I eased off into this topic with my principles on my post about Spring XML vs. Annotations that other day. This easy inlet was also my way of not complicating things too much for my team who is currently involved in writing this new app that will probably have a production life-span for 3-5 years (if we do it right and hope world of technology does not changes over it’s head).
I have been working with Spring Days since 1.1 so yes I have a level of comfort working with very large and complex XMLs. But, I know how to write them and more importantly I know how to read them. Since then Spring has made it easy for developers to understand them – Spring STS with Beans Explorer /Graph. Developers now do not have the need to worry about looking at multiple XML – those tools do the job for them even writing and managing beans for them.
We sacrifice the art of writing good and performant code for the short term gains of improving developer productivity
Since I saw Spring 3.x introduce this notion of Annotation based configurations, and the hype train of using these annotations instead of using XML has been huge for at-least 7 years (if i remember correctly). I have not been able to make peace with this change in direction.
Not saying it’s bad, but the point that this feature has been anything but abused by the community to it’s core and Spring has been guilty of promoting the abuse. Any Spring Documentation today, talks about annotation-style’d coding only to follow with the “classic XML way” of doing things.
While people say – it’s easier to read the Code, it’s easier to debug the code with annotations in the mix, they forget what’s it’s not code in code anymore – they have embedded configuration in code. And as far as I remember Configurations were supposed to be externalized. The problem is more severe in cases where we use ORM frameworks like Hibernate and JPA.
Even in original Spring Design, even with XML I feel that how we setup spring applications are not what spring was design for. It’s time for me to go find what Rod Johnson had in his mind when he designed Spring (I know a bit but I need to find some details and get into depth). But thats for another day.
So let’s look at this blog post that explains using JPA with Spring or read this StackOverFlow thread. Well, they both explain how to use, but very soon we realize that but using these so called Rich Annotation based configurations in Code we have diluted the overall meaning of What code/design is supposed to be. This style of programming is great when I have to try something new as a personal pet project to get off the ground quickly – i can just write a class, type a few annotations and boom i am ready to do CRUD, but does this really works in enterprise level applications especially how do we manage this in production.
These articles are nothing but a bunch of marketing/sales pitches that want us to go use these frameworks and new features, but they hardly put in context the complex situations we have to deal with in big production systems
In 2007, we used hibernate extensively on our project (with Spring 2.x with XML based configurations) and we realized very soon that we had taken the ORM framework beyond it’s limits. we had complex queries which we were trying to retrofit into Hibernate and something that was possible to write in MS-SQL as optimized procedures and fire away those queries were now becoming major bottleneck. I was new to the framework but more importantly I had a push from my technical leadership to use Hibernate to it’s fullest. Those people had access to article like I shared earlier and this looked like the way to go but they were nothing but marketing material to sell a feature that Hibernate and ORM brought onto the table. When rubber hits the road is when i had to go back and refactor the code and follow good old ways of writing queries.
90% of the times these frameworks that use annotations work well, but those 10% where you need your system to perform under stress is EXACTLY when these fail
Back tracking to Spring and Annotations now – why i do not like them? Simply because they make me write code like I am a college student who is learning something. They force me away from what used to be good practices in golden old days. Yes it used to take time to setup a few bunch of classes and it used to take time to write the SQL queries but I had right stuff in right places. And Yes it took time before we gathered momentum, but once we had those basics setup tight not only we could development speed, we also had done the things the right ways.
And yes no one can force us, but the average Joe Developer or the average Jim architect do not have the time and inclination and make these POVs, they do a google search and when they see 5 articles saying the same thing, they presume it’s the right thing to do and they proceed happily. And many of our Senior Technologists who also read these articles support the designs and many a times challenge the POV of what I am trying to put here.
Think about it and please do not use annotations to configure your applications. Configurations were never meant to be part of code – the reason they are called configurations. So let’s let those be. A small gain in short term wont go the long way especially when a client asks for a change in a table or a value and you tell him that will beed 5 days of development, testing and deployment.