• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Object Persistence (Materialization & Dematerialization)

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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:

    1. How object-oriented is this approach? Seems more like database-oriented programming to me.
    2. 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.




    3. Can anyone shed some light on this topic?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic