Richard O. Hammer wrote:
With good MVC separation I suppose the View would never contain a statement like:
import java.sql.ResultSet
Have I got that right?
Generally speaking, I'd say yes. If the View element (Jsp or what have you) imports java.sql.ResultSet, it introduces unnecessary coupling
between the View and implementation details of the Model.
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.
That's pretty much what I've always done. Iterate over the ResultSet,
creating a ValueObject or Bean of some sort for each record, and inserting each record into a Collection, such as an ArrayList.
So yes, in a sense the data is being "touched" twice, which may or may not be a big deal. If you're concerned about performance, keep in mind that, depending on the scenario, you may be able to cache the Collection of VO's and reuse it without rebuilding it again. So the cost of building it is amortized over all the hits to whatever page displays the data, and the average cost of listing the data approaches the cost of only iterating over it once.
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.
Acceptable is a relative term. Having the View elements deal with the ResultSet directly might be advantageous in some regard. The question then becomes, do those advantages outweigh the disadvantages.
At the very least, I would argue that you would be making the system more difficult to maintain - by at least a small margin - using the ResultSet directly in the View.
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?
I don't know that generalizing to "the benefit of separating responsibilities into tiers can be gained only by paying the cost of duplicate handling of data?" is *always* true, but there is a cost associated with layering and following Separation of Concerns, etc.
Or is there something I'm missing?
Premature optimization is the root of all evil? Make the program correct and maintainable first, then worry about performance if it's problematic? Don't trust any assumptions or assertions of others regarding performance, benchmark it yourself if you want to be sure.
FWIW, my experience developing server-side Java, web-based applications, using Struts and JSPs, etc. is that the benefit of making sure to separate concerns and isolate the Model / View / Controller components is worth it. The code becomes, IMHO, much cleaner, more understandable and easier to maintain.
Anyway, that's my $00.02 worth... HTH.
TTYL,
Phil -- North Carolina - First In Freedom
Free America - Vote Libertarian www.lp.org
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
