Mike is already already aware of this but I'm repeating it for the sake
of others on the list... I do the same but use a delegate approach
instead. Using "Theme" as a basis for my example...
Classes:
CayenneDataObject -> MyBaseDataObject -> generated._DefaultTheme ->
delegates.DefaultTheme
user.DefaultTheme extends user.Theme
where _DefaultTheme resides in a "generated" Java package and
DefaultTheme resides in a "delegates" package.
then I define DefaultTheme extends Theme, two completely different
classes which reside in a user-space package. So from the user's point
of view, they're playing around with user.Theme which is really
user.DefaultTheme which contains delegates.DefaultThem. When a call
comes into the Theme, it passes it on to the underlying delegate.
This allows me to deliver completely clean classes to end-users while
maintaining full access to the underlying database objects.
my userspace/wrapper classes have two constructors:
user.DefaultTheme() // wraps an unregistered delegate
user.DefaultTheme(delegates.DefaultTheme) // wraps a preexisting delegate
and users can invoke getDelegate() on the wrapper to get at the
underlying delegate. The only time they actually need to do this is when
registering the object-graph root object.
Anyway, I am just presenting this as an alternative approach. I know it
looks like more work but I personally prefer it because I prefer the
extra encapsulation.
Gili
Mike Kienenberger wrote:
> Based on previous difficulties with unit testing and representing
> transient instances of a DataObject, I've worked out some templates to
> generate interfaces as well as Cayenne implementations of my
> DataObjects.
>
> Ie, I have these object hierarchies:
>
> Classes:
> CayenneDataObject -> MyBaseDataObjectImpl -> _DataObjectImpl ->
> DataObjectImpl
>
> and
>
> Interfaces:
> MyBaseDataObject -> _DataObject -> DataObject
>
> where each *Impl object implements the corresponding * interface.
>
> I'm curious to know if anyone else has tried to do something similar.
>
> A couple of things I've noticed so far are that I need to convert from
> an interface to a DataObject when working with relationships. I
> don't see that as a big deal since trying to mix a nonDO with a DO is
> an error anyway.
>
> public void setContent(Content content) {
> setToOneTarget("content", (ContentImpl)content, true);
> }
> public void addToViewpointList(Viewpoint obj) {
> addToManyTarget("viewpointList", (ViewpointImpl)obj, true);
> }
> public void removeFromViewpointList(Viewpoint obj) {
> removeToManyTarget("viewpointList", (ViewpointImpl)obj, true);
> }
>
> I'm also copying each of the static property strings from the
> interface to the class:
>
> public static final String VIEWPOINT_LIST_PROPERTY =
> _Announcement.VIEWPOINT_LIST_PROPERTY;
>
> public static final String ANNOUNCEMENT_ID_PK_COLUMN =
> _Announcement.ANNOUNCEMENT_ID_PK_COLUMN;
>
> Anyone have any comments on this approach?
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 14:49:41 EDT