MVC Extended

[Vince42]

Hi,

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?

Don't worry too much about the wording - it's meant to be as simple as
possible ... :)

--
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----(  )-------------------------
                           (  )    (_/
                            \_)

[weierophinney]

-- Vince42 <[hidden email]> wrote
(on Monday, 27 July 2009, 12:53 AM +0200):

> 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:

 * What you term "Model" in this diagram is probably better termed an
   "entity"; see Benjamin Eberlei's Zend_Entity proposal for some
   background.
 * Service Layers are considered part of the "model". I'd group the
   services and entities together.
 * A service object may interact with multiple entities
 * 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.
 * A given controller action may potentially interact with multiple
   service objects, as well as individual entities themselves
 * 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).

Overall, though, yes, looks reasonable.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/

[Vince42]

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----(  )-------------------------
                           (  )    (_/
                            \_)

[weierophinney]

-- Vince42 <[hidden email]> 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            | [hidden email]
Zend Framework          | http://framework.zend.com/