MVC Architecture
Model
The Model is the name given to the permanent storage of
the data used in the overall design. It must allow access for the data to be
viewed, or collected and written to, and is the bridge between the View
component and the Controller component in the overall pattern.
One important aspect of the Model is that it’s
technically “blind” – by this I mean the model has no connection or knowledge
of what happens to the data when it is passed to the View or Controller
components. It neither calls nor seeks a response from the other parts; its
sole purpose is to process data into its permanent storage or seek and prepare
data to be passed along to the other parts.
The Model's job is to represent the problem domain,
maintain state, and provide methods for accessing and mutating the state of the
application. The Model layer is typically broken down into several different
layers:
- Service layer - this layer provides cohesive, high-level logic for related parts of an application. This layer is invoked directly by the Controller and View helpers.
- Data Access layer - (ex. Data Gateway, Data Access Object) this layer provides access to the persistence layer. This layer is only ever invoked by Service objects. Objects in the data access layer do not know about each other.
- Value Objects layer - this layer provides simple, data-oriented representations of "leaf" nodes in your model hierarchy.
View
The View is where data, requested from the Model, is
viewed and its final output is determined. Traditionally in web apps built
using MVC, the View is the part of the system where the HTML is generated and
displayed. The View also ignites reactions from the user, who then goes on to
interact with the Controller. The basic example of this is a button generated
by a View, which a user clicks and triggers an action in the Controller.
The View's job is to translate data into a visual
rendering for response to the Client (ie. web browser or other consumer). The
data will be supplied primarily by the Controller; however, the View may also
have a helper that can retrieve data that is associated with the rendering and
not necessarily with the current request
Controller
The final component of the triad is the Controller. Its
job is to handle data that the user inputs or submits, and update the Model
accordingly. The Controller’s life blood is the user; without user
interactions, the Controller has no purpose. It is the only part of the pattern
the user should be interacting with.
The Controller can be summed up simply as a collector of
information, which then passes it on to the Model to be organized for storage,
and does not contain any logic other than that needed to collect the input. The
Controller is also only connected to a single View and to a single Model,
making it a one way data flow system, with handshakes and signoffs at each
point of data exchange.
It’s important to remember the Controller is only
given tasks to perform when the user interacts with the View first, and that
each Controller function is a trigger, set off by the user’s interaction with
the View.
The Controller's job is to translate incoming requests
into outgoing responses. In order to do this, the controller must take request
data and pass it into the Service layer. The service layer then returns data
that the Controller injects into a View for rendering. This view might be HTML
for a standard web request; or, it might be something like JSON (JavaScript
Object Notation) for a RESTful API request.
