Model-View-Controller
Architectures
Model-View-Controller (MVC) architectures dominate desktop and web-based applications. Operating under the principle of avoiding mixed domain coupling, specifically, the principle:
Application logic should be independent of presentation logic.
The MVC architecture does this by enforcing a strict one-way dependency between less-reusable presentation logic and more-reusable application logic:
The MVC architecture is a refinement of the Entity-Controller-Boundary Pattern used in analysis models.
Strictly speaking, model, view, and controller are roles played by multiple classes, not single classes. That said, here is how these roles might be connected in a class diagram:
Notice the one-way associations connecting views and controllers to the model. This is the crucial feature of the MVC architecture.
The model belongs to the application package. It encapsulates business logic, rules, entities, processes, etc.
More often, the model is a collection of related entity classes.
Policy, Claim, PolicyHolder ...
Treatment, Patient, Test ...
Auction, Bidder, Bid, Item ...
Dungeon, Weapon, Character ...
etc.
In our simplified class diagram the state of the model describes the temperature, fuel-level, claim status, test results, etc. The model provides methods for updating and querying this data.
Views and controllers (there may be many) belong to the presentation package.
A view might be a web page or a desktop window. Instantiating the Composite Design Pattern, a desktop window often contains child-windows and controls.
A controller listens for user input coming through the view's controls (buttons, sliders, menu items. etc.). When input arrives, the controller updates the model. This may involve calling many model methods in a carefully prescribed order. For example, executing the command:
transfer $100 from savings to checking
involves the following micro operations in the model:
locate the accounts
checking for permission
check for sufficient
withdraw $100 from savings
deposit $100 to checking
confirm transaction
Often controllers correspond to use cases from the analysis model.
The following sequence diagram captures a typical MVC interaction:
Note that after the controller asks the model to update its state, the view queries the model for its new state, then updates itself. For example, the view might have several child-windows that display aspects of the model's state in different ways: pie charts, bar graphs, text, etc. These need to be updates when the state changes.
Problem: How do
views know when to query the model?
Answer: Publisher-Subscriber Pattern
Problem: How can
commands be decoupled from the controller?
Answer: Command Processor Pattern
Problem: How can
undo/redo be implemented without violating encapsulation?
Answer: The Memento Pattern
Problem: How can
features be added to view without modifying the view?
Answer: The Decorator Pattern