My 2 cents: Struts is a good framework, and easy to work with. However, I have reservations (others may or may not agree entirely), when it comes to the MVC-part. As you have mentioned, certain practices "force" you to end up coupling the View and Model quite closely. It would be possible to try and reduce this coupling, but that definitely needs some hard-work on the developer/designer's part.
If you have heard of Velocity, and the VelocityStruts project on Apache, my choice has - and would be - to use Velocity as the presentation layer. The biggest benefit of this is it makes it much harder for one to deviate from the MVC paradigm - that is, one has to think in order to break this (as compared to one has to think hard to enforce it with Struts/JSP), leading to a simpler, and more OO-implementation. Velocity is also much simpler to use and implement. As someone already mentioned, it is probably more important to think of maintainability than anything else. Performance can always be tweaked and achieved. The other "drawback" of a JSP-application tends to be: The original developer knows what's being done, what's put in the session/application scope, etc. But, 6 months down the line ... Boom! You can't figure it out, unless its *really* well documented. Velocity may not be entirely avoiding this pitfall, but it simplifies this, and thus reduces problems arising out of such design/implementations. Cheers, Saurabh Bobde ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "DISCLAIMER: The information contained in this e-mail message may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. Zensar Technologies Inc. does not accept any liability for virus. If you think that you have received this e-mail message in error, please delete it and notify the sender." -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard O. Hammer Sent: Saturday, April 23, 2005 7:28 AM To: Java Users Group Cc: [EMAIL PROTECTED] Subject: [Juglist] MVC pattern strain I am working on a rewrite of the jobs-posting application at <http://trijug.org/jobs.jsp>. This is my first application using Struts. I'm trying to be a good MVC boy scout, separating the View (JSPs, tag libraries) from its Model (database and JavaBeans). But achieving this separation seems to necessitate extra coding and computation, unless I am overlooking something. I write for input. Consider the question of how to deliver a set of job listings into the JSP which renders the listings. Each job listing occupies one record in the MySQL database. So somewhere the code will iterate through a ResultSet. With good MVC separation I suppose this iteration through the ResultSet would occur in the Model. With good MVC separation I suppose the View would never contain a statement like: import java.sql.ResultSet Have I got that right? What seems required then is that the Model would iterate through the ResultSet, packaging the data probably into some Collection which will be passed to the View. The View then would have to iterate through this Collection in order to generate the needed HTML. As such we iterate through the list twice, once in the Model and once in the View. Whereas in a simpler world it would be acceptable for the JSP which generates the HTML to be handed a ResultSet through which it would iterate. In this simpler world there would be only one iteration through the list. Interestingly, something like this is done in the sample application for the book _The Struts Framework_ by Sue Spielman. The book starts out with a chapter about MVC and separation. But the sample application has a custom tag -- part of the View -- which does all the work I would expect to see in the Model (all the java.sql, Connection, Statement, ResultSet stuff). Am I learning a simple truth, that the benefit of separating responsibilities into tiers can be gained only by paying the cost of duplicate handling of data? Or is there something I'm missing? Thank you, Rich Hammer Hillsborough _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
