It does seem like a pain in the ass, but your existing model is subject to
the same problems, isn't it? You're having to make changes in two places
when you add properties (Datastore.saveThingy() being the second place) and
your existing Datastore is Oracle-specific from the sounds of things.
The problem materializes with both models when you need database-specific,
entity-specific persistence peers. The "clean" way then becomes to abstract
out the database-specific details into utility classes which implement the
same interface, that your entity-specific persistence peers can use
transparently.
--
As an aside, TOPLink by ObjectPeople is a commercial persistence layer that
impressed me - they have a very helpful free evaluation program that
includes a full set of printed manuals, and technical sales people to talk
to. I can tell you more if you're interested.
Michael
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Hines, Bill
Sent: Wednesday, May 24, 2000 12:48 PM
To: [EMAIL PROTECTED]
Subject: Model 2: Persistence Layer?
In our current app, which we want to move to Model 2, we have packages to
hold model, view, and controller classes. The view package holds servlets
that emit html to build/handle the HTML. The model package holds "pure"
business classes, lightweight ones to represent Account, Product, Region,
SalesRep, etc. The controller package holds a Datastore class that handles
all interaction with Oracle for the app, as a persistence layer. An example
would be a methods like:
Datastore.saveCustomer( Customer customer )
Datastore.saveRegion( Region region )
The servlets call this in response to form submissions, etc. The pure
'model' classes of course, have no knowledge of the view or controller, they
are just passed around like a cheap prostitute.
How is the persistence handled in your model 2 apps? It seems that to follow
what may happen if we get to EJB, we need a persistence class for each class
in our 'model' package, such as AccountDB, ProductDB, RegionDB, etc. Then we
have two places to make a change if a class gets a new property, for
example. It is even more if we come up with another platform to persist to,
such as SAP or another ERP.
Is this the case? I'm looking for a clean way to handle this.
Bill Hines
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
