Re: Re: Best practices in a thin-controller application

On Thu, Jul 24, 2008 at 11:02 AM, Don Zampano 
<don-+TOG+kmQGiFBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> wrote:
> real life objects are created and they live, there's not such a thing
> like persistance (just some places where they are e.g. embedded) or databases
> and in the end they are destroyed.

This brings up another question for me, especially after reading up on
the Data Mapper pattern one of you (Bryce, I think) suggested earlier
in the conversation.

Since persistence is such an important technical requirement in web
applications, it has to be handled somewhere.  However, there are two
requirements I've gleaned from this discussion and from Fowler:

1. A good domain model is unaware of its own underlying data source
(or even that it has one), and therefore cannot really be responsible
for its own persistence.
2. Code using the domain model (e.g., a controller action) shouldn't
really be aware of the technical details of persistence either.

Because of rule #1, implementing a save() method (or delete(), or even
load()) in the domain model itself seems inappropriate; it's not
supposed to know that it needs saving!  This would mean that
persistence needs to be handled completely outside the domain object,
by some sort of "Persister" that knows how to extract data from the
domain object and store it elsewhere.  This sounds a lot like a Data
Mapper, right?

But if we also abide by rule #2, we run into an additional issue.
Consider this controller action:

[code]
public function someAction()
{
    // The Mapper here is the only object that knows
    // anything about the underlying data source.
    $mapper = new Travel_DataMapper();

    // Use the mapper to retrieve an existing domain object
    $model = $mapper->findTrip(14);

    // Change some arbitrary data
    $model->traveler = 'Adam';
    $model->departure = '2008-09-01';
    $model->getDestinationByOffset(2)->country = 'MX';

    // Pass the modified domain object back to the mapper for persistence
    $mapper->save($model);
}
[/code]

This seems ALMOST correct to me, but I'm still not sure I'm entirely
satisfied.  The thing is, the controller is now aware of the
persistence layer, which seems to violate rule #2 above.

Then again, although the controller is aware of the persistence layer,
it doesn't know anything about the details of the persistence process.
 So maybe it's not the worst thing in the world...after all, it seems
like persistence in a web application is mainly necessary due to the
stateless nature of HTTP transactions, and HTTP transactions are the
bread and butter of the controller layer.

Anyway...I really appreciate the continued discussion here...we almost
ought to turn this into a tutorial, as it's probably the most helpful
conversation I've ever had about domain logic.  Even the philosophical
parts...turns out I actually have a philosophy degree, so that's right
up my alley :)

Thanks!
Adam