M. Fowlers latest book does contain a lot of persistence layer related patterns.
http://www.martinfowler.com/books.html#eaa
Jerome Jacobsen wrote:
Hi, My questions apply to any Java Object level persistence frameworks: OJB, TopLink, JDO, Castor,etc.Question 1: What patterns are used to hide the OID from the business layer? One suggestion I've seen is to define an interface for the persistent class which does not reveal OID accessors. However consider a common webapp workflow where the business layer does not hold onto the entity between requests. A first request might find the entity (not by OID). A second request may then want to update it. However it has to be found again. Now I don't know how the O/R framework querying works wrt caching. But I'm afraid that the O/R framework would have to hit the database again because the 'find' method didn't supply the OID. Am I misunderstanding how the querying/caching works? Are the frameworks smart enough to pull from the cache when given a query that doesn't contain the OID?
Yes, most of them are. (At least TopLink and OJB) So handling with OIDs is not really an issue. At least I did never come accross this problem.
OJB does support a DTO approach. OJB entities with lazy loading proxies can be serialized to clients without sending the whole object graph!Question 2: What patterns are used to hide the persistence framework from the business layer? Some people have the business layer use Session EJBs or some other type of Facade which deal in Data Transfer Objects (DTOs). There are two huge issues I see with this (but again maybe I misunderstand). First issue is that if the persistent object (and its lazily instantiated object graph) must be converted to DTOs then huge inefficiencies would result. The benifits of lazy loading are lost if the business layer ends up not using much of the object graph. Or do I misunderstand DTOs? Is the DTO supposed to be an adaptor for the persistent object (that is maybe it contains it). Is that right? If so, aren't DTOs commonly made serializable? Yikes, then we'd be materializing the entire object graph during serialization.
OJB proxies are remote capable.
Good O/R tools use abstract syntax tree based query frameworks. They are quite similar wrt. to structure.The second issue concerns flexible querying. If I'm hiding the persistence framework then I'm hiding its query framework (e.g. JDOQL, EJBQL, ODMG OQL, OJB query by criteria, TopLink query framework). If all my queries are finite and/or simple this wouldn't be a problem. However for apps that need flexible querying I can see two solutions, both of which I don't like. One is to create my own querying framework which hides the actual one being used. This is a huge task of reinventing the wheel just to decouple the business layer from the persistence framework. A second solution is to just reveal the query framework. However now my business layer is not decoupled from the persistence framework. A middle ground might be to create a simple query by example API hiding the actual query framework.
Thus it is not difficult to write a simple AST query framework with translators for the target O/R tools.
We have sucessfully done that in a business framework in my company.
Our framework also provides an abtract transaction mechanism that hides the tool specific tx managers.
(Such stuff is also covered in Fowlers book.)
A good start for a an AST query frame work is SODA, as it aims at a standardized query representation (http://www.odbms.org)
Well, if you've gotten this far thanks for reading. I'd appreciate your insight/experiences.
cu, Thomas
-Jerome -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
