Hi Mark,
1) By using Spring Annotations (which are essentially meta-types in Spring API), we're not really removing tight-coupling entirely. A real POJO should not be having any Spring import at all.
2) Each Controller class is well documented and pretty cohesive. It never puts you in a dilemma, as the purpose of each one of them is unique. To me, its more like the Collections classes, where you have a number of types, however, each with a dedicated purpose and pros & cons.
3) Yes, more classes = increased complexity (at least prima-facie). But also, 'more flexibility'. The template
pattern used in these Controller classes give us an unparallel advantage over Annotation-based approach, wherein we can fine-tune application to our very specific needs (for example, deciding how a request should be interpreted as a form-submit request).
The thing is, I'm not at all averse to Annotations being used by community, when they bring simplicity to the implementation. However, keeping ONLY that option open is not going to do good in my opinion. For specific cases, we might still prefer to use some Controller class.
I mean, I can still use a java.util.Vector (and even the elementAt() method in that), if despite what it gives, it suits my bill. There is nothing wrong in this class per se, only there may be more efficient ways to do the same thing.
Labelling controllers as 'deprecated' simply closes that door... somthing I'm not agreeing with at all. For me, annotations are not the answer to ALL the situations.
The reason to deprecate a class or a method in the open world of
Java has always been different from simply 'promoting one way over another'. Its more like 'providing a better and more efficient way which caters to ALL what was supported by older version (and probably even more)'. The replacement of a deprecated artifact should also take care of not undermining maintainability (debugging, flow-control) etc.
Best regards,
- Aditya Jha