I guess there is a mix of intentions here :-)... The main one being
simplification of the DataObject API. Designing client-side objects
just happened to be a good occasion to do it. When I started designing
client-side DataObject, I realized that if it works, there is no reason
not to use it on the server as well, and it will probably be much
cleaner than current CayenneDataObject.
As for splitting client and server objects... At the minimum I am
planning to start with support of split classes (with remote method
call capability), and later add cross-tier same DataObject (Persistent)
class functionality. In the interim I suspect that it won't be too hard
to make CayenneDataObject implement both Persistent and DataObject, so
the same set of classes will be an option, maybe with some class
generation tricks...
Andrus
On May 17, 2005, at 8:42 PM, Derek Rendall wrote:
> Is the intention (when merge the DataObject and Persistent approaches)
> to return to a single inheritance structure for client and server
> domain classes? At the moment I am concerned with having two sets of
> classes (one server and one client). If we want to add general domain
> logic then we would have to add them in both places?
>
> Then again, the splitting of classes does allow us to have control
> over client/server variations/accessability to the domain logic.
>
> I can see potential for moving away from objects having data and code
> to a case where code that is common to server and client gets removed
> from the domain classes and put in a domain "helper" type class. Are
> there any thoughts on managing/avoiding this?
>
This archive was generated by hypermail 2.0.0 : Tue May 17 2005 - 22:01:59 EDT