J2EE web framework: struts vs spring vs hibernate

[jacksuyu]

Hi all,

Seems currently there are three open source frameworks could be choose
in J2EE web development: struts, spring and hibernate.

What I understand struts is MVC mode for web design, spring is IoC
which could also used in MVC, and hibernate is for consistancy, and
also could be used seperately in web design.

I am wondering what's the preferred solution for a middle size shopping
application.

Thanks.

 

[Raymond DeCampo]

Hi all,

Seems currently there are three open source frameworks could be choose
in J2EE web development: struts, spring and hibernate.

What I understand struts is MVC mode for web design, spring is IoC
which could also used in MVC, and hibernate is for consistancy, and
also could be used seperately in web design.

I am wondering what's the preferred solution for a middle size shopping
application.

All of these solve different problems and it is possible to use all
three without being pointlessly redundant.

I think that you mean hibernate is for persistence.

HTH,
Ray

 

[Jon Martin Solaas]

Hi all,

Seems currently there are three open source frameworks could be choose
in J2EE web development: struts, spring and hibernate.

What I understand struts is MVC mode for web design, spring is IoC
which could also used in MVC, and hibernate is for consistancy, and
also could be used seperately in web design.

I am wondering what's the preferred solution for a middle size shopping
application.

Thanks.

For the web-part there exist so many more alternatives to Struts that
it's almost hilarious. Struts is the "industry standard". It is quite
low-level and thus flexible. It is not "component-oriented" or
"template-oriented", which are in my opinion the two other major
web-framework categories. Also look into Java Server Faces for the web-part.

Spring I've never used so you can do without. But people who use it seem
to love it, so worth looking at ...

Hibernate is for persistency and thus not a web technology. But ofcourse
most web-applications have a data-layer as well. Hibernate is one of
many persistence frameworks for Java, it falls into the category
object-relation-mapping-tool, used for mapping database tables
(relations) to java objects transparently. Oracles TopLink is another
(commercial) tool in the same category.

Another approach to database handling is plain jdbc programming,
iterating ResultSet and so on. For advanced queries and manual
transaction handling it may be more suited than using a higher-level
framework like Hibernate.

Because you are going to implement a webshop app it sounds like
transaction handling is important. If you choose to implement a
data-layer that runs in an EJB container you have the opportunity to
take advantage of container-managed transactions (even if you only use
session beans with plain jdbc programming). If you choose to use EJB you
can also use Entity Beans to access the database. People tend to avoid
Entity Beans because they're difficult to configure and can have
performance issues, but that's not always the case. But it *is* very
convenient to have a tool generating the beans and all the configuration
files for you.

 

[Timo Stamm]

For the web-part there exist so many more alternatives to Struts that
it's almost hilarious.

Here's a list: http://java-source.net/open-source/web-frameworks

Struts is the "industry standard".

It is quite easy to find struts programmers. This might be important.

It is quite low-level and thus flexible.

I found Struts to be totally unflexible. IMHO, it just sucks.


Timo

 

[ozgwei]

Struts is the "industry standard". It is quite low-level and thus flexible.

Struts is not flexible. It forces you to extends its several Action
classes. Thus you cannot have a super abstract Action class in your web
application for common processing.

For advanced queries and manual transaction handling it (JDBC) may be more suited than using a higher-level framework like Hibernate.

JDBC is too low-level and error-prone. Programmers may forget to close
the connection in exception handling. You can try iBATIS from Apache,
which gives you almost full control of SQL command that is configured
in an XML file with placeholder parameters. So if you in the future
would like to change the order of the parameters (such as for
performanc purposes), you don't even need to change your code. If you
use JDBC directly, you may hard-code the order of the parameters and
thus need to change you code in those cases.

you have the opportunity to take advantage of container-managed transactions (even if you only use session beans with plain jdbc programming).

You can do J2EE without the overhead of EJB and an expensive
application server. You just need a web container, such as Tomcat, if
you use Spring. It is really good and also provides declarative
transaction management superior to EJB. It allows you to specify
whether to rollback a transaction or not based on the class of the
exceptions. Thus you may choose to rollback a transaction on a data
access exception but not on an illegal argument exception.

If you choose to use EJB you can also use Entity Beans to access the database. People tend to avoid Entity Beans because they're difficult to configure and can have

performance issues, but that's not always the case.

Entity Beans' notorious n+1 finder method is hard to avoid, you have to
read the application servers manual carefully to optimise this. Why
bother? Use Hibernate or iBATIS...

Also please read the two books of Rod Johnson (Spring's founder). EJB
is designed by committee, and has largely failed, while Spring,
Hibernate and iBATIS became popular because they are actually used by
people in the industry...

 

[Jon Martin Solaas]

I found Struts to be totally unflexible. IMHO, it just sucks.

If you try to make a complicated user interface using a low-level
framework, you really, really have to take care not to end up with
something monolithic and spaghetti-like. The framework is flexible, but
the implemented solution is not ... So basically it sucks, yes.

 

[Jon Martin Solaas]

Struts is not flexible. It forces you to extends its several Action
classes. Thus you cannot have a super abstract Action class in your web
application for common processing.


JDBC is too low-level and error-prone.

It is not too low-level for low-level tasks.

Programmers may forget to close
the connection in exception handling. You can try iBATIS from Apache,
which gives you almost full control of SQL command that is configured
in an XML file with placeholder parameters. So if you in the future
would like to change the order of the parameters (such as for
performanc purposes), you don't even need to change your code. If you
use JDBC directly, you may hard-code the order of the parameters and
thus need to change you code in those cases.

Definitely true, plain jdbc-coding for plain queries and updates aren't
the way to go. At least use some framework to get rid of the
bulk-coding, a connection pool and so on.

You can do J2EE without the overhead of EJB and an expensive
application server. You just need a web container, such as Tomcat, if
you use Spring. It is really good and also provides declarative
transaction management superior to EJB. It allows you to specify
whether to rollback a transaction or not based on the class of the
exceptions. Thus you may choose to rollback a transaction on a data
access exception but not on an illegal argument exception.

Spring is an exellent alternative, from what I hear. I've never used it,
so I don't feel comfortable recommending it.

performance issues, but that's not always the case.

Entity Beans' notorious n+1 finder method is hard to avoid, you have to
read the application servers manual carefully to optimise this. Why
bother? Use Hibernate or iBATIS...

Also please read the two books of Rod Johnson (Spring's founder). EJB
is designed by committee, and has largely failed, while Spring,
Hibernate and iBATIS became popular because they are actually used by
people in the industry...

Well, the industry also sometimes requires commercially supported,
expensive platforms, either by sheer stupidity or for actual good
reasons. So EJB's are actually widely used too. And how can you use
Spring if you believe in the best-of-breed-philosophy? Only one
implementation ... tsk, tsk ... And, is it really so that Spring and
EJBs are mutually exclusive?

Fortunately Java programmers has a really large toolbox to pick from.
But picking the right tool for the job is hence equally important.

 

[Timo Stamm]

If you try to make a complicated user interface using a low-level
framework, you really, really have to take care not to end up with
something monolithic and spaghetti-like.

Low-level in a language/framework means a small discrete set of
functions to me. Just like a processor has only a simple set of
instructions. But you can still use a high level language like java on a
processor.

The key is abstraction. Struts (and most frameworks atop of JSP) is more
or less usefull for a small set of applications. But it prevents any
further abstractions, and thus actually *forces* you to write
pasta-style once you need a bit more than what it initially offers.

So I would say it's definitely not flexible.


Timo

 

[Jon Martin Solaas]

Low-level in a language/framework means a small discrete set of
functions to me. Just like a processor has only a simple set of
instructions. But you can still use a high level language like java on a
processor.

Sort of agree ... but web technology is certainly not a «RISC
architecture» then, the basic «instruction set» is not small, Struts
runs atop jsp/hmtl/javascript and so on. And Struts doesn't add any
level of abstraction, just some convenient tools to interact with the
«hardware». I guess it would be similar to a collection of assembly
language macros, and what we'd really like would be a higher level language.

The key is abstraction. Struts (and most frameworks atop of JSP) is more
or less usefull for a small set of applications. But it prevents any
further abstractions, and thus actually *forces* you to write
pasta-style once you need a bit more than what it initially offers.

So I would say it's definitely not flexible.


Timo

Struts doesn't *prevent* further abstractions, you can add any level of
abstraction on top, you'd just have to do it yourself. So it's flexible
in my opinion, but it keeps me wonder, what's the point ... I'd rather
use something else.

As it seems we agree mostly on struts, it'd be interesing to hear what
is your favourite web framework?

 

[Timo Stamm]

As it seems we agree mostly on struts, it'd be interesing to hear what
is your favourite web framework?

I have been using Wicket lately, and am quite pleased with it after a
lot of bad experiences with other java web frameworks.

Wicket is a component based framework. It's closest relative among java
web frameworks is probably Tapestry. But it is page-oriented. For each
page, you have

- a HTML template that can be edited without any knowledge of java or
template languages

- a simple java class representing the page that can add or modify
the content using components


A very simple example:


MyPage.html:

<html>
<body>
<span wicket:id="myLabel">
example text that will be replaced
</span>
</body>
</html>


MyPage.java:

public class MyPage extends WebPage {
public MyPage() {
add(new Label("myLabel", "Hello World"));
}
}

Result:

<html>
<body>
<span wicket:id="myLabel">
Hello World
</span>
</body>
</html>


For a better introduction see
http://www.wicket-wiki.org.uk/wiki/index.php/Newuserguide

(The wiki is far from complete, but the API docs are quite good, and the
mailing list is very helpful.)

Wicket is quite young, but gaining a lot of momentum. I am sure it will
be become a well-established alternative to suns JSF.


Timo

 

[Jon Martin Solaas]

Sounds interesting. I prefer component based frameworks myself, too. And
especially pleasing is working with frameworks at a high abstraction
level so that I in fact do not have to concern myself with web-related
issues and html at all. There exist a few, but I've mostly used
Millstone. Pages are built with containers, layouts and panes, events
are handled with handlers (what else and if I absolutely have to
modify look-n-feel I can modify the xslt stylesheets that actually
transforms gui components to html (or anything else). (This is one of
the weaknesses too, xslt-processing can be resource-consuming ...)

 

[Timo Stamm]

Sounds interesting. I prefer component based frameworks myself, too. And
especially pleasing is working with frameworks at a high abstraction
level so that I in fact do not have to concern myself with web-related
issues and html at all.

Wicket might be interesting to you, then. A link can look like this:

new Link("myLink") {
protected void onClick() {
// link was clicked
}
}


Going to another page is also trivial:

setResponsePage(new MyPage());


It's all plain java. HTTP processing is completely hidden, but you can
still access request parameters if you want.

You have to edit HTML though. In fact, you have to match the component
hierarchy in Java with the component hierarchy in HTML. But this is not
mandatory. I have written my own high-level GUI-components and don't
have to touch any HTML to create new pages. So it is possible to use
wicket in a component-oriented way, even if it is page-oriented by default.

There exist a few, but I've mostly used
Millstone. Pages are built with containers, layouts and panes, events
are handled with handlers (what else and if I absolutely have to
modify look-n-feel I can modify the xslt stylesheets that actually
transforms gui components to html (or anything else). (This is one of
the weaknesses too, xslt-processing can be resource-consuming ...)

I have only had a quick look at Millstone. I was afraid that it would be
too time-consuming to customize the standard GUI-components. I actually
like to write HTML just like it appears in the client without any
abstraction layers. But I want it encapsulated in components (unlike JSP).

But to be fair, I never even installed it, only looked at the examples
and docs.


Timo