I've read the hype, read the user docs and I've even purchased Rod Johnson's latest book. I've even spent an evening or two trying it out myself. While I can't (or haven't yet) convince myself that the Spring Framework is the second coming of Java development, I can't help wonder if I'm missing the point entirely and can't see what the masses are raving about.
The most common argument goes like this, "it's amazing, I can develop with MySQL on my workstation and then with the flip of a switch my application deploys to Oracle|DB/2|[insert industrial strength db here]".
In a corporate environment where choices are sometimes not plenty, is this pluggable feature (ie. Hibernate, iBatis, JDBC, etc) really really that beneficial?
I work mostly with large corporations with large databases and we integrate many legacy applications with newer modern systems (ie. typical J2EE layer above the aging but still necessary mainframe legacy application). I have rarely had the luxury of simply creating/installing a database on my workstation to develop against and simply deploy against the official one. The problem usually stems from lack of data (or abundance of it depending on which side you wish to view it from). I'm not developing petstore applications or shopping cart systems for ecommerce sites. We're dealing with massive amounts of data, the data that is the backbone of your business logic/applications. Without the data model from that legacy database, you don't have much of an application. We're not talking about a toy USER table with the corresponding ADDRESS table and whatever dinky little model you can imagine and populate with a few rows of test data. Sure you can harp on how it's useful for a new application, etc. but IMO this is a rarity in large corporate system development. At best, you might have new tables that are linked with pre-existing data but it's unlikley you get to create that application scratch from the ground up.
Here's something I've noticed in most places I've worked, Companies don't change database servers very often. Ok, I shouldn't make such a generalization because I know there are all those little shops out there who started with MySQL, outgrew it and upgraded to postgresql or hell even spent a few bucks and bought one of the commercial databases (you get my point). This just strengthens my point though, those are probably small companies evolving their infrastructure as needs grow. Large companies rarely switch database vendors. I'm not going to go into specifics as to why but to be brief just consider the amount of work to do data conversion, upgrading all applications that use the data and what do you do about all those archived tapes?
In my experiences, the argument that I quoted above doesn't hold much value in large organizations. Yet, I can't be the only one who thinks this...the entire blog nation can't be wrong.
What I do see is a lightweight container with an assemblage of useful frameworks from the Java OSS community, sort of a revolutionary, underground J2EE movement fighting against the evil doctrine evangelized by Sun, aka "Java Enterprise BluePrints".
Someone enlighten me.
Before you start flaming, let me add a disclaimer that I actually think Spring is cool. I'm just struggling to understand it's purpose. I'm actually working on an EJB application at the moment and I've thought of using Spring's BeanFactory but I ran into problems when trying to create the BeanFactory in my ejbCreate() (others have reported similar problems in the forums), so I've put that little project aside while I work on real stuff.
Subscribe to:
Post Comments (Atom)
7 comments:
The 2 things I like about Spring have nothing to do with "magically switching databases".
1. It lets me easily separate the UI/Business Logic/Data Access tiers of the application using interfaces. Sure, I could have written my own factory framework or some other way of doing it, but why reinvent the wheel.
2. It handles opening/closing and transaction management for me so as long as I follow the rules, I don't have to deal with them at all in my code. Therefore, my code is easier to read because it has less try/catch/finally blocks. I don't have to pass database connections around or anything like that. It handles stuff for me. Again, I could have written my own framework for that stuff, but why do it?
I don't know who you are talking about, but switching databases easily is not a very good argument for using Spring. The person that argues that doesn't understand what Spring is all about.
Your first poing has nothing to do with the framework. It's just the formalization of a good practice (coding to Interfaces) to begin with. As Rod essentially says in his book, this is simply recognizing a Design Pattern as a Best Practice.
I do concede on your second point as I can see the wisdom in abstracting all the transaction coding away from your business logic and letting Spring handle/configure it.
The "switch your database" argument is a weak one, to be sure. But that's just an absurd example of a more practical thing Spring enables: loose-coupling. When the components that make up your class are loosely-coupled, you can swap out implementations easily without impacting the code that depends on them. I'm not *necessarily* talking about databases here. A practical day-to-day swap you might perform is to swap out a real-world production implementation with a mock implementation for testing purposes. If you're doing unit-testing with jUnit, then you know it's hard to truly unit-test a class (in isolation) without indirectly dragging along the other classes that it depends on (and the classes that they depend on and so forth). If your classes only know about each other via an interface, then it's easy to swap out a real implementation for a mock implementation.
Not that Spring is the magic tool to enable that...certainly you can do mock testing without Spring. But Spring fosters the type of development that leads to loose-coupling and thus leads to more easily testable code.
Another thing Spring brings to the table is its AOP framework and more specifically its support for declarative transactions (via AOP). On the surface, Spring provides declarative transaction support for POJOs that is reminiscent of EJB. Because it's POJOs, you don't have to run your app in a big application server...Tomcat is often sufficient (standalone is even possible in some cases). But Spring also goes beyond EJB's transaction support (which was pretty much limited to propagation behavior) with the ability to declare isolation levels and rollback-on rules (the ability to always rollback or always commit when a given exception is thrown).
I could go on, but this comment is long enough...I'll let someone else speak of the other stuff Spring is great for.
"Your first poing has nothing to do with the framework. It's just the formalization of a good practice (coding to Interfaces) to begin with. As Rod essentially says in his book, this is simply recognizing a Design Pattern as a Best Practice."
I don't agree. The spring framework (through IoC) isolates the layers of an application. If you don't use the Spring framework, you'll need some other framework that isolates the dependancies between tiers. I'd just rather use something that others debug for me. It's also something that developers may have learned before we hired them, reducing training costs. You can use your own framework if you like. It's all up to you.
Spring's IoC container is quite powerful--it can used consistently as THE solution for configuring and connecting your application objects in potenially any deployment environment (for example: web, system test, standalone, rich client, etc.) This capability greatly simplifies your application objects, as they are freed from having to configure and and manage their dependencies themselves (for example, via ad-hoc singletons or property files).
Furthermore, as the last comment alluded to, Spring provides structure to your application - most importantly, promoting the definition of a well-defined, POJO-based service layer that can be decorated with infastructural services transparently by the facilites of the IoC container, AOP framework, and various Spring support packages...
At the moment I'm doing some consulting at a big corporate and you're right, they're all using Oracle so there's no real need to be all pluggable and stuff. One of the architects here is heavily trying to prevent Spring from coming into the development team.
A couple of days ago there was this developer that had huge problems with connections leeking all over the place. He got crazy with it. So I had a chat with the architect, convinced him of me introducing Spring's JDBC support and sat with the developer for half an hours. Using the JdbcTemplate and some other nifty Spring stuff the connection leaks where gone in no-time.
Of course they could've all developed this themselves, but then they'd have to maintain all of it. Right now there's thousands of developers using it and it works.
Just to indicate that you don't have to start off by using Spring's advanced IoC support. There's more to Spring than its IoC container and the AOP framework. Use it where you see fit. Eventually you might even start to wire your beans using it ;-).
Alef Arendsen
Disclaimer: I'm a Spring Framework developer
Signature
Post a Comment