Better framework design removes the need for Spring July 10, 2007
Posted by Wille in Java, Software Development.trackback
For the record: I kind of like Spring, I’ve used its IoC-container for the better part of the last 3-4 years and I’ve been the driving force behind Spring adoption on several previous contracts.
However, as far as the core bits of the Spring Framework go, a lot of it grew more out of trying to paper over the cracks of the original, fundamentally flawed J2EE architecture and programming model than anything else.
About 90% of J2EE was so crappy up until “JEE 5″, that Spring (with Hibernate) was a natural “replacement” for a lot of it, and pretty good at it as well. However, that doesn’t mean Spring is perfect, maintaining a big application and its configurations is not a walk in the park. In fact, I’d say Spring is starting to show its relative “age” in some areas, it is the first commercially successful framework of its kind (much like Struts 1 was the first successful Java web framework). In practice that means that some of the design decisions of Spring where good, but not perfect, and other frameworks have popped up, learning from Spring by making better design decisions where Spring’s where flawed, and retaining the good ones.
The fact that Spring was borne more out of J2EE flaws than anything else has become very apparent to me in recent months, while getting to know new frameworks such as Wicket and JPA. Using the Wicket/JPA combination as an example, compared to the “last-gen” frameworks of the same kind, like WebWork and (older versions of) Hibernate there is a vast difference:
With WebWork and Hibernate, however good they actually where (and lightweight compared to a full J2EE stack), I always found myself wanting to shove Spring further and further into their territory.
With Wicket and JPA I found myself in the opposite position at first, I was scratching my head thinking: “huh, now where would I want to use Spring?”.
The answer to my last question was: Not in very many places at all.
In fact, I’d say there is probably a case for not using Spring at all in a Wicket/JPA application, if there are no links to other types of systems or frameworks and database interactions are all there is to it. You just don’t need it, the code and the application will be just as clean and nice anyway done right.
I think this conclusion also gives at least some weight to the point some people argue, that “Design Patterns to some degree exist to solve flaws in programming languages and frameworks”: Springs popularity and use grew out of fundamental flaws in Java in general, and J2EE in particular. As those flaws have been rectified by new JEE specifications, and better frameworks (such as Wicket), the need for Spring is suddenly diminishing (which is probably why the Spring people are so eager to add everything, including a kitchen sink into the Spring distribution to hedge their bets for the future).
Yep. That’s it exactly.
I don’t use spring or IOC or XML config or container security or really almost anything except straight Java and Wicket with a persistence framework (iBatis at Thoof and sometimes Hibernate elsewhere). You wouldn’t believe how often JEE people go on and on about stuff that’s just completely irrelevant in Wicket.
Anyway, while I can imagine using Spring to inject web services into my wicket pages, there are other possibly lighter ways to do that too and in any case the whole JEE world seems to be fading like a bad hangover. And not a moment too soon.
BTW, I should point out that I don’t work on “big enterprise” apps at the moment where it might be more important to factor out a service / business layer. Igor tells me that parts of Spring could be useful there and I’m inclined to believe that. Still, it is nice that you aren’t forced to write applications in a big-enterprise style if you’re working in a startup with less than 10 people.
“Big enterprise apps” where the reasons for my “caveat” for Springs applicability, I can very much see it still being useful if I need to integrate into legacy systems, put messages on various queues etc etc..
I still think one Spring XML-file is preferable most of the time over a plethora of .properties-files.
use jsf instead of wicket .. It is better for your career.
jsf has gotten lot better over the years. You can inject beans into jsf using spring. It is very easy to build simple app as well as complex app in jsf if you like component framework. use spring mvc or spring webflow if you like request – response model web framework.
No need to move to JEE 5 unless you need to support the old model or you are required to program in that model because of your company policy. Always prefer light weight programing
I’m in the business of making money for myself and my customer – hence I have to deliver applications once in a while rather than just charge for endless hours of fighting with frameworks.
In that instance, JSF is a complete no-go.