After having gone through
numerous of blogs and articles, I came to a conclusion that very few of the genuine
writers have explained the topic from the basic to full-fledged, while including a working application. My effort in this MVC articles series will be
to cover almost all the aspects of MVC starting from creating a simple app and
connecting with the database with various Microsoft providers. We’ll be
gradually moving forward part by part so we can understand and practically implement
- Part1: Introduction to MVC
architecture and Separation of Concerns.
- Part 2: Creating MVC
Application from scratch and connecting it with database using LINQ to SQL.
- Part 3: Connecting the MVC
Application with the help of EntityFramework DB-First approach.
- Part 4: Connecting the MVC
Application with the help of EntityFramework Code-First approach.
- Part 5: Implementing
Repository Pattern in MVC Application with EntityFramework.
- Part 6: Implementing a
generic Repository Pattern and Unit Of Work pattern in MVC Application with
All set? Let's start our
journey with Part1.
Part1: Introduction to MVC
architecture and Separation of Concerns
Topics to be Covered
- What does MVC mean.
- Understanding MVC
- Separation of Concerns
Model: The business entity on which the overall
application operates. Many applications use a persistent storage mechanism
(such as a database) to store data. MVC does not specifically mention the data
access layer because it is understood to be encapsulated by the Model.
View: The user interface that renders the model
into a form of interaction.
Controller: Handles a request from a view and updates
the model that results a change in Model’s state.
To implement MVC in .NET we
need mainly three classes (View, Controller and the Model).
The choice of MVC
comes when we go for a solution where the separation of concerns, ease of
maintainability and extensibility of an application matters a lot. As per the
architecture given below, we can see the request-response flow of a MVC
The architecture is self explanatory. The browser (as usual) sends a request to IIS, IIS searches for the route
defined in MVC application and passes the request to the controller as per route,
the controller communicates with the model and passes the populated model (entity)
to View (front end), Views are populated with model properties, and are rendered
on the browser, passing the response to browser through IIS via controllers
which invoked the particular View.
Separation of Concern
As per Wikipedia 'the process of
breaking a computer program into distinct features that overlap in
functionality as little as possible'. MVC design pattern aims to separate
content from presentation and data-processing from content. Theoretically sound,
but where do we see this in MVC? One place is reasonably clear - between the
data-processing (Model) and the rest of the application.
When we talk about Views and
Controllers, their ownership itself explains separation. The views are just the
presentation form of an application, it does not have to know specifically
about the requests coming from controller. The Model is independent of View and
Controllers, it only holds business entities that can be passed to any View by
the controller as required for exposing them to the end user. The controller is
independent of Views and Models, its sole purpose is to handle requests and
pass it on as per the routes defined and as per the need of rendering views. Thus
our business entities (model), business logic (controllers) and presentation
logic (views) lie in logical/physical layers independent of each other.
Now that we know why and where to
use MVC, in the next part of the series we’ll be creating an MVC application
from scratch, and exploring the practical implementation of MVC.