An application model is the non-UI part of an application that manages its state and carries out business logic. In a Razor Pages application, it is not necessarily one class: it can encompass a domain model, services, and database interactions. Keeping that work separate from HTML generation makes each part easier to change and test. section 13.4.2 section 13.4.4
In a typical Razor Pages request, the responsibilities are divided:
- A binding model holds information supplied with the request, such as values from the URL. section 16.1
- The page handler validates the request, calls the application model through services, and chooses a response based on the result. section 13.4.2
- The PageModel exposes data to the Razor view, which generates the HTML response. The PageModel is not the application model. section 16.5 section 13.4.4
Viewing a to-do category
Suppose a user requests the to-do items for a category and username. The page handler can call into the application model to obtain the relevant items. That work might involve checking which items the user may view, searching the category, and loading details from a database. Once the details come back, the handler chooses the response; the application model does not create the view. section 13.4.2 section 13.4.4 section 16.1
Figure 16.2 The MVC pattern in ASP.NET Core handling a request to view a subset of items in a to-do list Razor Pages application
Follow the request through the distinct models to see where binding, application logic, and response generation fit. section 16.1
The domain model is one part of this larger concept: it holds complex business logic in classes that do not depend on infrastructure. An application model can also include services and data access. This boundary helps prevent a change to UI code from unexpectedly changing business logic, or vice versa. section 13.4.2 section 13.4.4
