MVC JSP and Servlets

Question

I'm creating JSP pages to represent the view of the site and servlets to get the request and decide which JSP page to load next.
When the servlet recibes a request it generally has to query the database to get some data and then show it back to the client. To do this the servlet calls other object that is responsible to query the database and fill a ResultSet.
My question is: what is better, to load a Vector with special objects containing the data in the ResultSet and then return this vector to the jsp page for it to use it, or may a return directly the ResultSet to the jsp page? With the first option I have to cycle in the resultSet to load the vector and then cycle through the vector to show the results. With the second option I cycle only once, but I isolate from the database (column names, order in which the things are returned...)
I hope anybody can give me an opinion.
Thanks

Answer 1

There are a few things wrong with this:
1) MVC -> The View should have no Model work init.
For the MVC pattern, the database is Model. Use
a
a ResultSet in JSP, and now your View is lockedto
a
database with a specific column format.
Huh? I think that's backwards. The View willalmost
always require Model data unless it is a staticpage.
The Model, however, should be agnostic about what
t View technology it serves. (The Controllerbridges
the two). Also, I would call the database the
Persistence or Integration tier, a separateconcept
from the Model, though intimately coupled to it.I meant the work of the model (gathering the data to
a presentable form) is moved to the View. Yes, the
View needs to know the Model to be able to display
its data. But the Model should handle the data
collection.
Fair enough. I might have read it backwards as well.
>>
2) Any web application (or any application in
general) wether it uses MVC or not, should still
follow a 3 tier approach: Persistance (Data),Domain
(logic), Presentation (View, output) (note, thisis
different then MVC.) By moving the ResultSet inthe
JSP you would be dragging the Persistancemechanism
up two layers. Generally, a layer should only
see
the layer just below it (Presentation seesDomain.
Domain sees Persistance. Persistance never sees
s Domain or Presentation. Domain never sees
Presentation. Presentation never seesPersistance).
>
I agree that Persistence and View should not seeeach
other. However, Model and Persistence must. How
else do you write a DAO? Or even use a mapperlike
Hibernate?First the Model doesn't fit into just one of the
three tiers (Persistance Domain and Presentation).
The Model of MVC is both the Domain logic and the
e Persistance mechanism.
To me, at least, Domain logic = model. The terms I have normally read is either "business tier" or "model domain". "Patterns of Enterprise Application Architecture", M. Fowler. Though, I will concede that this tier has the least well defined set of terms.
But for the three tier architecture: the domain sees
the persistance. You always see one layer down. So
Domain sees the persistance and pulls the data into
the model. So a DAO would be part of the Domain, the
logic of collecting the data from the database to be
used in the application (in the correct object graph
and all that). The persistance though, doesn't see
the domain.
Hmm, I'm not sure which direction 'down' is. And even if 'down' meant towards the back-end or away from it, what about the controller? It parses view requests and delegates them to the model. The results are then normally returned to the controller for dispatch to a view. So, the controller seems to have its fingers in all the tiers except integration and persistence, at least to me. I think of the controller as the 'middle man' between model and view that lets the model be agnostic to the view. The view and controller will to some extent always be coupled. However, the model theoretically exists on its own.
Half of me thinks that I have a different view on
where the Domain and Persistance border is. I
thought the DAO or the Data Mapper would be in the
Domain, whereas you seem to be saying they are in the
Persistance layer?
That's interesting. I don't know if there is an absolute answer. We are dealing with the O/R boundary, and the DAO straddles the boundary. However, one could, at least theoretically, change persistence strategies. What would change? Not your model objects, but your persistence tier objects. Though, again, the definition is nebulous.
3) From a Practical matter:
In many DBs, if you close the connection fromwhich
the ResultSet was derived, the ResultSet is
closed
and you get errors if you try to access it. Ifyou
don't close the connection in the Servlet beforeyour
JSP, then you have to do it in the JSP. Thatmeans
even more DB bleed through to the JSP, and theM->V.
Or, you could just not close the Connection and
d allow it to hang around and create memory
leaks.
>
Yepper.
4) Also practical:
To use the ResultSet in JSP is going to require
scriptlet code. This is ugly and hard to manageand
update later. You have to wrap your code in
try{}catch(SQLException e) {} finally {}, so
the
code is even uglier and harder to manage(especially
if you end up not touching the thing for monthsand
forget what you had done - or god forbid someoneelse
has to keep up your code). You could make acustom
tag to handle it, which makes the JSP easier toread,
but does further damage of spreading the dataaccess
code all over the application.
Definitely!
5) Practical:
When you do this sort of thing, then later
decide
to
change the way the database is set up, digging
all
the places affected by the simple renaming of a
column, or refactoring of which columns are inwhich
tables becomes a heavy effort. Keep it all in a
DataAccessObject, and changes in DB becomestrivial
to keep track of in your code. It is all in one
place, and can be tested off line. Harder stillis
if you change persistance from a database to anXML
library, or some directory lookup or something.You
would have to completely refactor your Servlet
and
your JSP. Put it in a DataAccessObject and allyou
have to do is switch out the DAO instance. The
change is transparent to the Servlet and the JSPas
long as you maintain an interface.
Just keep in mind that for the vast majority of
projects, the RDBMS technology is rarely switched.I
generally program to interfaces in my Model, butmy
Persistence tier is always so tightly coupled thatI
simply use POJO's without an interface.
6) Practical:
I have elluded to this several times, but I will
state it specifically. When you isolate the
persistance and data access to its own layer
then
you
can swap out the presentation (the View and the
Controller) when testing all your persistance
operations. This means the data is independent
of
the container. You can run it out of theServlet/JSP
environment and it will behave EXACTLY as it
will
inside the JSP environment. You can designrobust
tests, debug, redesign, re-edit, etc... muchquicker.
Then, when all done, plug it into your web app
p without worry.
Great point.
Of course, Numbers 3 -> 6 are the reasons why
following 1->2 (MVC and the 3 Tier architecture)are
such good ideas.- Saish
BTW, please take all the above just in the interest of having a good discussion. I have been wrong many times before! ;^)
- Saish