don't fall off your chairs...

re: " I have in the past had long debates over whether or not the domain
object should know about persistence at all."

but i have *successfully abused inheritance* in the past to achieve an
interesting mix (for thin client/web apps).

* Xyz Domain Class
o can live on server or client
o has the usual: properties and accessors
o business methods
o associations to other objects
o often employs lazy loading
o knows NOTHING about DBs
* Xyz Business Class
o *INHERITS* from the Domain Class
+ Gets all of the class properties that way :-)
o Knows about persistence classed (DGs/DAOs)
o has the persistent ID
o can get itself from the DB via an ID
o can save() itself to DB
* Xyz Transfer Object
o small thing to meet some need of going between UI and server
o used typically when the Domain Object is too big and you
want specialized sets of properties filled in
* Xyz Identifier Class
o really tiny thing
o usually just an ID and a string
o sometimes a few other things
o used for lightweight lists of associated classes
+ to drive drop-downs
+ typically used in conjunction with lazy loading

<gulp> there, i've confessed.

jon
blog: http://technicaldebt.com



Paul Oldfield said the following on 4/7/08 4:42 AM:
>
> (responding to John
> >
> >
> > I think it's never a great idea to embed persistence in domain
> > objects. Sometimes I have done this, merely as a convenience
> > when the application was small and there was no need for
> > long-term maintenance or expansion of functionality. But
> > generally, persistence should be separated from the domain
> > objects, because it leads to loose coupling, and a cleaner
> > and more flexible design.
>
> Agreed. I advocate encapsulating persistence, but not
> embedding it. The Strategy pattern allows me to do this.
> I hope you understand the distinction...
>
> Domain Object: "Here's my object that deals with all
> my persistence needs. I don't know how it does that: I
> don't care. But I don't want anyone else to get to talk
> to it; who knows what they'd do?"
>
> I have in the past had long debates over whether or not
> the domain object should know about persistence at all.
> I'm not convinced there's a right answer, or if there
> is I haven't come across it yet. I always choose an
> approach that works in the specific context.
>
> I've dabbled with compound objects that implement the domain
> object interface and also a transactional interface; I
> like this approach provided I can auto-generate the code
> for all the classes of compound objects I'd need. Aspect
> Oriented programming might help here - I don't know enough
> about it to say either way.
>
> > A File object is fundamentally a data object. It should
> > not contain services for interacting with the file system.
> > A file system is a manager of files, which provides a
> > bundle of services for discovering and manipulating files.
>
> I disagree. The term "File" comes from a domain that is
> about information storage. A File belongs on a filing
> system. We choose to put information in a File because we
> want to be able to store it. I agree that there are also
> data objects that should have no need to interact with
> the filing system. We put these data objects into a file
> when we want to store them in a filing system.
>
> > Test-driven development leads to the proper design, because
> > person.persist() does not suggest an obvious way to test
> > for the expected functionality, but
> > PersistentService.persist(person) does, because through the
> > persistence manager, you can check to verify the person was
> > actually persisted.
>
> I think about this in a different way. You might not agree
> that it's better, but it works for me. I think of a real
> world object as something that intrinsically persists. I
> think that any change to the data of a computerised object
> representing this real world object should persist by default.
> The object can, of course, know when its data has changed.
> It can ensure that these changes persist without needing to
> be told to do so.
>
> The problem arises with Transactional sytems, where we want
> to ensure that the model of the real world does not get
> out of step with the real world... say by one account taking
> in some money without the other account releasing hold of
> it. Real world? Think of two hands both holding on to
> the same gold coin... With Transactional systems we need
> all parties to the transaction to agree that the transaction
> has, or has not, taken place. Some people choose to do this
> by exposing aspects of the persistence of objects.
>
> The rest is down to design solutions that try and optimise
> the relatively high overheads of communicating with any
> persistant storage.
>
> And anyway, the only real test of Persistence is to turn
> the system off and back on again.
>
> > I don't see how this issue has anything to do with
> > polymorphism...
> > ... Traits, duck typing, and
> > delegation address the problem in a maintainable way.
>
> Hmm... I view inheritance and delegation as alternate ways
> to implement polymorphism, but maybe I'm out of step with
> common usage of the term?
>
> Paul Oldfield
>
>