Monday, 15 December 2014

Introduction to MVC architecture and Separation of Concerns.


Topics to be covered:
  • 1.     What does MVC mean.
  • 2.     Understand MVC Architecture.
  • 3.     Separation of Concerns


Players:

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).

MVC Architecture:

           The choice of MVC comes when we go for a solution where 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 application.

The architecture is self explanatory in itself. Browser as usual sends a request to IIS,IIS searches for the route defined in MVC application and passes request to the controller as per route, the controller communicates with 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 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 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 controller as per need of exposing them to end user.The controller in independent of Views and Models, its sole purpose is to handle requests and pass it on as per the routes defined and as per 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.

Conclusion:

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

No comments:

Post a Comment