The Model-View-Controller pattern is an architectural pattern that encourages strict
isolation between the individual parts of an application. This isolation is also better known
as separation of concerns, or, in more general terms, “loose coupling.”
Architecting applications in a loosely coupled manner brings a number of both shortand
Individual components do not directly depend on other components, which means
that they can be more easily developed in isolation. Components can also be readily
replaced or substituted, preventing complications in one component from affecting
the development of other components with which it may interact.
Loose coupling of components allows test implementations to stand in for “production”
components. This makes it easier to, say, avoid making calls to a database,
by replacing the component that makes database calls with one that simply returns
static data. The ability for components to be easily swapped with mock representations
greatly facilitates the testing process, which can drastically increase the
reliability of the system over time.
Isolated component logic means that changes are typically isolated to a small number
of components—often just one. Since the risk of change generally correlates to
the scope of the change, modifying fewer components is a good thing!
So now that we know Model-View-Controller pattern, let us try to define the Model, View and Controller formally:-
Model: The model represents core business logic and data. Models encapsulate the properties
and behavior of a domain entity and expose properties that describe the entity.
Technically,These are the classes that contain data. They can practically be any class that can be
instantiated and can provide some data.
Controllers: The controller, as the name implies, controls the application logic and acts as the coordinator between the view and the model. Controllers receive input from users via the view, then work with the model to perform specific actions, passing the results back to the view.
Technically,These are the classes that will be invoked on user requests. The main tasks of these
are to generate the model class object, pass them to some view and tell the view to generate
markup and render it on user browser.
Views : The view is responsible for transforming a model or models into a visual representation.
In web applications, this most often means generating HTML to be rendered in the user’s browser, although views can be render in many forms. For instance, the same model might be visualized in HTML, PDF, XML, or perhaps even in a spreadsheet. Views should concentrate only on displaying data and should not contain any business logic themselves—the business logic stays in the model, which should provide the view with everything it needs.
Technically,These are simple pages containing HTML and C# code that will use the server side object i.e.
the model to extract the data, tailor the HTML markup and then render it to the client browser.