Persistence Strategies [Was: Open source WO - offer]

On Sep 5, 2006, at 7:31 PM, Lenny Marks wrote:
> Just to expand, the benefit of POJO model objects is in the fact  
> that they have no dependencies on the persistence framework(in this  
> case Hibernate), which means any business logic can be easily  
> tested with a Plain Old Unit Test in isolation without loading  
> configuration files or connecting to a database, or any other  
> complication.

I think the above is an argument for POJO vs. EJB. Not POJO vs. EO's  
or Cayenne DataObjects that are both actually POJO's from the unit  
testing perspective. I.e. if you manually inflate your object with  
test data values prior to testing the business logic, all ORM  
frameworks should work the same.

But not having a framework-mandated superclass can be good (or bad)  
in different situations, that's for sure. A framework superclass  
saves you time coding many things (and attach/detach thing IS  
annoying), but can have unpredictable consequences during  
serialization (e.g. when the objects have to cross the wire), and  
makes it impossible for another framework to dictate a superclass :-)

> Its also good for re-usability and maintainability not having your  
> business entity classes and business logic tied to a particular ORM  
> solution.

True in general. Still if you code your business logic only relying  
on public properties of the entities, the two approaches are equivalent.

> The reason you have to make sure the Hibernate session is either  
> closed or at least disconnected after each request is so the JDBC  
> connection is released. In EOF, you don't need to worry about this  
> because there is for the most part, a single open database  
> connection shared by all editing contexts across the entire  
> application or at least each EOF stack.

You don't have to worry about it in Cayenne either, and it is fully  
multithreaded with a connection pool (javax.sql.DataSource) behind it.

> Speaking of caching. As I mentioned above, this was another place I  
> found EOF to be flawed. Our experience wast that, EOF is great for  
> read mostly applications or single instance applications that  
> handle all database updates, or for applications without fresh data  
> requirements. IMO, EOF applications get way too complicated, if  
> this is not the case, for example if for whatever reason you have  
> database updates happening outside of your app(legacy system) or  
> because you have more than one instance of your app, or multiple  
> apps manipulating the same data, or whatever...

Stale data is a problem with any system that has a cache, period. Not  
sure how Hibernate implements caching, but if you refetch everything  
from scratch with EOF and/or Cayenne on every request, you get fresh  
data, if you don't - you can end up with stale data.

What EOF is missing is user friendly cache management facilities.  
Expanding on your point - one size doesn't fit all, so making it  
easier to implement alternative caching strategies is needed. Cayenne  
is half-way there - we are doing some work on it in 3.0.

> I'm not too familiar with Cayenne. We checked it out about a year  
> ago, but thought it might be a little too much like EOF

Not in the threading part ;-)

> and at the time did not support POJO's which have been of  
> substantial benefit. I'd be interested to here comments if Cayenne  
> addresses some of these issues.

DataObjects (and more so Persistent objects used in the remote layer)  
are POJO's, except for the framework callbacks in the set/get  
methods. We just need to replace them with runtime class enhancement  
(we still want lazy faulting and automatic reverse relationship  
connection/disconnection, don't we?).

Since we are targeting full JPA spec compliance, you'll see lots of  
things familiar from Hibernate (and TopLink) world - again, attach/ 
detach/getTransaction and other fun stuff.

Andrus