I just wanted to share some ideas on DataObjects design. I was trying to
solve the problem of persistence of *any* kind of Java classes, not only
the ones that inherit from our superclass. Original idea, as discussed
before, was to create an interface that custom classes should implement to
become persistent. This kind of did not work, cause the main problem was
notifying context about any changes in the object field values (or keeping
track of changes internally inside the object). This would have meant that
every "set.." method defined in the custom class had to generate an event
on every call. Basically we would have forced people to add extra code to
every "set.." method. This is much more complex and restrictive then
simply implementing an interface. So here is the idea:
We will have 2 types of data object classes :
1. Classes that inherit from the classes generated by our tools. All
persistent fields "set.." and "get.." methods will be part of the
generated superclass. The actual subclass will have any extra business
logic desired by user. This is a "normal" approach (used by EOF, etc.).
This is what we have in our original design.
2. (this is an interesting part)... Classes that have an arbitrary
superclass. To make them persistent, our tools will generate some sort of
"adapter" classes, that will keep a pointer to the original object, have
their own "set.." and "get.." methods that perform all necessary backend
job, and finally call corresponding method on the original object. This is
kind of like EJB (without remote method call overhead), when you write code
for one class, but work with objects of another "proxy" class. For example,
inserting new object in the context will look like that:
MyClass mainObj = new MyClass();
// initializing object fields BEFORE it became persistent
mainObj.setField1("1234");
MyClassAdapter persistentObj = (MyClassAdapter
)dataContext.registerObject(mainObj);
// initializing object fields THROUGH ADAPTER object
persistentObj.setField2("5678");
// initializing object fields DIRECTLY, AFTER it became persistent
// this may or may not work depending on implementation....
mainObj.setField3("901112");
// here all 3 fields (field1, field2, and field3) will be saved, and all 3
are directly accessible
// through both mainObj and persistentObj
dataContext.saveChanges();
I haven't tried all the scenarios with relationships yet, but this sounds
promising. As you see, we create an extra object for every data object, so
there is always a performance/memory concern. But in fact (if implemented
the right way), we can improve performance or make it the same as approach
(1) by pooling unused adapter objects somewhere in the DataDomain (say when
context goes out of scope, all adapter objects are cleaned up of their
state and returned to the pool). Custom objects creation will be faster,
since inheritance tree is smaller, and we are saving on repetitive creation
and garbage collection of adapter objects...
I can see how approaches 1 and 2 can be mixed in the same context easily.
Couple of things left to figure out:
- object identities
- relationships.
If you do not see any fundamental flaws with this model, I will try
implementing it both ways. This will give us some flexibility and also
allow to compare speed/performance numbers.
Andrei
This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 16:21:24 EDT