This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
How Do the Patterns Work?
A good way to understand how the different patterns work is to examine the process flow of a typical user request. We take the scenario just presented of a user pressing a button to show more details regarding a particular data row in a grid. The following sequence of actions would result.
- When the user presses the Show Details button, Windows generates a button push event.
- Depending on the pattern in use, one of the following would happen. In all patterns, the controller, presenter, or view model receives notification that the user requested an action, as follows:
- a. MVC: The controller receives the event and checks the view to see which data row is current.
- b. MVP: The view receives the event and in response generates a different event for the presenter to consume. This event has the current row information embedded in it and any other relevant information the presenter needs.
- c. MVVM: The advanced binding that is available with XAML-based applications means the button is bound to a button press command in the view model automatically. This same advanced binding enables us to bind a view model property to the data grid so the view model has a pointer to the currently active row.
- Using the information on the current row, the controller, presenter, or view model makes a request of the data model for additional data.
- The model (that is, the repository in the model) receives the request for data and issues a query to the database.
- The raw database data is returned to the model, which does any pre-processing necessary to change the raw data into an entity data class by copying values into the proper entity properties. If you use an Object Relational Mapping tool such as Entity Framework or NHibernate, the ORM does this step.
- The business entity is returned from the model back to the controller, presenter, or view model.
- The controller, presenter, or view model can execute any further processing required by the Show Details request. For example if your application displayed financial data, it might get an instance of a StockPriceService and request the current price for the stock the user is interested in, then update the entity class.
- To show the dialog with the detailed stock data, the controller, presenter, or view model creates another controller (or presenter or view model), which we call the DialogController, gives it the proper information to display and then calls a ShowDialog method on the DialogController.
- The DialogController creates the proper view, creates the bind data to appropriate text boxes on the view, and shows the view to the user.
This is one of the simplest of all processes. The controller, presenter, or view model can get much more complicated and perform as many duties as the user wishes. However, the basic division of labor should always be maintained.
- The view has only UI logic and no business rules or other logic.
- The model (the data model, not the view model) has only data access, entity class generation logic, and data validation.
- The controller, presenter, or view model has the logic necessary to perform the specific action the user requested.