Business process and data with MVC

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.

Service MVC Class Diagram with 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.