I’m as much of a Spring fan-boy as the next guy, but I still think that there are some points of improvement. One of the most important things I miss in the Spring framework is the encouragement of a behavioral domain model. I wrote about the advantages of a behavioral domain in a previous post, but since that post was about .NET, I’ll rephrase the argument using J2EE terms here.
Once upon a time, there was little Enterprise computing, and developers – including yours truly – were writing fat clients (even though the term was unheard of at the time). One of the most important works at the time was Design Patterns, which gave us all a common language to express ourselves without much explanation. We were encouraged to think in an Object-Oriented fashion, which – amongst others – means that you only touch your own private parts. This was all fine and dandy: everything fitted within our object-oriented structures.
Then J2EE happened
All of of a sudden, we were supposed to use databases to store our stuff. As Martin Fowler has pointed out, the conversion of a relational model into a object-oriented graph is not something simple. Luckily for us Java developers, Sun came along with the EJB specification. By implementing some entity beans interfaces, this spec allowed us to keep our object-oriented designs!. What more could we wish for?
As it turned out, life was not so simple. The performance obtained on entity beans was so bad, it forced us to find solutions to fix this. One of the most important solutions was the Session Façade, which basically put a faster-performing stateless session bean in front of the entity beans, so that the fine-grained manipulation of entity beans was replaced by courser-grained calls. In the end, we even got to use local interfaces, which further improved performance.
For some reason or another, this model stuck in people’s minds. The façade layer (or managers layer, as most classes in this layer bear the suffix Manager) was so widely adopted that developers could not devise a J2EE app without it. Unfortunately, the widely spread of this “pattern” also meant that behavior was stripped from the objects (i.e. entity beans) into the façade. Why on earth would you want to place code on the entities? The managers are good enough, right?
Enter Spring
Rods books on the Spring Framework struck a nerve. Finally, we were able to use POJOs again!
The bad pattern, however, stuck. Developers still used the managers façade to layout their services. In fact, this was encouraged by Spring, since all spring-managed beans are singletons by default, much like the stateless session beans of the EJB days. The alternative to singletons is that you get one instantiation per request, which is at the extreme opposite of the spectrum. Hence, the Law of Demeter cannot be applied.
The Solution
To facilitate in my OO-needs, I would like to be able to specify the exact life-cycle of my beans. JavaServer Faces comes close to what I would prefer, since it has four instantiation options (none, application, session, and request). Obviously, these options are only valid within a web application.
I think that Spring should come with a similar model, allowing me to use entities in an Object-Oriented fashion, but still giving me the huge benefits of the Spring container. Most of the time, I don’t really care whether an object is stored in a databases or not yet: the web pages I create around it are basically the same. In the end, instead of:
I’m looking something like:
where the hibernateBean is some kind of bean that can obtain the entity primary key using whatever context is available: spring-mvc, JSF, whatever…