- Working with Architectural Patterns
- An Overview of Architectural Patterns
- Differences Among MVP, MVC, and MVVM
- Handling UI Events
- How Do the Patterns Work?
- Which Pattern Should You Choose?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
An Overview of Architectural Patterns
These architectural patterns have the same goal to help keep the application structured in such a way that it is easy to maintain and has low coupling. They separate our application into three major sections.
Model: This is the data model and is typically represented by the database and any direct interaction with the database. This includes the queries used to extract the data from the database, classes that represent a row in each table (entity classes), and entity class validation logic to ensure that the data in the database is consistent with the business rules. The validation logic ensures that the data is consistent with business rules before it is stored in the database.
There is typically only one data model in any given application, though in rare cases, there can be more. For example, it might be necessary to have two data models if you want to access data from a different application and that model must change independently. It might also be convenient to have two models if the application requires data from both MS SQL Server and Oracle.
- View: This is the code that displays the data on the screen for use by the user. It includes the code to create the window and add the controls necessary to display data. A significant piece that is not in the view is data manipulation and business logic. Changing data is the responsibility of the third piece, the controller, presenter, or view model.
- Controller / presenter / view model: The place where the three patterns differ is in this third piece. Depending on which pattern you choose, you have only a controller, only a presenter, or only a view model. The general goal of these pieces is the same in all three patterns, but the specifics and implementation details differ.
In general, each view has either a controller, presenter, or view model associated with it. This is the section that glues the model and view together and orchestrates the interaction between the two. This is where we put the business logic necessary to decide which rows in the database need to be retrieved and the code to query those rows (using the model) and deliver that data to the view to display to the user. This piece uses the services we described earlier to implement some of the generic business logic, and the logic specific to the requested operation is included here.