There we go, that's the kind of information I was looking for! Thanks John. What got me started with Spring initially was its JDBC templates, but then everything I read basically said, "Yeah, Spring has JDBC templates, but you won't really need them since you should be using ORM instead." However, when I went to find some Hibernate/Wicket examples, all the ones I found were based in a Spring DI framework. So here I am. I'm sure it will be worth it in the end, but at the moment it's a lot of reading and testing without feeling like I'm being especially awesome.
Dane On Thu, Jul 23, 2009 at 1:32 PM, John Krasnay <j...@krasnay.ca> wrote: > Wow, this post generated a short burst of heat but not much light! > > I think the problem is your question conflates dependency injection, > XML-based configuration, and the Spring framework. IMHO you have to > consider these separately to understand their relative merits. > > Dependency injection is simply that if object A requires object B, it > can assume that it will be given an instance of object B rather than > having to "look up" an instance of object B. This has some very important > advantages: > > - it makes for cleaner code, since you don't have to code the lookup. > > - it makes your code independent of any particular lookup approach. You > can change how your business layer is wired together without changing > all of your code. This is particularly important when trying to create > libraries to be re-used in different applications. > > - it makes your code easier to test, since your test code can manually > inject stub objects and mocks. > > So for me, DI is a big win, regardless of how you do it (Spring, Guice, > or even code in your app startup that instantiates the objects and wires > them together). > > I don't find the Spring XML configuration to be that much of a problem, > since most of the apps I work on have no more than a few dozen object > configured there. One thing I like about it, as opposed to some > annotation-based approaches, is that it's external to the objects > themselves, making the objects more flexible. For example, suppose you > had a WidgetDAO that worked with a DataSource. With the Spring XML you > could easily create two different WidgetDAO instances each pointing to a > different datasource. This would not be so easy with an annotation-based > approach. > > As for the Spring framework itself, I find it contains a whole bunch of > functionality that I normally need in a business app, such as > declarative transaction management, AOP (e.g. for logging), and sane > wrappers around JDBC, JavaMail, and other difficult APIs. If you're not > using Spring, you usually have to figure out other ways to do these > things. > > Hope this helps. > > jk > > On Wed, Jul 22, 2009 at 06:40:19PM -0700, Dane Laverty wrote: > > Due to the fact that nearly every substantial sample Wicket app is > > Spring-based, I imagine that there's something awesome about using > Spring. > > In fact, Wicket is what has finally gotten me to start learning Spring. > > > > I think I understand the basics of dependency injection -- configure your > > objects in xml files and then inject them into your classes -- but I'm > still > > not clear on the advantage of it. I've read quite a ways into "Spring in > > Action", and the author seems to assume that the reader will > automatically > > see why xml-based dependency injection is great thing. I must just be > > missing something here. What I love about Wicket is being free from xml > > files. Can anyone give me a concise explanation of how the advantages of > > Spring are worth introducing a new layer into my applications? > > > > Dane > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
