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? 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. 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. Well, if you've gotten this far thanks for reading. I'd appreciate your insight/experiences. -Jerome -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
