The Presentation Layer

Model-View-Controller Pattern

The structure of the presentation and domain layers instantiates the Model-View-Controller design pattern.

View Notification Problem

When data in the domain layer changes, how will views of this data in the presentation layer know to redraw themselves? Recall that there are no dependencies from the domain layer to the presentation layer. This is called the view notification problem. There are a variety of mechanisms for solving notification problems. The most famous one is the publisher-subscriber pattern.

Here is an example of how we might use this pattern in our video store:

Controllers

When the user clicks a button, selects a menu item, or enters text at a prompt, some type of command is created and sent to a controller.

The relationship between views and controllers can be many-to-one or one-to-one (or N-to-M):

If there is one centralized controller we call it a front controller or a command processor.

Alternatively, there can be one controller for each view (called a page controller) or one for each use case (called a use case controller).

Where does the intelligence reside?

1. Smart controller, dumb commands and views

In this case the controller knows how to update the model. Commands are merely strings or lists of tokens. Views only know how to draw.

2. Smart commands, dumb controller and views.

In this scenario a controller simply asks the command to execute itself.

3. A smart view knows how to display itself and how to update the model. The controller merely selects a view based on the command, then forwards the unexecuted command to the view.