Annotations versus Configuration (More lightweight java ideas)
I know this is yet another topic that can easily turn into a religious debate. Some folks prefer external xml configuration (instead of annotations), and others are getting tired of having to maintain xml files and like the idea of annotations instead.
Up to this point, none of the frameworks i use really take advantage of annotations (i know webwork has some annotation support, but i have never heard of anyone really using it). As far ask i know, Spring and iBatis arent annotation friendly (though correct me if I am wrong. All the Spring 2.0 examples i see, use the new simplied xml config). So, I'm really not familiar with using annotations in my work. I think i would like to see that change.
Like others, I think I am at the point where having my app config scattered across less files would be a good thing. Sure, at the moment, i know where to look for them, so its not a huge deal. But with the webwork/spring/ibatis architecture, there are quite a few config files all over the place (the spring applicationContext.xml, xwork.xml, webwork.properties, defaultbundle.properties, sql-maps.xml, plus the ibatis xml file for each DAO object...though calling those sql xml files config files might be stretching it)
I know one of the biggest advantages to having the config in xml files is the idea that you can change your config without recompiling. I guess if you have a huge codebase that takes several minutes (or more) to compile, then thats a compelling argument. My current project compiles in well under a minutes..usually less than 10 seconds when i am just making incremental changes. So the time savings of the recompile really doesnt benefit me. Another benefit i read about is that you can make config changes and push them live more quickly, since a build isnt required. While a good idea in theory, in my 5 years on weather.com, and now 9 months on forgetaway.com, i have never needed to publish JUST a config file. Any change that has involved a config file change has ALWAYS also included java file changed..at least in my experience. So, thats another benefit of external config files that i havent experienced.
I've been reading about JPA and Stripes, and it makes we REALLY want to try those 2 together. Or maybe even
Stripes and Stripernate (though I dont know much about Stripernate at the moment). Looking through the docs on the Stripes website, I can really appreciate the simplicity and more importantly, the self-documenting nature of annotations. I will go into this more in later blogs when i start blogging about Stripes (assuming i have some time to take a look at it in the next few days)...but i LOVE how the annotations tell you EXACTLY which fields are getting validation, which method is responding to which url, which method is getting called before a certain interceptor, which jsp is getting returned from the method, etc. To me that makes the code much easier to maintain and understand..no need to dig in config files to figure out how the page flow works. You also dont have to always understand the entire interceptor lifecyle in Stripes to understand a given Action class..the interceptor annotations before a method EXPLICITLY state when that method gets called. Proper use of annotations like JPA, Stripes, and Hibernate seem to be almost just another level of documentation that just happen to also perform work. Nice!
Again, I know that using annotions, any config changes now require a recompile. However, I think at this point thats fine with me..i like have the config info in the same file as the code it is configuring.
I really want to spend some free time trying to rewrite one of my current pages in Stripes to compare it to WebWork. That would give me some idea of whether annotations are as nice in real life as they are in my head. Then i would like to try replacing iBatis with JPA or Hibernate annotations and see how that goes.
At least in my head..Stripes plus JPA/Hibernate could be a killer lightweight java architecture. (Stripes even seems to a really nice intergration with Spring, that would keep the Spring xml file to a minimum for those who would want to keep Spring in their architecture).
I would love to hear from anyone that is using Stripes and Hibernate/JPA, and how lightweight you think it is.
I hope to start playing around with Stripes this week...i'll def blog about my experiences as i get started.
posted by Jeff C @ 3:43 PM
7 comments
links to this post
7 Comments:
I'd say there are good uses and bad uses for annotations.
Annotations would entirely break the idea of IOC (inversion of control) that Spring is built on, so don't hold your breath there - the Spring XML file defines the way beans are used, explicitly without the beans' knowledge, so we should never see annotations that define how a bean will be used - or by definition the bean will no longer be reusable.
OTOH, annotations that describe something inherent about the class IMO are a good thing. JewelCLI for example, which was recently blogged about, is exactly that - it allows one to declaratively define command line parsing options -- the class and the options are always tied together, so it does make sense to use annotations there.
Iceman: why would annotations break the idea of IOC? Here's my take.
You create a class. It has a dependency. That dependency needs to be satisfied before the class can be used. You can either rely on it being wired up in an XML file, or you can annotate the property as being a dependency that needs to be injected (e.g. @Dependency).
I'm not a big Spring user, and I can totally understand why you wouldn't want your service/bean definitions inside classes. But I can't understand why you wouldn't want to document a bean's dependecies using annotations. It doesn't seem to make anything inherently less reusable as far as I can see.
i second Tim. i dont think annotations breaks spring IOC mechanism at all, in fact it makes it much easier to maintain. Check stripes Spring usage for a change please.
I've used annotations to simplify development, and I find it of great use.
However, i've also worked on projects where the only difference between one implementation and the other was the Hibernate configuration, so there really is some value in externalizing the config.
Of course, 95% of the time it isn't the case.
Here's how IOC would break dependency:
You create a class. It depends on IFoo.
You write into your annotation that FooImpl should be set as the dependency.
The runtime should have figured out which instance you needed - at compile time you're only relying on the type, not the concrete instance.
It would be especially hard to annotate a class written using the Strategy pattern - how do you annotate which Strategy to use - that is totally up to the user of the class!
Maybe I haven't seen enough examples, but I think Brian's comment says it all.
OK, so perhaps I should have asked, done intelligently do annotations have to break IOC ;)
The way Stripes does it is that you annotate a member (presumably of the interface type) with @SpringBean. The annotation takes an optional bean name (not type), e.g. @SpringBean("mySpecialBean"). The wiring process then looks for a bean by that name in the context. If the name isn't specified it infers it from the property name. If there is no bean present by name, it looks for a bean of the interface type in the context.
So you can happily change the service provided in your context (e.g. change mySpecialBean's implementation type) and the right service will get injected.
This approach may not be 100% as flexible as doing it all in XML, but I think you lose very little flexibility and gain a lot of clarity/maintainability. That's just my opinion though, I'm not proclaiming it's the one true way ;)
Lastly I should comment that I think the vast /majority/ of code we write is project-specific and as such that's what I tend to focus on. When you're writing code that you intend to use in more than a single project, obviously different rules apply and externalizing becomes more important.
Working on a Hibernate/Spring project right now.
Got spring cfg in XML and Hib in Annotations.
Recently started becoming concerned with the fact that my domain objects's now know something about their persist store (tables/cols etc) and the imports now directly reference hibernate classes for the annotations.
This seems kinda ugly when in some environments I'm using I don't want them peristed to/from a db or want to swap the persistance.
This leads me towards an all XML approach to I can supply the persistance info within the context of the containing app, but I don't find the proliferation of non-java artefacts very appealing either.
Suggestions / thoughts?
Post a Comment
Links to this post:
Create a Link
<< Home