Re: Best practices in a thin-controller application

Hi Adam,

Adam Jensen wrote:
> 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.
>   

This is where the philosophy part comes in to play: your rule #1 
precludes perfectly valid patterns, such as Active Record, that "know" 
something about the data source structure. You have to decide based on 
your own philosophy, the app's requirements, and the trade-offs of 
different data source strategies, which approach is really the most useful.

> [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.
>   

To me, this doesn't violate rule #2 (based on my very superficial 
knowledge of what you're trying to achieve). Here, the data mapper has a 
fairly abstract interface that doesn't appear to tie you to any specific 
data source structure other than one identifying Trip objects by an 
integer. This would probably be flexible enough for most of the examples 
I've seen so far in this thread.
> 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.
>   

I agree: in MVC web applications, I think the controller's main job is 
to translate HTTP requests into some form of request upon the 
application's domain model, and then to express the domain model's 
results as something meaningful in HTTP. This means managing the 
interaction with domain model objects, and persistence is still part of 
the model layer.

That said, if you want, you can use something like a Service Layer [1] 
to cleanly separate the HTTP-specific code from the domain-object 
management code. Use the Service Layer as a facade to create a very 
coarse API that would roughly correspond to what each controller action 
needs to do with the domain model. You'd have to decide if this would 
really be worth the effort for your application.
> 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
>   

Hope this helps,
Bryce Lohr

[1] http://martinfowler.com/eaaCatalog/serviceLayer.html

August 1st is National Minority Organ Donor Awareness Day