 |
| A typical collaboration of the MVC components |
So after some thought I thought I would annotate some of my current thoughts.
Microsoft tinkered with the pattern when they talked about MVVM and MVP but they are basicly just variants on MVC and not clearly adopted outside their software.
So the alternates with my favourite last:
Business Process and Data with MVC (Model-View-Controller)
In her blog Lea Hayes talks about using MVC but adopts the concept of splitting the model part into a business process and data [See blog].
This is a nice idea as it shows how to consider a controller that actually does a task instead of just going directly to a view.
Unfortunately this approach does not absolutly resolve all the issues as it relegates the controller to the role of "postman" or router. It also does not address what happens when the service has changed the data.
It also has no good monika to remember it by ... MS-VC ... nope!
Lea Hayes included a link on her blog to a second concept...
'VESPA': A better MVC
This post on a further varient from Bennett McElwee's blog to me offers more promise as sooner than redefining the paradigm as MVVM and MVP do, it adds definition to the elements of MVC. I agree largely with VESPA but I have only one refefinition (see later).
 |
| The Original VESPA pattern |
The reasoning is that as a designer you can communicate the MVC pattern to your developers but you may need to add some definition to how they start coding.
Essentially you break the M & C into four parts and effectively create a M=(SE) & C=(AP) which gives us SE-V-AP ... or rearranged as VESPA so you can communicate it.
But what are the parts:
The Model becomes "Store" and "Entity"
In MVC data is still stored and used on a view but there may not be a direct 1-1 mapping between stored data and the entities shown on the views. Which is where the MVVM comes in.
In VESPA your Store classes deal with persisting your data and contain any business logic on how to combine elements.
The Entity classes are those that are presented on the view but are not stored, they are however responsible for collating Store objects into a usable form.
An example of StoreB objects could be a set of JAXB objects talking to a web service, while the Entities are a set of POJOs that are used to place a degree of separation between the application and the data sources.
The controller becomes "Action" and "Presenter"
In MVC the controller is still in charge but there are two variants.
There is the Presenter which is the simple "mail-man" controller I spoke of earlier. It just finds the data entities and passes it to the view.
The other type is the Action, which is called "Actor" in the original VESPA but for me this conflicts with the Actor term from UML [See]. It is also similar to the "Service" Lea Hayes speaks about, but I think it is more of a controller concept.
My input to VESPA
 |
| My input to VESPA |
I agree with the original concept of VESPA 95% and I am adopting it into my projects.
My differences from the original are:
- Its Action not "Actor";
- The Action and Presenter only deal with the Entities.
Class packages and VESPA
Finally being a bit anal about package naming I would break down the classes into the following packages so you can find them.
Using a base package of mcnought.myproject you get:
- Actors are in mcnought.myproject.controller.actor;
- Presenters are in mcnought.myproject.controller.presenter;
- Stores are in mcnought.myproject.model.store;
- Entities are in mcnought.myproject.model.entities;
- View are in mcnought.myproject.view.
I hope this helps you.
No comments:
Post a Comment