-- Vince42 <[email protected]> wrote (on Tuesday, 28 July 2009, 01:08 AM +0200): > Matthew Weier O'Phinney: > > * Service Layers are considered part of the "model". I'd group the > > services and entities together. > > After reading Leendert Brouwer's article > > http://www.angryobjects.com/2009/03/30/writing-robust-php-backends-with-zend-framework/ > > I must say: no. For me it seems pretty clear that domain entities > represent domain and business logic, while it would be asked to much of > them to implement the whole complexity of application logic too - at > least there are things put together, which rather should be seperated in > order to achieve a better readability and comprehension of the > application itself. > > His sketch of the Service Layer pattern is reasonable and I didn't find > any objections against it. But as I am not opinionated in any way, I am > open for new input on this.
He actually says specifically, "A service should model the core behaviour of your application." Note the word "model" in there. Martin Fowler discusses Service Layers within his "Patterns of Enterprise Application Architecture," and specifically groups them along with other patterns related to domain models. His discussion does talk about them being the application boundary -- but in terms of defining the specific functionality the application may invoke on the models. The service layer itself invokes business logic and controls the various transactions between different models and entities. The main purpose is to centralize common transactions that occur in the model layer, which is why I argue that the Service Layer is part of the model. <snip> > > * A view may request service objects and/or entities related to the > > display logic. So you need an arrow from View to Model (where Model > > here means the group of service and entity objects, as well as any > > assisting objects such as ACLs, validators, mappers, etc). > > Isn't the Controller supposed to feed the necessary entities to the > View? IMHO the view should not request anything, but will be fed with > all necessary data prior to rendering ... If you look at the classic MVC diagrams, they invariably show bi-directional communication between the View and the Model. The typical explanations indicate that the View may not mutate the Model, but may request information from the Model; conversely, in some systems, the Model may update the View (typically you'll see this in GUI development). One reason for this is because the View may have an idea of what needs to be displayed, while the Controller is simply shuttling input and output around. The Controller may have an idea of what the *primary* service being operated on may be, but have no clue that the View needs information from additional Models. For instance, a given "page" may need not just the article it was provided to render, but also a list of "recent articles" and "related products" with which to feed the sidebar. This is display logic -- and not something the Controller should be worried about -- let the View request these items. We actually encourage the View querying the Model with our View Helpers, and it was one big case for the various view enhancements made with 1.5. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/
