Introduction to MVC Architecture and Separation of Concerns: Part 1

Introduction

After having gone through numerous blogs and articles, I decided that very few genuine writers have explained the topic from the basics to its details in a full-fledged manner with a working application.

My effort in this MVC article series is to cover nearly all the aspects of MVC beginning with the creation of a simple app and connecting with the database with various Microsoft providers. We'll be gradually moving forward part by part to understand and practically implement all the scenarios.

Road Map

All set, now we can start our journey with Part 1.

Part 1: Introduction to MVC architecture and Separation of Concerns

The topics to be covered are:

What does MVC mean
Understand MVC Architecture
Separation of Concerns

Players

The players are:

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 in a change of the Model's state.

To implement MVC in .NET we need mainly three classes (View, Controller and the Model).

MVC Architecture:

The choice of MVC s determined by a solution where the separation of concerns, ease of maintainability and extensibility of an application matters significantly. As per the architecture given below, we can see the request-response flow of a MVC application.

The architecture is self explanatory in itself. The browser, as usual, sends a request to IIS. IIS searches for the route defined in the MVC application and es the request to the Controller per the route. The Controller communicates with the Model and es the populated Model (entity) to the View (front end). Views are populated with Model properties, and are rendered on the browser, ing the response to the browser through IIS via Controllers that invoke the particular View.

Separation of Concerns

As per Wikipedia, "the process of breaking a computer program into distinct features that overlap in functionality as little as possible". The purpose of the MVC design pattern is to separate content from presentation and data-processing from content. Theoretically well, but where do we see this in MVC? One 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 need to know specifically about the requests coming from the Controller. The Model is independent of Views and Controllers, it only holds business entities that can be ed to any View by the Controller as per the needs for exposing them to the end user. The Controller is independent of Views and Models, its sole purpose is to handle requests and them on as per the routes defined and as per the needs of the rendering Views. Thus our business entities (Model), business logic (Controllers) and presentation logic (Views) lie in logical/physical layers independent of each other.

Conclusion

Now that we know why and where to use MVC, in another part of learning MVC we'll be creating a MVC application from scratch and exploring the practical implementation of MVC.

Read more:

Other Series

My other series of articles:

For more informative articles visit my Blog.