MVC from a CRC Perspective

The Model-View-Controller (MVC) pattern maps well to programming an HTTP client interface with persistent data stores as each external system interface requires a decent amount of protocol-specific adapter code which is well focused by the pattern.

While measuring the effectiveness the MVC pattern in focusing code according to component purpose, several anti-patterns have arisen, such as the following:

• Spaghetti View
• Fat Model
• Fat Controller

Instead of delving into the anti-patterns, we should understand first the intent of the pattern and what force(s) cause the pattern to break down, giving rise to the anti-patterns.

The MVC pattern from a Class Responsibility Collaborator (CRC) perspective follows, specifying for a network service, listing classes according to the trace of a client call path:

• Router
• List the business operations of the domain
• Route business operation requests to the appropriate Controller
• Translate InterProcessCommunication (IPC) protocol semantics, it HTTP, into functional programming semantics.
• Controller
• Receive Client business operation requests
• Validate parameters
• [optional, should be omitted due to optimization for a postcondition-guaranteed system] Validate system state wrt the requested operation
• Coordinate Model operations
• Respond to Client with Resource or Error
• Model
• Receive CRUD operation requests
• Translate DataStore protocol semantics into a common CRUD set of operations.
• Respond to Client with Resource or Error
• View
• Receive Model
• Translate Model into a format fit for consumption

With the MVC CRC listing in mind, developers relatively easily can create, read, update, and delete code in the appropriate class when programming a feature that exposes operations on a single resource.  This leads to quick "green field" development as well as small, incremental modifications such as exposing a display_name as a calculated field on a Person resource when the resource had only the constituent parts as fields.

From measures of deviance in primarily MVC-patterned applications, anti-patterns emerge typically as a result of development technical and feature increments that cause strain at points not addressed in the basic model of the pattern, such as:

• multiple underlying data stores become necessary to store a resource
• resource modifications become cohesive and through incorrect channels, ie models interact
• deviance from model operations being restricted to CRUD, but instead expanding to be the set of business operations

A large percentage of deviances from quality MVC-patterned code are the result of basic code handling mechanics which are necessarily made more difficult when employing MVC.  For instance, when altering the constraints on a resource, the change must be performed on the model as well as on the controller (and likely on a view or a few).  This opposition to the DRY principle is evident within the perceived need that Ruby on Rails and Django code generators fulfilled.  No pattern or practice is perfect; as such, it is incumbent on the programmer to know their pattern and perform the alteration with minimal negative impact on the code through the development channel (through QA and up through delivery to the consumers of the solution.)

Other antipatterns in MVC emerge as a result of strains that are outside of the scope of the MVC pattern itself, ie multiple underlying datastores.  A general solution that often proves successful is to employ the Façade pattern, creating a ResourceModel (no datastore) that translates one-to-many underlying models into a concise, coherent, and clear solution to an otherwise jumbled solution.  The Façade pattern also resolves the strain caused when attempting to resolve how a model can be restricted to support only CRUD operations.

If you would experience MVC antipatterns in the wild, please wrangle them.  If you would like to share your experience, please comment.