Just A Quick Note on Frameworks
Since I’ve been pushing Spring quite a bit lately (what can I say… I like it!), a lot of people have continuously asked me, “why?” The most common question I keep getting is “What problems does it solve?” and when I mention all the features it has (dependency injection, wiring, bean management, event publishing/subscribing, etc) the response is always along the lines of “Why bother? Why not just handle the dependency injection yourself?” or “Any programmer worth their salt would be able to write a simple event handling mechanism.”
My thoughts on this is that Spring handles all the boring, mundane boilerplate work and allows developers to focus on what really matters in software… the domain. The domain is what drives business, and sadly while it is 90% of what makes the software important, it often goes ignored in favor of focusing on the mechanics of tying everything together in a system. And, to my dismay, I have on more than one occasion observed developers ignoring the domain all together (even at one of the DesignFest sessions I attended at OOPSLA, the developers tackled the problem by first designing the database tables and the ORM mapping to them).
So, long story short… I think that we as developers need to delegate non-domain work to frameworks as much as possible… why in this day in age we still let developers write custom O/R mapping solutions, dependency injection frameworks, and custom event dispatching systems on business projects is quite a mystery indeed… wouldn’t their talent and effort be better put to work by focusing on the business logic in their system instead?
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
October 4th, 2007 at 9:09 am
I agree completely.
While it is probably true that “Any programmer worth their salt would be able to write a simple event handling mechanism.”, do you really want to be the programmer who has to write that mechanism again and again and again and again as he/she moves from team to team and firm to firm? Writing it once may well be fun and instructive, but it gets old fast.
I sure don’t. Spring (and like frameworks) take away the gumpf and alow you to concentrate on the the important (and unique) bit, namely the domain.
October 4th, 2007 at 9:38 am
Great point. Businesses need a lot of money to throw at a project to afford the time to come up with a better solution then what Spring, Hibernate, and other frameworks provide. Yes, they could then use the homegrown DI or ORM solution in future projects at the company, but they would still have to support/enhance the framework which would cost money.
I normally recommend free/open source projects with the logic that if it’s a good project, with interest, it will only continue to get better being open. Over time there will be more people testing/debugging/improving an open source framework then what a company could do “in house”.
Erik
November 28th, 2007 at 11:18 am
I know you already know this, but you can tell them:
It does a few things:
* Solution with the least amount of effort (complex models from simple components)
* Easy easy dependency injection! Yay!
* AOP - makes crosscutting concerns nice and easy, in example with interceptors for logging or security
* Spring support for Persistence Frameworks. Man, oh man, does this make me happy since it will plug into Ibatis, Hibernate, JDO, Java Persistence API and supports all those languages with their DAO support modules. No longer do I have to write a bunch of extra support code - and it will close the connections and all that for you! You guys would be able to say goodbye to Kurt’s Hibernate manager thing.
* Those DataSources can be changed with just loading a different file into the context, whether it be getting the datasource from the JDNI, Hibernate Transaction Manager or whatever, it’s all transparent.
*It can also be used instead of Struts for the MVC
December 6th, 2007 at 5:30 pm
James is Crazy!!!!!!!!!!!!!! Blogger.