At the Spring Experience, in several different sessions, there is quite a bit of coverage of different uses of annotations. I may have to update
my list.
One of the really interesting uses (maybe I'm just ignorant here) is to identify classes and methods to apply point cuts with AOP. This seems like the perfect use of meta-data. This one isn't necessarily a Spring thing, just cool.
The use of annotations in the MVC project have some good and bad. One good thing is the use of an annotation to identify a controller, rather than having the controller extend the
AbstractController. This means the class doesn't need to depend upon Spring classes. This should help preserve backward dependability (to your app) as the framework evolves.
Another cool thing is the ability to decide which method gets called by the value of a request parameter, via annotation. This changes to a more declarative model of programming that should make code easier to develop and much easier to test (less logic, less to test).
@RequestMapping(params = "action=delete")
public void removeSite(@RequestParam("site") String site,
&nbp;&nbp;&nbp;ActionResponse response) {
.
Then there is a scary part, using annotations to map URL patterns to controllers. This means the URL patterns will get scattered around the code base (hopefully in only one or two packages). The XML configuration isn't perfect but, personally, I'd like to see URL mappings in one place.
@RequestMapping("/myAction.do")
public void handleAction....
An interesting thing of the how annotations are used in Spring is in many places they help remove dependence on Spring classes and interfaces. "Use Spring but, don't
depend on it".
@PostContruct and
@PreDestroy (function are obvious from the name) are pretty cool.
@Resource both powerful AND dangerous (this one is for annotation driven dependency injection). Using this could make unit test more challenging.
@Autowired is a good way to reduce XML if auot wired beans don't scare you.
A little validation for my attitude with annotations. During Rod Johnson's presentation on The State of the Art Dependency Injection, he said that he like annotations but, not annotations that take strings (even the stuff in Spring). At least if I'm crazy, I'm not alone
:-) Update: reference to this post on DZone.
.
.
Labels: annotations, java, patterns, practices, spring, Spring Experience
I'm a little late jumping on to the Java5/6 bandwagon. I'm one of those big strong typing / type safety advocates. It comes from spending a lot of time on big projects where tracking down trivial errors is a process unto itself.
Naturally, I find the new generics to be a blessing. When you are in favor of type safety, casts always make you cringe.
I must admit that I basically ignored the annotation system for a while. When I did start using it, I saw things like
@Override, "hey this is good to protect code while refactoring." I saw the Spring framework's @Required (ensure classes are properly configured). These seem like good things, communicate with the compiler, communicate with the frameworks. This establishes a rule in the first case and a requirement in the second.
Then things start to go grey. The
@SuppressWarnings mostly finds itself being used when using code that does not support generics (J2EE :
request.getAttribute()). Ok it's a necessary evil, I admit.
Then EJB3 starts down a darker path.
@TransactionAttribute(TransactionAttributeType.REQUIRED)do we really want to define this in the class?
What about JNDI lookups
@Inject(jndi-name="java:comp/env/jdbc/test") ?
Finally, it gets down right ugly
@Resource(name="myDB", type="javax.sql.DataSource.class")
@Table(name="CUST", schema="RECORDS")Finally, we start to see annotations with SQL in them
@SQL(statement="SELECT * FROM USERS WHERE {sql: where}")Finally, there's the ultimate abuse (from
Google Guice):
@ImplementedBy(ServiceImpl.class)
public interface Service {This one is so bad it doesn't need explaining.
Like many things, I think annotations can be very useful when used correctly. What bothers me most is when Sun is the one promoting obviously bad practices. Really, what's the difference in using annotations with SQL in them or just writing plain old JDBC? not much. If the configuration is in the code being configured, then what's the point of an annotation?
To be fair, I could agree with doing this if it was contained to configuration classes. By this, I mean a handful of classes that sit in a package all to themselves and serve to replace XML configuration. Configuration classes benefit by providing compile time type safety, and can exploit tools for auto-completion. But, sprinkling these kinds of annotations around the code base is going to make for maintenance nightmares.
The way I see it:
annotations to make code easier to configure :
Goodannotations to enforce local policies :
Goodannotations to define requirements (contract) :
Goodannotations
to configure :
BadUpdate: I've just received an email about
Loom and how it uses annotations for validation on beans (value objects to the rest of us). The idea being that the logic can exist in one place instead of at every tier (web, middle, data access). It can read the annotations to generate javascript for page level validation, and use the same annotations to validate the beans in the other tiers.
I haven't looked at Loom myself so, I'll reserve judgement but, on the surface this appears to be an interesting (read innovative) way to use annotations.
Update: while talking to a colleague, he mentions that much of the 'bad' use of annotations looks like C macros in sheep's clothing.
Update: reference to this post on DZone.
.
Labels: annotations, development, practices
