 |
|||||||||
|
|||||||||
|
|
Well JEE has come a long way indeed. Things have become much more simpler than it was several years ago. One of the welcome additions to the Java language is the use of annotations. It is a full fledged addition to the language and is a very good feature that can increase developer productivity as well as make code more clear.
Examples are the use of the @Remote or @Local annotation for marking a EJB as remote or local, or a @WebMethod for marking a web service's exposed methods. In all these cases the generation of code (mostly boilerplate) is what aids the developer significantly. From a documentation perspective, even a new initiate into the technology can tell at a glance that the code they are looking at is part of a web service or an EJB.
These are all very good things, no doubt. However as with the rest of human endeavor, there is a danger of going overboard with this annotation business as well. This is particularly noticeable in the area of Entity Beans and annotations for persistence. I have seen code recently that is has multiple annotations for persistence (such as Secondary Tables, Associations, Id etc) which almost obscure the actual business function of the entity.
This is particularly inisidious because an Entity Bean should reflect the business domain model first and foremost and should act as a reusable business component. There shouldnt be any additional baggage regarding how it is persisted etc. This is one area where a declarative style of programming (with external descriptor files declaring persistence needs) is much better.
It is better for two reasons: 1) We get a truly reusable business component 2) If there are changes to the persistence model, we dont need to modify the code. As an example of point 2: suppose there is an entity bean that is currently mapped to two tables and we annotate that in the code using @Table and @SecondaryTable annotations. After a while if the database constraints requires us to change this to a single table (this has nothing whatsoever to do with the business functionality of the component) then code changes are needed to remove the SecondaryTable annotation.
Likewise, if certains properties neednt be persisted then additions of @Transient annotations becomes necessary. None of this really needs any code changes, but for the fact that they were annotated in code. And every code change has its attendant misery of compile-test-deploy cycles which can really be the bane of a production support team's existence.
So annotations have to be used with care. We cant have too much of a good thing now, can we?
