File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JDBC and the fly likes Object Persistence (Materialization & Dematerialization) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Object Persistence (Materialization & Dematerialization)" Watch "Object Persistence (Materialization & Dematerialization)" New topic
Author

Object Persistence (Materialization & Dematerialization)

Kai Tan
Greenhorn

Joined: Oct 08, 2001
Posts: 1


I've encountered some issues with mapping my objects to an RDBMS and am hoping for some advice.


I've tried various O/R mapping frameworks like Castor(too complex and too slow for my liking), JRF(nice but very repetitive and difficult to extend) and then some, but have yet to find one which I'm comfortable with building an application on.


Instead, I've chosen to do it the low-tech way, with each domain class, say Book for instance, having a Broker class which knows how to communicate with the chosen form of persistence. So, since I chose an RDBMS, Book class has a BookRelationalBroker class which knows how to materialize and dematerialize Book objects to and from a RDBMS. If so required, I can plug in a BookXMLBroker which knows how to serialize the object in the form of an xml data file.


I've also implemented a primitive object caching system which (when enabled), caches objects requested so we only have to materialize it from the db once.


Here are 2 issues I have with my system:

  1. It is amazingly tedious (not to mention inefficient) to recreate the entire object from the database. This is even more so because I've implemented the Event Notification pattern, such that when say a book is deleted, the members who have reserved it are notified. The whole point of the Event Notification mechanism is so that the object being watched does not need to know of the objects which need to be notified on a state change. However, I've found it necessary to re-attach all the listeners on an object when it is materialized from the DB, defeating the purpose of the pattern.
  2. Complex object relationships are mapped poorly and recursive materialization leads to slow response times. If a Group object has a Vector of Members and other Groups, then whenever a Group object is materialized, all its constituent Members and Group objects also need to be materialized. (I understand O/R frameworks solve this through lazy instantiation)


    I studied the Jive2 architecture and found that they approached this problem by accessing the DB directly for any complex object relationships. In other words, the Group object does not actually contain a Vector of Members and Groups. Instead, it has a method called say getMembers() which proceeds to retrieve the necessary data from the DB and then materialize these objects.


    I'm not too excited about this approach for 2 reasons:

  3. How object-oriented is this approach? Seems more like database-oriented programming to me.
  4. Every call to retrieve Members necessitates a call to the DB. The data isn't cached with the Group object because the Group object does not actually contain the necessary reference to the Members and Groups.




  5. Can anyone shed some light on this topic?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Object Persistence (Materialization & Dematerialization)
 
Similar Threads
Domain Layer dependancy confussion
OutOfMemory Error
Longer Post - ALL IBM ICE EXAM Q's for UML
Answers to IBM 486 sample test
UML Sample testing questions