Hi Matthew, Matthew Weier O'Phinney: >> I am still working on some kind of scaffold to give beginners a >> head start in ZF. During my ongoing quest for collecting ideas on >> best practices, I came across two nice articles from Leendert and >> Matthew about building robust PHP backends and the Domain Model >> approach. Incorporating those ideas, I drew a little sketch for >> myself in order to better get the idea of that "extended MVC" >> pattern. See: http://imagebin.org/57263 Did I sketch it correctly >> or did I miss something important?
> A few quick critiques: The more, the better ... > * What you term "Model" in this diagram is probably better termed an > "entity"; see Benjamin Eberlei's Zend_Entity proposal for some > background. I chose the term "Model" as most beginners are familiar with the MVC paradigm. Besides that - as long as Zend_Domain / Zend_Entity is not officially part of ZF - I thought that this might be more comprehensible if the audience read the quickstart manual or your presentation from the Dutch PHP Conference. But you're right: It's a little bit misleading. > * 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. > * A service object may interact with multiple entities This is a flaw in the diagram, true - I will adjust it. > * A service object also will typically manage things like ACLs, > validation, decorators (in the classic term, i.e., for decorating > behavior in the entities, data mappers, etc.), etc. I had something like that in mind, but as you know, most of the diagrams out there are completely overcrowded with tons of graphical representations of every single aspect, as people fear they could have forgotten something - or simply want to show that they want to describe the *whole* system. This diagram is intended as top level diagram (like UML packages) to help the "classical MVC-only developer" to understand the concept of domain driven design / data mapping and the use of a service layer. Later more detailed diagrams will probably show additionally involved classes / components too, in order to facilitate a better understanding. > * A given controller action may potentially interact with multiple > service objects, as well as individual entities themselves True ... those were omitted for the grace of simplicity here too ... but I see that for a professional this diagram seems to be rather confusing than enlightening ... :( > * 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 ... > Overall, though, yes, looks reasonable. Thanks - I am awaiting your input and will try to improve the diagram then. Once the diagram meets your expectations, I will return to the task to build some basic scaffold for a ZF application with Auth / ACL / Guestbook like a "pimped" quickstart. This will hopefully help some ZF beginners to understand the modularity of ZF and give them a head start for their own application. If the design is straightforward enough and state of the art, it could also be used as first attempt to facilitate the creation of self-contained modules. As soon as it is online, I will leave a link to the SVN on the mailing list. -- Cheers, \\|// Vince (o o) ----------------------------ooO-(_)-Ooo------------------------- ''' (o)_(o) [ ][0][ ] ô¿ô (=°o°=) World Domination by Copy and Paste [ ][ ][0] - (")_(") [0][0][0] () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Ooo. ---------------------------.ooO----( )------------------------- ( ) (_/ \_)
signature.asc
Description: OpenPGP digital signature
