I think one of the benefits of Spring is that, theoretically at least,
it allows for a somewhat more vendor-neutral approach to development.
For example... where I work, we're a Websphere shop. For better or
worse, period, that's it, end of story. As a result I've seen many
developers doing Websphere-specific things. Now, on one level that
makes sense: why pay for an app server if you aren't going to fully use
its capabilities? The other perspective though is the one I subscribe
to more which says that the ability to swap out app servers with as
little trouble as possible is a nice place to be. I think this way
about databases as well, and in fact as many things as possible!
If you go down the route of using Spring then I think it helps you get
there. For example, you have Spring Web Services that you can use in
place of Websphere's WS engine (in practice this has proven to be a far
more difficult task than the theory says it should be, but still!).
Using Spring Security (which, as I understand it, used to be Acegi) can
help you get away from container-manager security a bit (and if that
sounds wrong to you then keep in mind that Spring is, to a large extent,
playing the role of the container itself). Using Spring's DI can get
you away from JNDI to some degree. And so on.
Talking about Spring JDBC in particular, because this is probably the
part of Spring I've personally had the most experience with and have
gotten the most beneift from... I'm on the same page as a couple of
posters here seem to be in that the infatuation that people had for a
couple of years with getting away from SQL and JDBC largely didn't pan
out (and yes, I recognize that's a controversial statement for many
still today). I'm someone that feels shying away from SQL is not the
way to architect a good application. That being said, I think that
Spring JDBC, which we've been using extensively for about a year now at
work, really does help significantly. Not having to worry about all the
details of JDBC while *still* dealing with naked SQL is a really nice
thing to be able to do. It's really just a collection of convenience
classes and methods, not another pointless abstraction layer. I like
that I get to stay fairly low-level but in such a way that is more
convenient.
At the end of the day, Spring is largely just a well-rounded,
full-featured library that you can in many ways look at the same way you
look at the whole of Apache Commons: take the pieces you like (and that
you see the point in) and simply ignore the rest! Spring makes doing
that pretty easy, for the most part at least. Some see it more as an
entire platform to build an app on, in many ways taking the place
traditionally held by various J2EE spec components, and if you really
buy into it completely I can see how it leads to that. But if you don't
see the point in the whole thing like that, then cool, not a problem...
don't let that stop you from finding the bits and pieces that will
definitely save you time and effort though!
Keep in mind too that there's such a breadth there that it takes a while
to get through it all and pick out those useful pieces. That's both the
blessing and the curse of something that presents so much power, simply
finding what you need is daunting. Don't take that to mean there's no
point or benefit to be had though :)
Frank
--
Frank W. Zammetti
Author of "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
My "look ma, I have a blog too!" blog: zammetti.com/blog
dusty wrote:
You should look at Spring annotations. So awesome. And Spring Security!?!
forget about it. If you don't drink the Injection/TDD koolaid then wiring
up services with Spring may seem lame.
I don't think the issue is how well Spring handles JDBC. We could talk
about Hibernate, but I am assuming that Hibernate is only for noobs when we
are talking about the value of writing your own JDBC management code.
Spring definitely provides some convenience. Some developers may be the
cat's meow at writing raw JDBC, but my experience has been raw JDBC = poor
resource and exception handling. Something that Spring should help you
with.
Ralf Fischer-2 wrote:
In my opinion this depends on the preferences of the developer and how
he likes to organize his code.
I never used Spring much. In the past I could never get used to the
XML configurations. I simply don't like it. I especially don't like it
in EJB2. Up to now I never had time to check out the Spring
annotations. What I do like are working function keys in Eclipse, esp.
F3 + F4 :-)
Am 27.01.2009 um 20:38 schrieb johnrock:
I have been reading 'Spring Recipes' and learning all about Spring
2.5 for
the first time. I have read all about Spring JDBC, transactions, AOP
and
eliminating cross-cutting concerns...my problem is this: I still
don't get
it. I am waiting to see some problem that Spring is solving for me by
making things easier and clearer but from what I have studied so far
it just
looks like Spring introduces twice as much complexity to solve the
standard
types of problems.
Well, you cannot remove complexity, you can just shift it around or
move it to another place in your code. Spring, like any framework, may
hide some of the complexity and deal with it in a common, or
"standard", way. At the price of additional abstraction.
And, the cross cutting concerns that you eliminate are
replaced by Spring code which seems to hide logic and make things more
obfuscated. Even the JDBC and transaction management seem much
simpler and
clearer to do with straight JDBC. Am I missing something? What is
the real
payoff here that Spring provides that I could not do otherwise?
Spring is just a framework you may want to use or not. The problems
which are addressed are the same everywhere: JEE, Spring, .Net, ...
The common developer out here has to solve business problems. The
technical issues are not his main concern, and usually don't play a
major role in the business model of his employer. Thus the big players
create frameworks/products/APIs which hide the common technical
problems as much as possible, in a more or less intuitive way. The
developer has a set of building bricks which plug together nicely and
help him to reach his goal as fast as possible: solve the business
problems.
I am dying
to hear at least one real world example that makes me say: "oh yeah?
that is
awesome!"
Right now I use EJB3 and JPA for the most part, along with a little
Spring (AECGI and some more) in the webapp. For the DI part to wire
the actions with the services and some external JAX-WSs: here runs my
own glue code, as my action doesn't care whether a service is a EJB,
WS or just a simple Java object I configured into the interceptor to
be injected.
Well. Everybody puts their pants on one leg at a time... Expect to be
unimpressed whatever you decide :-)
-Ralf
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
