During a trawl of posts on a software development postings on LinkedIn (or some where) I stumbled across a
blog post that set me thinking.
We have all be come very familiar with the concept of
Model-View-Controller (MVC), that I think as developers we don't give it any more thought and when it doesn't really fit what we are doing we blithely continue.
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).
What VESPA does is to refactor sooner than to redefine the MVC 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.
- 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.
