Model-View-Controller – is Now a design pattern for the architecture of all software applications. It is a widely adopted pattern, across many languages and implementation frameworks, whose purpose is to achieve a clean separation between three components of most any application. Its changing day by day, so need to be updated
An application have three main layers
- presentation (UI)
- Application logic
- Resource management
MVC is a framework methodology that divides an application’s implementation into three component roles: models, views, and controllers.
- “Models” in a MVC based application are the components of the application that are responsible for maintaining state. Often this state is persisted inside a database (for example: we might have a Product class that is used to represent order data from the Products table inside SQL).
- “Views” in a MVC based application are the components responsible for displaying the application’s user interface. Typically this UI is created off of the model data (for example: we might create an Product “Edit” view that surfaces textboxes, dropdowns and checkboxes based on the current state of a Product object).
- “Controllers” in a MVC based application are the components responsible for handling end user interaction, manipulating the model, and ultimately choosing a view to render to display UI. In a MVC application the view is only about displaying information – it is the controller that handles and responds to user input and interaction.
The confusion on model idea
Model is a set of classed which model and support the underlying problem. But a confusion arise how much power a model deserved. Because model don’t know view exists. To solve that, here proposed a new architecture name MdMaVC
Md or domain model represents core work of application with out knowing a view exists. Where Ma or Application model knows may be a view exists and that need some way to bind it. So the problem of communication between Model and view is solved.
So the control flow generally works as follows:
- 1. The user interacts with the user interface in some way (e.g., user presses a button)
- 2. A controller handles the input event from the user interface, often via a registered handler or callback.
- 3. The controller accesses the model, possibly updating it in a way appropriate to the user’s action (e.g., controller updates user’s shopping cart). Complex controllers are often structured using the command pattern to encapsulate actions and simplify extension.
- 4. A view uses the model to generate an appropriate user interface (e.g., view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view. (However, the application model can be used to allow the model to indirectly notify interested parties, potentially including views, of a change.)
- 5. The user interface waits for further user interactions, which begins the cycle a new.
One of the benefits of using a MVC methodology is that it helps enforce a clean separation of concerns between the models, views and controllers within an application. Maintaining a clean separation of concerns makes the testing of applications much easier, since the contract between different application components are more clearly defined and articulated.
The MVC pattern can also help enable red/green test driven development (TDD) – where you implement automated unit tests, which define and verify the requirements of new code, first before you actually write the code itself.