MVC (Model-View-Controller) is an architectural design pattern that encourages improved application organization through a separation of concerns. It divides an interactive application into three components: Model / View and Controller. It enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) traditionally managing logic, user-input and coordinating both the models and views. The goal of MVC is to help structure the separate the concerns of an application into three parts:
- Model is responsible for managing the data of the application. It receives user input from the controller.
- View means the presentation of the model in a particular format.
- Controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.
The Purpose of MVC Framework
As mentioned above, MVC software framework helps us to separate the different aspects of the application (input logic, business logic, and GUI), while providing a loose coupling between these elements. Thus, the information (most reusable) logic belongs in the model, the GUI belongs in the view. Input logic belongs in the controller. 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. MVC Framework is a good idea for a number of reasons, including:
- Simultaneous development – Because MVC decouples the various components of an application, developers are able to work in parallel on different components without affecting or blocking one another.
- Reusability – The same (or similar) view for one application can be refactored for another application with different data because the view is simply handling how the data is being displayed to the user.
- improved scalability – if your application begins experiencing performance issues because database access is slow, you can upgrade the hardware running the database without other components being affected
- Low coupling — the very nature of the MVC framework is such that there is low coupling among models, views or controllers.
- better extendibility – as the components have a low dependency on each other, making changes to one (to fix bugs or change functionality) does not affect another
Develop Use Case Scenario Using MVC Sequence Diagrams
You can use stereotypes for the lifeline in the MVC sequence diagram to make visually clear what type of objects you are using in the MVC. An MVC Sequence diagram has interface objects, controller objects and entity objects:
- Entities are objects representing system data: Customer, Product, Transaction, Cart, etc.
- Boundaries are objects that interface with system actors: UserInterface, DataBaseGateway, ServerProxy, etc.
- Controls are objects that mediate between boundaries and entities. A controller object often correspond to use cases scenario and often represented by a sequence diagram.
And here is the simplistic and hypothetical sequence diagram for MVC. What you see in this diagram, a web-user initiated a query and an event is generated that is handled by the controller and gets information that is needed from the model, validates the information and passes back the result set to the view.
Example MVC Sequence Diagram
Suppose an application that let you search for persons. The UI must have a text field where the user can enter a search string and it might have a button to start the search. Finally it must have an area where the search results are displayed. In our case, it is implemented with a list component.
The “Search for Persons” use case Scenario is:
- The user enters a search string in the text field
- The user clicks the search button.
- The search result is displayed in the result list.
The sequence diagram above shows how the user’s button click moves through the application until the result gets finally displayed in the list component.