JOB REFERRALS
    ON THIS PAGE
    ARCHIVES
    CATEGORIES
    BLOGROLL
    LINKS
    SEARCH
    MY BOOKS
    DISCLAIMER
 
 Wednesday, February 15, 2006
It's dogma that's bad... not Spring

Several people have commented on my recent posting about Spring, and I want to make something clear: I'm not saying that Spring (or Hibernate, or EJB, or anything else) is a bad technology. I'm saying that walking up to every project, assuming that Spring will be THE answer, is bad. This kind of dogmatic approach--which, by the way, more than anything else is what led to the downfall of EJB as a popular technology--is bound to bite you in an uncomfortable place sooner or later.

One commenter, in particular, chastised me for not providing specific examples regarding where Spring may fail; I'm not going to stand here and make an exhaustive analysis of Spring's strengths and weaknesses. Besides being something that's already being done elsewhere, it would be beside the point that I'm trying to make--that dogma of any form is bad.

Look, so you've been successful with Spring on a few projects--that's good, and I encourage you to consider Spring again for your next couple. But don't make the dangerous assumption that using Spring will always yield success. In fact, let's take this out of the realm of Spring entirely and restate the point: "Look, so you've been successful with [[TECHNOLOGY-X]] on a few projects--that's good, and I encourage you to consider [[TECHNOLOGY-X]] again for your next couple. But don't make the dangerous assumption that using [[TECHNOLOGY-X]] will always yield success." (Where [[TECHNOLOGY-X]] can be, but isn't limited to, one of Spring, Hibernate, EJB, J2EE, COM+, WCF, CORBA, XML services, relational databases, stored procedures, managed-code-inside-the-database, highly denormalized relational data, highly normalized relational data, ....)


Wednesday, February 15, 2006 5:52:55 AM (Pacific Standard Time, UTC-08:00)
I agree that golden hammers are a bad thing.

But Spring is something strange because it does multiple jobs:
-It provides an IOC container. It is great to wire up almost any JEE system (it also makes your code quite easy to test)
-It provides an abstraction for a lot of JEE specs.
-It makes it easy to use AOP (for transactions/security for example)

These are things we use in most JEE projects, so Spring provides a nice environment to wire up a wide variety of JEE applications. I don`t say is the best choice period, but Spring is a nice choice in a lot of cases.



Wednesday, February 15, 2006 2:17:23 PM (Pacific Standard Time, UTC-08:00)
If true, then it may be worth remembering that Java or even computers themselves may not always be the best way to solve some problems.
Tom
Wednesday, February 15, 2006 8:00:16 PM (Pacific Standard Time, UTC-08:00)
Agree with commenter#1, Spring is different.

Also, I've read the first two books from Rod Johnson, and IMHO he and his team are truly pragmatic and a far cry from the big egos and political leanings you normally see behind popular frameworks. I also feel that the days of specifications from Sun (e.g. JSF) gaining acceptance and surviving just because of the Sun rubber-stamp are over and the main reason is the Open-Source effect.

Spring may not be perfect, (I believe it is) but it may just be the best stack out there.
Monday, February 20, 2006 5:30:24 AM (Pacific Standard Time, UTC-08:00)
I don't like dogmas in any way. But on the other side anarchy is not very productive. Although one should never stick to one technology, it is counter productive only to settle for the perfect technology on a project.

Just choosing between .Net and Java has a lot of parameters and it is not certain there is a clear choice. And why not include assembly, c, c++, perl etc. in your tecnology pool.

In the end you might just end up with the technology you knew beforehand. I think it is very healthy to shop around in technologies, but I also like to have reference technologies I know my way around. I don't have time to learn it all :)
Friday, March 03, 2006 4:11:54 PM (Pacific Standard Time, UTC-08:00)
So, with Spring I generally find that my Service Locator and Singleton code disappears. It's simpler to load external resources through their built-in resource implementations. And it's easy to wire my objects together declaratively for dev, test and prod environments.

Those aren't compelling reasons to use the framework; I guess. But by the same token, the question isn't so much "Is Spring right for this project?". It's more like "How much of Spring should we use on this project?".
Comments are closed.