Infosys | Microsoft

For the sake of people who are not really clear as to what Model-View-Controller (MVC) pattern is, it would be better that we start off by describing what MVC is. MVC is basically a UI design pattern. The main purpose of this design pattern is to isolate business logic from the user interface, in order to focus on better maintainability, testability, and a cleaner structure to the application. The MVC pattern consists of three key parts: the model, the controller, and the view. Let’s delve a bit into these key parts.

Model
The model consists of some encapsulated data along with its processing logic. The model object knows all of the data that needs to be displayed. It can also define some operations that manipulate this encapsulated data. It knows absolutely nothing about the graphical user interface—it has no clue about how to display data or respond to actions that occur in the GUI. Often, model objects retrieve and store model state in a database. For example, a Customer object might retrieve information from a database, operate on it, and then write updated information back to a Customers table in a SQL Server database. Simply put, the model contains the business logic.

View
Views are the components that display the application's user interface (UI). The view object refers to the model. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object. Simply put, the presentation logic is located in the view component.

Controller
Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. Actually, the controller object is the interaction glue of the model and the view. Hence the controller object has to interact both with the model and the view. Simply put, the controller contains the input logic.

If you have now understood what exactly do we mean by terms like Model, View and Controller, you would be able to appreciate the fact that the MVC pattern ensures that there is a clean separation of different aspects of an application (input logic, business logic, and UI logic), while providing a loose coupling between these elements. The pattern specifies where each kind of logic should be located in the application. The UI logic is in the view. Input logic is in the controller. Business logic is in the model. This separation helps you manage complexity when you build an application, because it enables you to focus on one aspect of the implementation at a time. For example, you can focus on the view without depending on the business logic.

What this also means is that we can now think about parallel development. For example, one developer can work on the view, a second developer can work on the controller logic, and a third developer can focus on the business logic in the model.

Now the question is - how would they test these components independent of each other? This brings us to another major advantage of adopting this pattern. The MVC pattern makes it easier to test applications. The MVC framework decouples the components and makes heavy use of interfaces, which makes it possible to test individual components in isolation from the rest of the framework.