Models
Models represent data.
They contain all related logic with the exception of view and controller logic; and manage business, data access, and validation logic. There are three types of models: the domain model, the view model, and the input model.
- Domain Model – This model describes data manipulation at the level of the application's middle tier. The domain model, also referred to as the entity model or data model, provides an accurate picture of the entities populating the business domain. The data-access layer usually supports these entities. The services responsible for implementing business processes consume the entities. The domain model presents a view of data dramatically different from the presentation layer given the obvious differences of each perspective.
- View Model – This model describes data manipulation at the presentation layer. The properties of the view model classes hold the data (e.g., values, strings, or bulk data) presented at this layer. Controllers send data after managing related operations for response delivery to the user, and view model classes represent the data transmitted after processing. These classes form the view model, and one view model exists for each view (or page).
- Input Model – This model describes the flow of input data traveling from the page to the controllers and backend. The input model, a collection of classes, represents the uploaded data and associated HTTP requests. Management of this data typically consists of string manipulation and analyzing values. ASP.NET forms require conversion of strings into strong types. Model binding in ASP.NET MVC performs this task for the user; furthermore, it attempts to map incoming strings to matching properties of input models.
THE INPUT MODEL
Imagine the input model as a collection of classes modeling any data received through HTTP requests. Basic data transfer objects serve as the building blocks of the input model. The objects consist of only properties, no methods. Controller methods use input model classes to receive data passed on HTTP headers, or passed through other means.
In ASP.NET, the developer must determine the names and structure of input model classes, whether original or a popular pattern, which supports characteristics and events like common data throughout the application. Mapping that occurs to properties throughout is achieved through model binding.
MODEL BINDING
Action invoker components control the execution of controller methods. Developers determine the signature of the controller method. The invoker gets a model binder object for each parameter. The binder exists for the sole purpose of finding a value for the parameter from the HTTP request. Though each parameter can be tied to a model binder class, most applications employ a default model binder class (DefaultModelBinder class).
The model binders employ unique algorithms to find values for parameters with some matching names (e.g., matching a parameter named “Text” to requests related to text) and making conversions based on the matches found (e.g., converting the upload value to the parameter's declared type). The conversion, if successful, results in the value being used to call the controller method. If the conversion fails, an exception is thrown. The controller method call only performs successfully if the binder can resolve all parameters; and controller method code cannot be used to manage exceptions. Also, exceptions only result if the method parameter cannot be null.
Default binders search assorted collections associated with HTTP requests, with the Form collection being its first resource. These searches are case-insensitive. If no matches are found in Form collection, it proceeds to the QueryString collection after reviewing the route parameters. The length of the method's signature may become problematic with the use of primitive types and individual parameters when uploading and mapping multiple variables. Default binders help by finding a match between a value and a property on a target of an identical name. In the absence of a match, the target's property retains the default value.
CUSTOM DEFAULT BINDERS
The default binder works in most cases, however, some situations demand a custom binder. When aggregating values (uploaded individually) into a single object, custom binders prove critical. An example of this is a form with three fields for region, office, and department; which become a single object. These values can be bound to certain parameters, and then converted manually in a controller method.