Dear All,

I am currently in the process of taking up an M.Sc., and hope to be focusing greatly on Persistence Frameworks. I have been scouring the Internet for information on PFs, and as you may understand, the quality of the information varies greatly.

I am looking for papers, thesis, research / reference material, links, or any material that would help me construct a hypothetical persistence framework and/or draw up a theoretical requirements analysis for such framework. I am therefore trying to find out what actually constitutes such a framework, and would like to know whether set standards already exist, what are they key elements and considerations (transactions, connection pooling, lazy reading, proxies / cursors, etc), and whether these would be applicable to heterogeneous database connectivity, MDBMSs, and so on.

Any information, from basic to leading edge, would be greatly appreciated.

Thanks
Adrian

this is a good one:

http://www.chimu.com/publications/objec ... tional.pdf

and Scott Ambler's book "Object Relationsl Mismatch" offers good discussion points.

-devon

Hi!
Take a look at:
http://en.wikipedia.org/wiki/Object-relational_mapping

also at:

http://c2.com/cgi/wiki?ObjectRelational ... isonDotNet

and, to my other favorite (IMO the best two are Hibernate and EOF, I think a mix between them could create "the ultimate" ORM... or the ultimate BEM?)

http://en.wikipedia.org/wiki/Enterprise ... _Framework (general overview)

http://developer.apple.com/documentatio ... e_Objects/ (Manual)

An interesting topic for analisis could be the limits between an Object Relational Maper and an Bussines Entity Manager. Some people think that Hibernate shouldn't evolve to become more like EOF, because it should aim to do one and only one thing (be the best ORM) and other people think that it would be nice to have the services that an Business Entity Manager gives you (like automatic connection handling, automatic transactions handling, multiple undo levels, real nested transactions, client and server objects, distributed non-transactional lazy loading, etc).

There are also some people that think that a Bussines Entity Manager is more closer to the MDA "objective", so I think you should take a look at http://bdn.borland.com/article/0,1410,30375,00.html (Using Borland's ECO to develop model-powered applications for .NET) an many related articles: http://bdn.borland.com/delphi/eco the specially interesting thing for me about ECO is its OCL support (that can be used, for example to configure constraints that help ensuring that only consistent data is saved into the database... it is kind of a Design by Contract ( http://archive.eiffel.com/doc/manuals/t ... /contract/ ) for the domain model)

IMO the ActiveRecord pattern ( http://www.castleproject.org/index.php/ActiveRecord ) is getting too much popularity (perhaps thanks to Ruby, but I think it leads to an anemic domain model) and Domain Model based in Bussines Entity Managers is not as popular (thanks to the problems in EJB1 and EJB2) but it is important to remember that EJB is not the only way to build an Bussines Entity Manager, there are ways to build Business Entity Managers that are a lot more lightweight and user friendly than EJB, (just investigate more about EOF and ECO)

Interesting related discussions:
http://forum.hibernate.org/viewtopic.ph ... ic+anaemic
http://forum.hibernate.org/viewtopic.ph ... ic+anaemic
http://forum.hibernate.org/viewtopic.ph ... highlight=

An interested related question I have always had is:

Some people think that DataBinding? to the UI is orthogonal to ObjectRelationalMapping. In .NET case if an object implements the interfaces from the System.ComponentModelnamespace it can be bound to a WinForms or ASP.NET user interface and that's a separate issue from whether it can be transparently persisted to a relational database....

But I disagree... http://forum.hibernate.org/viewtopic.ph ... ic+anaemic

Thanks very much for your valuable feedback so far. Keep them coming, the more the better. Especially papers, research articules, thesises, and the sort.