Using Spring in web app

[Silvio Esser]

I'm designing a web application in following architecture:

Struts + POJO(Action Helpers & Business Service Classes) + Hibernate(DAO)

I was told to use Spring in the service tier. But what's the benefit of
using Spring here? Thanks.

[Purushoth Thambu]

If you have read about the framework you can make out that spring can be used across the layers. At the core spring is
- Object Assembler,
- Dependency manager.

I am sure your application will have many business components and dependencies among them. If you think about assembling/constructing business object to service a request through external registry you will appreciate the benefits.

[Silvio Esser]

Why do I need to let a framework manage the dependence between the
components or classes? component reuse?

[Hung Tang]

Spring provides IoC (dependency injection) capabilities. If you understand IoC and appreciate the benefits it brings to your project, then consider using it as it simplify J2EE coding.

[Silvio Esser]

I'm not using EJB. Only J2EE components we are using are Servlet/JSP through Struts in web tier.

Business and data access tiers are POJOs. EJB sucks and Spring might be
better, but read this: http://crazybob.org/2006/01/i-dont-get-spring.html

Spring reminds me 9 years ago when EJB just came out....
[ February 16, 2007: Message edited by: Silvio Esser ]

[Hung Tang]

That is the author's opinion about Spring. Whether he gets it or not, that is his problem but you cannot, and should never take other people's opinions and think it will apply to your case. Take it with a grain of salt.

Now, seriously....what are your real concerns with your project, and I'll tell you if Spring can help. better yet, you should take Spring for a test drive, and see if it really addresses your concerns or not.

[Silvio Esser]

I do not have a problem that needs Spring to resolve. My concern is that
Spring will make my simple web app unnecessarily complex.

[Ulf Dittmer]

Silvio,

knowing very little about Spring, I sympathize with your concerns about overkill. Too many frameworks are being bandied about as the next great thing, when in reality they are just not applicable to all projects. The advice given in that article is sound: Go in with your eyes wide open. Struts (or Stripes, if you're on Java 5) plus Hibernate go a long way - it may well be that you're better off not using anything else.

[Hung Tang]

Your application being complex due to Spring is very subjective. Those who don't know what value Spring can add to their projects will certainly make them more complex. In my experience, Spring brings a lot of value to my projects because I know what problems I have, and know where Spring adds value to them. That is, I have legitimate concerns such as code readability, good design, stable code base, documentation, J2EE support via templates, aspects, etc. etc. etc. Spring is arguably, imo, one of the best written frameworks I have the pleasure to look at.

If you don't have much concerns, then you shouldn't need a framework.

[Silvio Esser]

Hung, Why do you not use EJB in stead of Spring?

[Hung Tang]

Silvio,

I hope you don't misunderstood me in saying Spring should be preferred over EJB3 for all projects. Actually, I am planning to use EJB3 in my upcoming project over Spring. I am not overzealous on either framework/specification. I'm more interested in solving my own problems, and if there's anything that can help me (or my team or company) accomplish what I need (insert framework x), then great. Having said that, why would I prefer Spring over EJB3?

Testability: Spring is light-weight insofar that I don't have to drag a EJB3-compliant container to test my components.

Stability: How many application servers do you know out there are EJB3 certified right now? Spring has been out for over 5 years and is being used in major financial organizations all over the world for building high transactional systems.

Design-AOP: Spring2 supports true AOP semantics (i.e. pointcut support), something that EJB3 lacks with basic Interceptors.

Design-code readability: Spring2 supports IoC better than EJB3. You can only inject certain enterprise resources with EJB3 whereas Spring can inject any regular POJO component.

J2EE support: Spring is more than EJB3 in that it provides support for simplifying J2EE coding for specifications such as jdbc, jmx, jms, mail, etc. etc. etc.

User audience and market: Spring has been out a lot longer than EJB3. You'll find a lot more frameworks out there that has Spring support instead of EJB3 because there are many more users of Spring.

[Silvio Esser]

Originally posted by Silvio Esser:
Hung, Why do you not use EJB in stead of Spring?

I meant EJB2

[Hung Tang]

In that case, I can't really find a compelling reason to suggest to use EJB2 for new projects. Sorry.

[Silvio Esser]

Originally posted by Hung Tang:
In that case, I can't really find a compelling reason to suggest to use EJB2 for new projects. Sorry.

EJB2 provides all (even more) the advantages or good stuffs you want in your design. Of course, it is more complicated than Spring for developers.

The point I'm trying to make is that not to chase the buzzword, but take a close look of the real substance in a framework. What we really want is a STANDARD framework (maybe not perfect) to make developers' life easier to meet the business requirements.

If a framework just does things slightly differently with a lot of new
buzzworks, we need to be careful. On the other hand, chasing buzzwords is always good for
developers' resume.

We have been doing Dependancy Injection (DI) for yaes with many design patterns, even before EJB (BTW, DI is not an J2EE terminology although EJB/JCA/... support it well). I did not see the point to use a framework (with a lot of XML) to enforce that.

[Hung Tang]

Originally posted by Silvio Esser:

EJB2 provides all (even more) the advantages or good stuffs you want in your design. Of course, it is more complicated than Spring for developers.

I'm sorry, I do not share this view with you. I don't know how many people out there who has use Spring or even EJB3 would share that view with you. EJB2, IMO, is a major contributor to giving J2EE a bad name. That's the whole motivation behind the existence of Spring--to steer away from the awkward/confusing programming model that is forced upon us by EJB2. EJB2 is complicated, encourage bad design, difficult to test, etc. etc. When there is an EJB2 design pattern book out there, and you need XDoclet to generate deployment descriptors for your enterprise application, EJB2 is no where close to being "simple". Please enlighten me as to the "good stuffs" you refer to in EJB2 that I want in my design because I see none of it. But I do applaud the changes and improvements made in EJB3--it's a right step, but it has taken long enough.

Originally posted by Silvio Esser:
The point I'm trying to make is that not to chase the buzzword, but take a close look of the real substance in a framework. What we really want is a STANDARD framework (maybe not perfect) to make developers' life easier to meet the business requirements.

Granted, Spring is not a standard specification; however, unless you are constrained by some bureaucratic process that strictly forbid usage of other frameworks outside of J2EE, then this "standard" argument is irrelevant. One thing I hate about standards is that it takes forever to make changes to them because of the problems inherent with bureaucracy that comes with JCP. Talk about innovation (or lack thereof) with J2EE. Do you think the success of Hibernate, Spring, Struts, Seam has anything to do with standards? They are the reason why J2EE is at least keeping-up with the alternatives out there--see .NET and Ruby on Rails.
[ February 17, 2007: Message edited by: Hung Tang ]

[Silvio Esser]

"Please enlighten me as to the "good stuffs" you refer to in EJB2 that I want in my design because I see none of it."

Find a EJB book, it will list the advantages of EJB: code readability, good design, stable code base, documentation, J2EE support...

I agree that EJB should be much simpler. There are too many interfaces and XML deployment discriptors...

What is AOP? come on!

[Silvio Esser]

I want to redesign my web app with three more different options.
I only list Struts for the web tier as I fell comfortable
with it and it does what I need. There is a large Struts developer pool.


Struts + Stateless Session EJB + BMP Entity EJB

Although EJB supports Dependency Injection (DI), I think it's
a overkill. I use BMP to support the distributed 2 phase transaction.
CMP does OR mapping, but not support 2 phase TX well. Plus,
EJB is not a buzzwork anymore.

Struts + Spring + Hibernate (DAO)

Spring provides a IoC container using DI, but I can use DI with
my own code and it is much simpler and faster. I do not like a
framework that requires you to write a large number of XML files
to configure or use it. I select Hibernate because I have about
100 tables and I want the mapping logic be outside the Java code.
XML mapping files are easier to be understood than Java code.

Struts + POJO + JDBC (DAO)

It will work, but the DAO would be very mess given the number of
tables.

Struts + POJO + Hibernate (DAO)

This is my favor. Business modules will be losely coupled with DI,
which can be done easily in my own code using many design patterns.
Hibernate takes care OR mapping and can be used with the 2 phase
transaction. I want to do DI in the way I fell comfortable, not be
forced in a way of the framework or EJB. I do not want to write many
XML files to configure the framework (just like deployment descriptors
in EJB). I have been always using Java interfaces when they are
nesceesay.

BTW, I do not like the terms of "IoC" and "DI". They are just new names of
old stuffs, no real new substances. I think this is a common problem of the
open source community.

[Hung Tang]

Find a EJB book, it will list the advantages of EJB: code readability, good design, stable code base, documentation, J2EE support...

Code readability and good design? You got to be kidding me. What book have you been reading and how did you arrive to that conclusion? I'll give you my vote on stable code base on the application servers side, as well as documentation since it's been out for a long time.

What is AOP? come on!

Do you realize that many modern J2EE app servers use AOP for implementing distributed enterprise services you so heavily depend on like transactions?

[Hung Tang]

Originally posted by Silvio Esser:
I do not like a framework that requires you to write a large number of XML files to configure or use it. I select Hibernate because I have about 100 tables and I want the mapping logic be outside the Java code. XML mapping files are easier to be understood than Java code.

So you say you don't like to write a large number of XML files, but yet you are okay with all the XML mapping files for Hibernate?

BTW, I do not like the terms of "IoC" and "DI". They are just new names of
old stuffs, no real new substances. I think this is a common problem of the
open source community.

Those terms, and like many other design pattern names are helpful for communication. What do you really expect?

[Silvio Esser]

XML fits mapping very well, but not the dependence beween classes.

I like to use the old names to describe old stuffs, like container, de-coupled, loosely-coupled, mediator, ...
[ February 22, 2007: Message edited by: Silvio Esser ]

[Stu Thompson]

Interesting, 'lively' discussion, folks.

Originally posted by Silvio Esser:
Business and data access tiers are POJOs. EJB sucks and Spring might be
better, but read this: http://crazybob.org/2006/01/i-dont-get-spring.html

Did you follow through with the comments? Many interesting points and few trolls. It is worth reading if you have the time.

Crazy Bob's follow up: http://crazybob.org/2006/02/i-was-too-hard-on-spring.html

[Silvio Esser]

Another thing concerns me is that Spring is not 'light' anymore. It becomes
heavier and heavier, and even heavier than EJB.

[Hung Tang]

Originally posted by Silvio Esser:
I like to use the old names to describe old stuffs, like container, de-coupled, loosely-coupled, mediator, ...

hmm...container like Tomcat? mediator pattern? is this ioc? There's some literature written on ioc that you may want to read: http://en.wikipedia.org/wiki/Inversion_of_control

Loosely-coupled though, I agree to that extent.

Originally posted by Silvio Esser:
Another thing concerns me is that Spring is not 'light' anymore. It becomes
heavier and heavier, and even heavier than EJB.

Heaver than EJB huh? can you use EJB with Tomcat?

[Silvio Esser]

Bridge pattern is another example.

Originally posted by Hung Tang:

Heaver than EJB huh? can you use EJB with Tomcat?

You can always get JBoss. JBoss is just like Spring has lots of jar and XML files. The difference is that JBoss provides UI for configuration.
[ February 22, 2007: Message edited by: Silvio Esser ]

[Hung Tang]

Originally posted by Silvio Esser:
Bridge pattern is another example.

I think you're not really understanding what is ioc. And no, it's not the bridge pattern or any other terms you like to toss out there.

You can always get JBoss. JBoss is just like Spring has lots of jar and XML files. The difference is that JBoss provides UI for configuration.

Have you ever used Spring at all? JBoss is an application server that provides enterprise services such as security, JNDI registry, class loaders, proprietary XML descriptors, jsp/servlet container (tomcat), EJB3, MQ for messaging, etc. etc. etc. spring don't come bundled with these services. instead, it provides support for many of them--that's the difference. Often many small to medium applications don't require these additional services and can live without the bloat of JBoss or any other application server. Do you ever compare the size of the lib folder in JBoss to that of spring? on mine, it's 21MBs(for jboss) and 2.5mb for spring. Spring has lots of jar? I only have spring.jar, and no other dependencies. Do you ever compare the level of quality in the documentation of JBoss to that of Spring?

Please get your facts straight. If in doubt, do some research on the topic before making erroneous conclusions.
[ February 23, 2007: Message edited by: Hung Tang ]