[Dev] Transparent persistence

[patrickdlogan at attbi.com]

On Wednesday, April 16, 2003, at 10:00 AM, rys wrote:

> transparent persistence
>
> http://www.service-architecture.com/object-oriented-databases/ 
> articles/transparent_persistence.html
>
> This page echoes John Anderson's sentiment that using transparent  
> persistence will
> result in needing to write less code. It also says performance is  
> higher. (I'd be
> interested in Patrick Logan's reaction to the statement.)

 Transparent persistence sure does result in less code. That is the  
 first and most striking aspect of OODB adoption.

 "Performance is higher" is a pretty broad statement however, to which  
 the only sane response is, "It depends."

 Depending on the scenarios you want to support, you may end up writing  
 and debugging a lot of code to *implement* transparent persistence in  
 order to reduce your application-level code and keep its performance  
 where you want it.

 Cache, the source of the reference is an interesting example. It is  
 based on Pick, which is something like 20-25 years old. There is a lot  
 of experience behind their architecture. I don't think Cache is free  
 for use in Chandler.

 Transparent persistence and multiple users complicate the design.  
 Transparent persistence and large volumes of data complicate the  
 design. Writing less code can be achieved in other ways, and in  
 general keeping the data interface factored out of everything else.

 Decisions can and should be delayed as long as possible.

 The nice thing about transparent persistence is it is, well,  
 transparent. So your code is not making a commitment to some other  
 model that you might have to back out of. A key way of keeping the  
 code factored away from the data interface is to be event driven and  
 "higher order" in the sense that the code is passing higher order  
 functions and objects into aggregate abstractions as opposed to  
 pulling individual objects out of that aggregate into the application  
 for one-by-one operations.

 Designing good objects, abstract aggregates, and simple code in  
 general in the application will enable choices and adjustments in the  
 persistence interface. Let the decisions back there emerge as you  
 implement application space features.

 Hope this makes sense and helps.

 -Patrick