Thanks very much. I will look into the book and SODA. However, I'm confused about the need for "an abtract transaction mechanism". Isn't JTA just that?
-----Original Message----- From: Thomas Mahler [mailto:thma@;apache.org] Sent: Wednesday, November 13, 2002 4:37 PM To: OJB Users List Subject: Re: Patterns/Architecture info for OJB apps? Hi Jerome, 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. > 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 does support a DTO approach. OJB entities with lazy loading proxies can be serialized to clients without sending the whole object graph! OJB proxies are remote capable. > > 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. > Good O/R tools use abstract syntax tree based query frameworks. They are quite similar wrt. to structure. 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> -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
