I have been thinking about the general issues with the MVC and the Vespa concept “Vespa: A better MVC”. The idea of splitting the Model component has really helped me a lot with a project that I am working on.
Let me emphasise that this doesn’t define how the model-view-controller (MVC) design pattern is supposed to be used. It merely suggests a slight alternative which allows the Model component to be split into business process and business data.
I decided to split Model into Service and Model (yes I stuck to the same name, but it has a lesser more specific goal). In my project a Service represents a business process whereas a Model only represents business data. I allow the Model to access data via an encapsulated PDO connection.
Plural Model classes are used to access singular Model representations. For example, a user ‘Bob’ can be retrieved via a service which will in turn utilise the UsersModel class.
The following diagram shows the classes and I have labelled the dependancy arrows to offer an idea of the process.
Here are some rules that I am considering for my project:
- Controller objects can load and utilise all Service and Model methods and fields.
- Controller objects cannot instantiate a Model independently. This is a business process and must thus be undertaken by a Service. A business process could potentially decide to use an alternative model under certain situations.
- Model and Service objects may interact with a data source.
- Model objects must conform to the interface dictated by the corresponding Service class(es).
- Model and Service objects can be overridden or adapted.
- Service objects can be accessed by any View, Controller, Service or Model.
The relationship between Model and Service is many-to-many. A service can utilise many data models, and a data model can be processed and interpreted by many services.
I hope that you have enjoyed this article. Please feel free to leave comments!