2008年7月29日星期二

Re: [fw-mvc] Best practices in a thin-controller application

Hi Marian,

Certainly, PoEAA has been an extremely helpful resource for me, but
beyond that, most of what I've gathered has been scattered across blogs
and articles over time. There are a few books, such as Data Modeling
Patterns by David Kay and Domain-Driven Design by Eric Evans, that are
on my to-buy list, but I haven't bought them yet. :)

Regards,
Bryce Lohr


Marian Meres wrote:
> Hey Guys,
>
>> as it's probably the most helpful conversation I've ever had about
>> domain logic.
>
> I absolutely agree and I just don't want this thread to end...
>
> Besides already mentioned Martin Fowler's book (just bought it), what
> books/resources would you suggest are worth reading on this subject?
>
> Ideally something more conceptual/philosophical (rather than too
> concrete, with some examples though), web application oriented if
> possible... (I have not "googled" anything yet.)
>
> Thanks again for inspiration.
>
> Regards,
> Marian
>
>
> On 28.7.2008 18:54, Jonathan Lebensold wrote:
>> Hi Adam,
>>
>> I've found that the Repository Pattern (PoEAA) has done me a lot of
>> good in medium-scale projects. When you might have a complex
>> underlying data model (with 1-m m-m and 1-1), it doesn't make sense
>> to expose multiple aggregate roots (ways of persisting) since it
>> complicates the interaction between the controller, which is
>> interesting in client interaction, and the persistence of data.
>>
>> I start out by identifying aggregate roots and create repositories
>> around them. These repositories serve up data transfer objects (which
>> can be Doctrine or Zend_Db data objects) and then persist them.
>>
>> The big advantages to this approach are thin controllers and
>> transactionality since repositories, by definition have a unit of
>> work associated with them. For me, its the Repository that provides
>> the "coarse api" that Bryce was referring to. If you're clever, you
>> can store multiple data transfer object types in one repository's
>> Unit of Work, thereby doing commits atomically.
>>
>> Also, Zend_Form helps keep things thin. On my own projects, I've
>> managed to keep a small controller for complex forms by doing
>> validation in Zend_Form and flushing out the persistData() method
>> (which in turn fires against the Repositories in question). So with
>> the example you gave, I would've relegated that to a
>> Zend_Form-inherited object's persistData() method.
>>
>> This way, the repositories, as the project grows, can be refactored
>> into classes that live inside inside the domain, which can be tested
>> and that the controller doesn't need to deal with.
>>
>> my 2 cents,
>>
>> Jon Lebensold
>> http://jon.lebensold.ca
>>
>> On 28-Jul-08, at 11:58 AM, Bryce Lohr wrote:
>>
>>> 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
>>>
>>

August 1st is National Minority Organ Donor Awareness Day

没有评论: