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 emphasize 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 utilize the UsersModel class.
The following diagram shows the classes and I have labeled the dependency arrows to offer an idea of the process.
Here are some rules that I am considering for my project:
Controller objects can load and utilize 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 utilize many data models, and a data model can be processed and interpreted by many services.