Neward on Crupi

Don--great to see you taking an interest in this stuff.

How is Spring simpler than EJB? I can't claim to give you an independent view, but given that I started from EJB and designed Spring with that experience in mind, I'm happy to compare the two. For a start, Spring (or any IoC + services framework) keeps the framework out of your code. That's a huge difference with many implications. Any object can be made transactional etc without that object needing to jump through hoops as with EJB. This is also great for reusing legacy code. The fact that there are less framework-specific requirements on objects means that you have greater freedom to practise OO.

Sure, you typically use some XML in Spring apps (although there are ways to minimize the amount of XML), but it's way less than you end up with with the EJB deployment descriptors.

Because your code isn't heavily dependent on the container, you can easily unit test it with something like JUnit. Huge productivity gain vs the cumbersome in-container testing strategies often seen in the past in J2EE. You can even run some integration tests using a Spring container but not a heavier J2EE app server--unlike any app server, a Spring container takes very little time to start up.

Compare the Spring Pet Store sample with a traditional EJB approach. In the Spring approach there's very little Java code that doesn't do anything...no service locators, JNDI lookup etc etc. In my experience from client projects, using a combination like Spring/Hibernate it's not unusual to end up with 10-20% of the code a traditional EJB-heavy J2EE app would have taken, with a significant gain in speed of delivery and maintainability.

My recent "J2EE without EJB" (Wrox Press), argues these points in much greater detail. But I'd love to discuss this with you, here or offline if you're interested.

Rgds
Rod

PS There's a .NET port of Pico and work is underway on one of Spring. (Strictly speaking it's not a "port" as that wouldn't make sense. The core IoC + AOP stuff is pretty similar, but when we get into the services the issues are different in .NET.)

This is great, I hope the thread continues...

My 2 cents:
Spring and PicoContainer both look great and there is a good .net implementation of PicoContainer, StructureMap (https://sourceforge.net/projects/structuremap/).

But it appears that .NET has a nice lightweight container implementation living in
System.ComponentModel namespace.

Described in more detail by Kzu here: http://weblogs.asp.net/cazzu/archive/2004/05/10/129140.aspx

and by Brain Pepin here: http://www.urbanpotato.net/default.aspx/document/1757

Srdjan

I also wonder how many O/R mappers the world needs and why I would go with LLBLGenPro or a code generator like CodeSmith. The .NET community is still hashing out the fight between: DataSet versus custom collections as well. Give a kid a hammer and everything looks like a nail. I realize there is no ONE answer, but am I the only one in the world yawning at most code generators and thinks that typed-Datasets are the coolest thing since sliced bread? :-)

Sean,

I agree there's no one answer. The model of making local changes and then explicitly pushing them back in using diffgrams is hugely popular (look at LDAP!), and I think typed datasets are a reasonable way to do that.

I certainly prefer that approach to the implicit approach taken by ORM, but to each his own.

DB

Rod,

What I'm hearing you say is that EJB containers are too complicated and don't integrate well into test/debug infrastructure.

I'm not convinced that yet another layer is the answer to the former, and customers should hold EJB vendors (IBM, BEA) accountable for the latter.

BTW, I'm not bagging on your work - I'm just trying to grok the state of play in Java land.

Honestly, it appears to be absolute chaos to me (and I'm really not trying to FUD - I have plenty of chaos to deal with here in the big house).

DB

Don

In a high proportion of applications a "lightweight" container like Spring is not "yet another layer": you don't need the EJB infrastructure at all. It's a simpler layer that achieves most of the same ends, such as declarative tx mgt. Even where EJB is still useful (some remoting requirements etc.) an IoC container ends up replacing an in-house layer of software, rather than adding a layer that wouldn't otherwise have existed.

No argument that the standards/implementation should be simpler to use. J2EE hasn't done well there. The specs focus far to much on seldom-used high-end features, and forget the importance of making simple things simple. (I'm not too worried about this being quoted against me, as I've been saying it for over 2 years.) I believe that the better the design of an enterprise framework, the less complex the tool requirements should be for testing/debugging etc.

I don't agree that it's "chaos" in the Java world. I think that open source in particular has generated some great options, based on extensive experience in the field. It's taken a while, but now products like Hibernate and Spring have reached critical mass, so it's no longer necessary to do a lot of research to identify a suitable stack for say a transactional web app.

R

Don -

For me, the fact that technologies such as Spring and Hibernate are transparent is a huge win.

Also, you can add on services as you need to use them in your application.

With big frameworks like EJB you get the whole damn stack even though you don't want it.

http://www.almaer.com/blog/archives/000482.html

Dion

"As an aside, I really wonder how many O/R mappers the world needs. It's frightening how much energy goes into building these things (on both sides of the aisle I might add)."

I brought this up at Tim Ewald's blog. At one point a whole truckload of theoretical arguments were put up against O/R mappers in general and how it is a folly to shoe-horn objects into relational data or vice versa. Academically it was a very interesting discussion to follow. But even after the advent of O/R mappers like Hibernate (http://www.hibernate.org) which obviously has managed to garner a significant amount of mind-share among the Java developers, why don't the bigwigs of the industry consider the fact that Hibernate just might have got the approach right? Isn't the proof of the pudding in the eating?

Hi Don,

What do you think about Eric Evans' book Domain-Driven Design (DDD)?

OK, this might seem to be way off topic, but I might be able to re-connect it to the main thread... We'll see.
:-)

Best Regards,
Jimmy
www.jnsk.se/weblog/
###

Have to agree with Dilip's comments, based on my practical observation. O/R mapping has produced a real productivity gain on a number of projects I've led.

Having said that, I believe that Java folk have traditionally been *too* eager to use O/R mapping. I don't hesitate to use a SQL-based approach where ORM is not a good fit.

In reference to Ted's comments, I think the "Vietnam" happens when you try to apply ORM where it doesn't fit, not in ORM per se. Shovelling an ORM where it doesn't belong gets nasty.

R

+1 for Rod's latest book.

This is a really interesting time for Enterprise Java Development. We are finally seeing that the traditional EJB-centric applications and the excess of EJB "Design Pattern" overdose, dont work.
As a user of both Hibernate and Spring, I can personally attest to the fact that it is a much more productive environment.
Alot of the Core J2EE patterns are just not necessary. Why write/test/maintain code that has no business value? The plumbing should be provided transparently to us. EJB was supposed to let the developer focus on business logic..and provide the middleware services (?) If so, then why do we still see tonnes of Service Locator,Business Delegate, JNDI, etc.. ?

IoC, AOP (i.e. Spring) and transparent POJO persistence (i.e. Hibernate) have been extremely useful in the applications that I have been developing.
This isnt a blanket solution.. as it depends on the business requirements.
However for a great number of applications it can provide alot of value.

Also Eric Evans' DDD is a great book, as well as Fowler's PoEAA. These are the tech-agnostic books that really translate well to applications that actually embrace the OO in Java.

I've come across all this stuff about lightweight containers and the 'inversion of control' principle, as usual, by tripping over it in interesting posts on the (few) weblogs I try to keep up with. This trail of links started with...

Don,

To play the "middle-ground" here, I'd say there is a great deal of chaos, and a good deal of order in the Java universe. (And in a way, chaos is a good thing, because it calls for evolution). In general I'd say we all agree:

"The J2EE APIs/Abstractions (as provided by Sun) have failed to provide a good development environment for solving business problems."

The core of the issue is "How the technology goes about solving the business problem". There are plenty of issues (validation, exception handling, job scheduling, transaction mgmt.) involved in solving "the problem", (some of these things are handled within the J2EE/ EJB 3.0 specs, some not).

This is the beauty of Spring, not just the ORM integration. J2EE provides many loosely coupled APIs, but where does that leave you?... You are still relatively "far away" from a "business solution". The abstractions provided by Sun (particularly JDBC) have failed, and hence ORMs are around to make developers lives easier... Which ORM to use?? well it depends on the application, here's where Spring shows off it's power)

Spring has a huge value add in the respect of being able to "pull together/harness" all of the J2EE APIs as well as Open source APIs/solutions/components under one umbrella. A developer doesn't need to learn too much about the Quartz Job Scheduler to integrate scheduling into thier application. They can refer to the Spring API (and examples), plug in the jar, and configure it in an XML file in a "way" that is familiar to them. If something better comes along for Job Scheduling, plug that jar in, update the configuration, and you are off to the races. (You aren't "bured" on having to spend weeks trying to develop, understand, and configure an API that becomes outdated). As technology evolves (i.e. these Chaotic ORM's), you don't need to go back to the drawing board and learn all of the nasty configuration details.

To summarize, IMO Spring is a "lightweight platform" and J2EE which is a library of API's, to focus on "how Spring directly compares with EJB3.0" may be missing the big "business" picture.