There one more thing:
I think, in addition to an own superClass for DataObjects
it is a good idea to have an own Velocity template
for class generation ... so life can bee much more easy ...
cayenne-use..bjectstyle.org schrieb am 17.02.05 19:49:06:
>
> I'm actually leaning towards something like this:
>
> CayenneDataObject ->
> MyBaseDataObject ->
> _Company ->
> _CompanyValidation ->
> Company
>
> Of course, the three "Company" classes would most likely be in separate packages (maybe more like com.foo.auto.Company, com.foo.validation.Company, com.foo.Company), but near each other. I can't imagine ever wanting to not be able to re-generate my classes. I agree with you that it is no fun to wade through boiler-plate code when you don't have to and I do like having the functional separation. Note that the validation layer can be slipped in whenever needed. Just add the validation class (subclassing the auto class) and re-direct the terminal class inheritance.
>
> /dev/mrg
>
> -----Original Message-----
> From: Bryan Lewis [mailto:brya..aine.rr.com]
> Sent: Thursday, February 17, 2005 12:19 PM
> To: cayenne-use..bjectstyle.org
> Subject: Re: Modeller Question
>
>
> Yep. In my superclass (named "ModelObject") I have little convenience
> methods like isPersistent(), isModified(), hasProperty() and resolveFault().
>
> The term superclass is a bit overloaded here. There are several levels in
> the DataObject hierarchy -- CayenneDataObject, your root superclass (like
> ModelObject or GenericDataObject), each entity's superclass (such as
> auto._Company) and the entity's terminal class (such as Company). I've
> found that this works great because I can put my entity-specific business
> logic (like company.isInternational()) in the terminal class where it's
> naturally reusable by any other code dealing with the entity, but still
> keeping a clean separation from the database-level accessors.
>
> This reminds me of a seminar by Bruce Tate that I attended at the NFJS
> conference last year. (He was talking about Hibernate but the concept's the
> same.) He recommended turning off the entity-super-class generation once
> your model has stopped evolving and you were no longer regenerating the
> classes. He didn't like having two places to look for a method. That
> doesn't sound practical to me. For one thing, our model never stops
> evolving. (Although it's true that you can handle small changes with manual
> editing, not regenerating from the modeler.) And I like having that
> separation... I don't have to search past a bunch of read-only boiler-plate
> code when I'm tweaking the biz logic.
>
>
> ----- Original Message -----
> From: "Jürgen Saar" <jsaa..eb.de>
> To: <cayenne-use..bjectstyle.org>
> Sent: Thursday, February 17, 2005 6:50 AM
> Subject: Re: Modeller Question
>
>
> > It is right, that the cayenne classes get richer and richer,
> > but it is allways a good idea to build a own
> > base class for the business objects to be a
> > little more independent from the changes
> > of the cayenne classes ... In my case I
> > have a special support for transient informations
> > in my business object class.
> >
> > cayenne-use..bjectstyle.org schrieb am 17.02.05 01:42:21:
> > >
> > > Fredrik Liden <flide..ranslate.com> wrote:
> > > > Also, what is the purpose of the DataObject Superclass field that can
> be
> > > > set under the maps?
> > >
> > > You can set a superclass for all of your DataObjects. For instance I
> have
> > > GenericDataObject set as my superclass and it contains a variety of
> > > convenience methods [DataObject getLocalObject(),
> > > objectMatchingPrimaryKey(), primaryKey(), and so on] that each of my
> > > DataObjects use.
> > >
> > > Ironically, most of those functions are now available directly in
> Cayenne,
> > > but at the time, they were all local patches :)
> > >
> > > -Mike
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
This archive was generated by hypermail 2.0.0 : Fri Feb 18 2005 - 02:19:23 EST