A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Yes, of course April showers and May flowers are a good idea. But how about the open source Java framework that enables inversion of control? ( also known as dependency injection.)
My company is just beginning to use Spring and I'm trying to figure it out. It looks to me as if one key aspect is that instead of using "new" to create an instance of a class, you define an interface, and then you ask Spring for the instance of a class that implements the interface. Spring has a generalized class factory that will create the instance based on Spring configuration files.
Spring is intended to make it easier to do automated testing and to eliminate lots of boiler plate code associated with transactions and talking to the database.
But it is yet another layer in the stack for the poor innocent programmer to master. In some ways it also goes against the "collocation" gospel that Joel describes so well.
So... do you guys think it is worth it?
Wednesday, May 18, 2005
I have still yet to figure out what use it is. Wiring up objects has always seemed quite simple to me. The AOP stuff is likewise generally unintersting to me. The transaction stuff is exactly opposite of how I like to code so I don't like it much either. Don't know about the web flow or client side stuff.
But people go google over it so I think I am just out of step on this one.
son of parnas
Wednesday, May 18, 2005
Yes, it's absolutely a good idea.
Read an article on what it does for you to understand a bit more at:
As a longtime Java developer (among other things), the main benefits I see are:
- It makes it easier (and path of least resistance) to build software with fewer hardwired dependencies. For example, if you're using an external FAX service, it's perfectly understandable to hardwire it into a class, but w/ Spring, its almost free create an IFAXService, and configure an instance to use at runtime. You don't have to worry about creating a bunch of factory code and worrying about where to initialize it. It support "dependency injection" to allow more pluggable software, and in fact, to make that easier than NOT doing it that way.
- It simplifies configuration headaches. If nothing else, it provides an obvious place to put configuration parameters, as well as configuration for your service objects. That FAXService implementation, for example, needs a target URL, a username and password. All goes in the same place.
- It makes testing easier. Because its easy to externalize the hard-coding, and program with interfaces, it naturally lends itself to making "test" configurations, say, a MockFAXService that logs its results. You just need a test configuration file.
- Reduces questionable programming tactics like overuse of Singletons. Because you have a place to put things that only need to be initialized once, you don't wind up with a bunch of global singletons holding configs, handles to datasources, service handles like EJBs, etc.
- Database and transaction support. Spring has out of the box integrations with most of the popular Java persistence frameworks like Hibernate, Toplink, J2EE entity beans, JDO, etc. Provides support for declarative transactions without using EJB containers. Also provides some built in JDBC wrappers to make direct JDBC use easier.
- Surprisingly unobstrusive. Using Spring doesn't mean having to learn all of its functions, you can start by using it for basic cofiguration storage, then using it as a generic object factory, and finally using the transaction, AOP, persistence integration, and other advanced features.
Wednesday, May 18, 2005
It's aspect-oriented programming, which is patented.
Why the FUD about aspect-oriented?
If they ever decide to charge licensing fees, the code in Spring will just have to be redone. I'm sure there are enough users that this task would get done, regardless of any single person's decision.
And they could sue for past and present use, but that could happen for a lot of things. Linux was discovered to possibly use a couple hundred of patented inventions, but nobody has jumped on them yet.
Do you see anyone in a mad rush to stop using E-mail addresses in objects, now that MS has patented it?
People who worry obsessively over patents will not find much success in our society, unless they're lawyers. There are a number of real threats. I don't see using a framework that uses AOP as being one of them.
I'm still not sure whether Spring would make a significant difference to my project. However, the place that I think Spring should be most successful is in third-party libraries. If I'm using a Spring-enabled third-party library (basically, one that expects an external source to create it and configure it - it need not explicitly depend on Spring), it'll be very easy to incorporate into my existing application, and I'll still control my application's startup and configuration. If the third-party library expects to have its own config files or something, it makes for a messier deployment for my app.
So while Spring may or may not have significant advantages for my application, I'll tend to prefer third-party libraries that are designed to be "sprung".
Thursday, May 19, 2005
I guess I was making more of a comment about patents than about AOP.
If someone decides to enforce the patent, it's not obvious that it's possible to write around it, because it's not copyright, so it's not a case of making a new clean-room implementation of the same idea.
Fortunately, Europe seems to be evading software patents, so far.
Well, I did see a whole lot of people paying huge sums of money to Unisys a little while back.
Considering how poorly advertised and completely undefended that patent was, I can't see why people companies are suddenly going to stop using patents as weapons now.
I don't care how pathetic Microsoft's patents are, not many of us could survive the court battles.
Thursday, May 19, 2005
I found both of your replies interesting.
After thinking about it for a while, I will concede that the AOP patent is a little scarier than most, mostly because it appears to be legitimate (new, novel, and no prior art). I would probably think twice before using AOP in my own code. I would still use Spring and JBoss's EJB 3.0, but write my own code without any AspectJ syntax.
Hopefully JBoss makes a business deal that makes AspectJ free from concerns related to this patent.
If you still have reservations about Spring, pick up Rod Johnson's (the creator of Spring) book, "Expert One-on-One J2EE Development without EJB".
While you're at it, pick up "Patterns of Enterprise Application Architecture" by Martin Fowler.
I'm about half way through the Fowler book. It seems like Rod Johnson read it and then went and made a framework based on it.
Saturday, May 21, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz