RE: Separation of Objects from Logic 2004-12-11 - By Philip Nelson
--- Terry Voss <tvoss@(protected)> wrote:
> Phil,
>
> I use #1 because I want each class responsible for the proper things,
> itself. My #1 classes have load, save, and delete and are subclasses off
> another layer.
The encapsulation points have been well made here so no need to rehash. I have
been thinking long and hard about this basic topic lately myself. For me,
what's at issue is where the CRUD methods and other data access needed for
reference types or collections should go. First off, here is a blog with
pointers too other blogs that argues and tries to solve some key problems.
http://www.jnsk.se/weblog/posts/dddstyle2.htm
In Jimmy's terms, you would use a CustomerRepository to save a customer, more
like Plip's #2, and less like an ntier with a DAL layer that knows about your
types. The discussion is about what to do when the Customer contains an Order
which in turn has it's own CRUD.
Here is a quote from the referenced blog by Steve Maine
"The red flag for me is the implication that the Address entity object needs to
implement a Save() method. One of the principles I took away from Domain Driven
Design is that entity objects don?t expose their own lifecycle management.
Instead, that responsibility is handled by their associated Repository class.
|
|
