This week's giveaway is in the Spring forum.
We're giving away four copies of REST with Spring (video course) and have Eugen Paraschiv on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes Which framework to use in web layer? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Which framework to use in web layer?" Watch "Which framework to use in web layer?" New topic

Which framework to use in web layer?

Sandeep Ghosh
Ranch Hand

Joined: Jan 23, 2002
Posts: 145
We are going to start a medium size project, which has potentiality to be a big project in future. I have to take decision for fixing tools and technologies for this project. Database will be Sybase for now which will be migrated to Oracle. Hence we couldn�t write any stored procedure. Our team members had worked with Struts, Spring, Hibernate. So Spring and Hibernate is almost fixed. I am in dilemma what to use in web layer. I had read component based framework like Tapestry, JSF are better than MVC based framework like Struts and Spring MVC. So should we leave Struts in fresh development? If yes what should we choose i.e Tapestry or JSF. Is it true in JSF, web page designer has to learn JSF based tools as their tools like Dreamweaver will not work. It will be difficult for me convince them to learn something new. Does Spring MVC gives client side form validation like Struts validator.
If we choose JSF, do we need to buy any commercial IDE like JBuilder or Exadel.
In nutshell I am looking for honest suggestion to which web framework to choose. Candidates are
1. Struts
2. JSF
3. Tapestry
4. Spring MVC.

Thanks in adv
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
Struts IMO (and most people I know agree) should preferably not be used for new development.
Exception is maybe if you have a ton of Struts applications already and don't foresee them being replaced or phased out at any time in the intermediate future.
Same can probably be said for Tapestry.

Both are definitely outside the standard, making heavy use of custom classes and components.

I'm personally starting to like Spring MVC a lot. Pretty much everything you write is independent of Spring itself, making porting of the application to something else relatively easy.
Same with JSF of course.
Both also work well together with Spring, a major advantage.

Whether component based frameworks are better than MVC based frameworks is purely personal preference. It's kinda a religious war.

Spring MVC provides full serverside validation. For quite a lot of it (if you need to validate on standard data types) you don't need to do anything at all except for using the Spring taglib in your JSPs.
I've not looked at using it for clientside validation, which I personally don't consider particularly important.

You can write JSF in any text editor just like you can JSP. If your web people don't know how to write HTML by hand you may need to look at replacing them.

Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
If you need a decent level of separation of roles between your HTML designers and Java developers, then Tapestry,Facelets and Wicket are probably your best bet. I don't know how easy it is to write custom components or extend the existing ones in Tapestry and Facelets. In Wicket, ofcourse its super easy. Just plain vanilla HTML backed by a subclass of Wicket's Border or Panel class as the case may be. So you can give Wicket a try right away or wait for a month may be and check thisout
Most java developers love to keep things in Java. Personally, I feel that Wicket is more likey to keep your designers and Java guys happy. Wicket integrates well with Spring and Hibernate and ofcourse you can get to Hibernate through Spring which i believe is a widely follows practice. So you have that side covered too.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
You can easily separate roles when using JSF and JSP.
Just because many beginners don't do it doesn't mean it can't (and shouldn't) be done...
Chase Bonham
Ranch Hand

Joined: Jul 15, 2006
Posts: 50
Just use EL,JSTL, Custom tag library, AJAX, Oracle stored procedures for (DML)

Look at myspace and all those million PHP sites out there, they are not using any fancy MVC framework and yet they are thriving. MVC for webapps is an overkill because most of the frameworks out there put too much emphasis on the M and the C and not on the V, when in reality you really need to simplify the V. JSF is one framework that provides re-usability in the "V", but its M and C is tedious.

IMO, editing XML files for defining and validating fields on a JSP page and defining how to navigate from one JSP to another is so "non-intuitive". Why not keep all that is JSP related inside the JSP?.

As your project increases, the # of XML mapping, config files you will need to maintain will also increase.. whereas if you stick to JSP and smart tags
(commercial tag library, JSTL, EL), you will just need to stick to JSPs.

Now, you said you are moving to Oracle so that you can use stored procedures. Obviously you plan to do some DML in these procedures. Why do you need Hibernate at that point?. Hibernate is good if you are doing all your persistence in the Java layer. Keep your persistence code in either the database layer (stored procedures, triggers) or the Java layer. Don't spread it in different layers.

Which brings to the M and the C. You can write a single servlet that would be your front controller and use convention over configuration (i.e., derive navigation from jsp naming patterns). Thats what Ruby on Rails uses. The only reason you need M is for Hibernate and if you are sharing Pojos in some other project. IMO, M without EJB is a waste. What purpose does a pojo that maps to a form on a JSP serve?. Its a throw away. Remember as you add more pages there will be more pojos to write...
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
Bad advice, very bad advice.

Large sites DO use an MVC system of some sorts, it's just that the user doesn't see it
And if they don't they soon get into serious trouble at the first change in their infrastructure.
Want to change the database? Want to change the screen layout? Oops, not possible because it's all tied closely together.
Chase Bonham
Ranch Hand

Joined: Jul 15, 2006
Posts: 50
How often do you change infrastructure?

Changing a database vendor is a major event and would warrant rework in at least 2 layers of your MVC application. 1) the database, 2) the OR mapping.
Whereas with a smart tag library you would make that change in 1 place.

Layout/Themeing. These are usually specified in CSS files which are outside
your HTML anyways.

Back in the Powerbuilder days when they were mapping GUI widgets directly
to database columns, did they not develop large applications?.

I have nothing against MVC as long as the M & C is automatic and I have to deal with only the V. But thats the not case with the existing java web frameworks out there. The M and the C still need a lot of baby sitting/configuring. Its just not as automatic and painless you would expect it to be.

Struts -> Too many XML files.
JSF -> Over engineered crap. Event driven web pages with all user clicks mapped to an event going to back to the server. Yeah, who cares for snappy user experience as long as we are getting MVC.
Spring -> Does it really have any V specific tools?.
Tapestry -> Good! but too much work.

Hibernate -> What good is Hibernate when all your calls are Stored Procedures?
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
have you ever had to maintain a Powerbuilder (or Progress, or similar) application of any size?

It's a major pain in the butt because of that hard linking between user interface, business logic, and database code.
Sure you don't change database vendors all that often (in fact with Progress and I think Powerbuilder too you can't even change it because they're hardwired to the database engine...), but the database structure changes constantly as the application evolves.

I was maintaining a Progress application earlier this year when there was a database change with pretty hefy impact.
Had it been an MVC application that would have required few changes, maybe a few stored procedures and data access classes would have to be changed.
But it wasn't, it was all hardcoded database fields inside the user interface (as is the norm with Progress).
Adding a single field to a few dozen tables required that over 2000 source files be modified, and 2000 more needed to be checked for correctness but didn't need changing.
A team of 10 people needed 3 weeks to do the job, working 60 hour weeks.

The benefits of MVC architectures for all but trivial multi-tier (web)applications has been well established.
I know also that there's a constant stream of greenhorns who have never been in a situation where they have seen the benefits and consider the bit of extra work during initial development to be a pain and see that as proof that MVC is useless.

Your comments put you squarely into that category, rejecting everything that eases maintenance and makes the application more flexible to change and less rigidly linked between application layers.

Changing the database vendor in a well constructed MVC application would affect part of a single layer, the model layer.
That layer is itself divided into multiple tiers, and indeed several of those are affected.
And as those layers would very likely run on independent machines (possibly in different parts of the world) and there might well be multiple view layers and controller layers accessing the model layer, changes would be very limited.
For example, the system I'm currently working on has a single model layer (which is itself a multitier system).
But there are in our control at least 3 view layers, each with its own controllers. Each of those layers has multiple clients (indeed, these layers are in part clients to each other).
Customers can pay for access to these layers, receiving data feeds and an SDK to create their own applications on top of them.

Changes to the database have ZERO effect on the data the customer receives. In fact he will never know the database changes at all, as he'll just be routed to a different database server while a server is down for an upgrade or database schema change.

Try that with your tightly linked code where each client application directly accesses the database in each field it puts on the screen.

But in your dreamworld of completely integrated application every single part of the application would need to change. Every smallest change in the database might mean a complete rewrite of the entire system.
But dream on, and let's hope we never have to work with you until such a time as you've come to your senses as as it stands you're unlikely to be a valuable asset to most teams working on non-trivial applications.
Chase Bonham
Ranch Hand

Joined: Jul 15, 2006
Posts: 50
Spring MVC is one of your choices. I checked out thid s link which shows a step by step approach to Spring MVC. This link is suppose to attract me to
using Spring MVC.

To show a JSP with a list of products and an option to update the price.
The tutorial shows the use of

a. Two XML files (springapp-servlet.xml, web.xml)
b. Four Java classes (,,, (Excluding test classes)
c. Now scale a) & b) for a medium sized project with 100 views.

and you are ok with that kind of maintainence?.

Why do you think RoR (Ruby on Rails) is getting to be so popular?
Chase Bonham
Ranch Hand

Joined: Jul 15, 2006
Posts: 50
I think you are mistaking the power of JSTL/EL and custom tag libraries. They can be written in a manner that promotes re-use and puts things in one place.
I'm not talking about having a sql statement be repeated in 2000 files.

I'm saying that you need just the view layer and hide the complexity of M through tags. You need a C (I like the pattern of a single front servlet for controlling security and all that), but to get that you don't need a heavy framework.

To change 2000 source files you need a good Perl script, not 10 people working 60 hr weeks.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
a. Two XML files (springapp-servlet.xml, web.xml)
b. Four Java classes (,,, (Excluding test classes)
c. Now scale a) & b) for a medium sized project with 100 views.

You'd still have 2 XML files, and quite likely a few dozen classes only.
First Spring MVC application I created had 5 views (page states).
It has only 3 classes and a single JSP.
Had I used your ideal solution I'd have 15 classes and 5 JSPs.
I agree. Here's the link:
subject: Which framework to use in web layer?
It's not a secret anymore!