I don't personally use Hibernate annotations, I prefer the XML syntax. However, I had to comment that your post has some truth in it and it runs contrary to your very same post: "Data outlasts programs". Odds are you'll abandon your program before your schema changes in a significant way. So, if you have annotations that specify ORM metadata you are likely to not have to worry about changing it that often at all once you go live. (previous statement is totally dependent on a multitude of external factors)
To the overall point: I must disagree that annotations are a bad smell. Almost all configuration is code of one form or another in that it manipulates your application. Just because you're not "programming" doesn't mean you're not "coding". Just because you have configurations in XML does not inherently make your application more decoupled either. You still have to be aware of configuration metadata wherever it lies. In the case of XML it is actually further away from the code that it configures than annotations. That's a big advantage for annotations - you can see the code and the configuration of that code without have to juggle various XML files. Also, in the case of passing in enumerations to the annotations you get a level of native compile time safety that you can't get with XML. You'll know immediately if you have a syntax error or, in some cases, invalid argument types. As noted previously, with both XML and Annotations you're going to perform a build (depending on your build tool semantics may vary) and deploy. Even on large projects this is not the end of the world. If you follow best practices you should be able to compile, test, and deploy discrete modules of your project without forcing an entire rebuild of all dependent modules. And even if you do have to, that's an even stronger argument for annotations since you get compiler warnings on syntax errors while you do not typically get this with XML. This will save you valuable time vs. chasing down a runtime error because you misspelled an xml attribute value that is only used in x scenario on y days. Having said all that there are times I prefer XML. For example, Spring's XML syntax is very powerful and probably could not be expressed as elegantly via annotations. Additionally, the context XML file fits nicely with the philosophy that you're wiring an application together out of various, potentially unrelated, modules. It's nice to do this declaratively via an XML file, IMHO. Contrast that with Tapestry where you are instrumenting individual components/pages in your UI layer (I know Tapestry does other things - no flames - just pointing out the typical use case). In this case I find it much more convenient to have the configuration close to the particular piece of code I am working on. I would say this boils down to personal preference / best tool for the job rather than a blanket statement like "it smells bad". - my $0.02 On 4/18/07, Patrick Moore <[EMAIL PROTECTED]> wrote:
jdk 1.4 3+ years old, annotations are great for tapestry.... I don't have a single .jwc file anywhere.... But personally, I think the hibernate people are smoking crack to use annotations. Data outlasts programs and to have your data definitions blended with your code.... WTF are they thinking. But for tapestry? come on! Hey they are working on jdk 1.7 .... at some point Sun is going to EOL 1.4like they did 1.3.... catch up with the rest of the world! -Pat On 4/18/07, li li <[EMAIL PROTECTED]> wrote: > > Annotation is a bad small. I mean that it is a bad thing. You have to > compile all java code if you change any annotations. But if you use xml > config file,there is no problem. > > > > > *离人网* >
