Is there a design pattern that describes the separation of a Form from a Model

Question

I am working on a web application implemented in C#, that follows MVC conventions.

This application contains a page that allows me to create or update a Wingding. The view passes a complete Wingding Model back to the controller for me to create or update.

The problem is that the page also has a checkbox that allows me to create identical Wingdings for all users. The current code adds a variable to the Winding Model to capture that data, so it can be passed back from the view.

It seems obvious to me that the page should have a Wingding Page Form object that is passed back from the view to the controller, instead of adding extra variables to the Model that won't get saved to the DB.

I know that this counts as separation of concerns, but is there a more specific design pattern that describes the separation of a From from a Model?

Answer 1

Sounds like you're looking for a View Model.

The View Model is an object that encapsulates only the data that is required for the View to display. Example:

public class UserInformationViewModel
{
    public string DisplayName { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string StateID { get; set; }
    public string Zip { get; set; }

    public SelectList States { get; set; }
}

In this example, States is a list of states or provinces, used to populate a drop down list. The data is sourced from multiple tables, but contained in a single object.

In smart client scenarios, the View Model can also contain view logic, such as validation and display modification based on user-selected data.

Answer 2

There're multiple solutions:

1.) IMHO the cleanest solution is to have that checkbox as a separate field and pass it to the controller, so it knows what to do.

2.) You can use a PresentationModel pattern to encapsulate everything the controller needs to know and pass that object.

Apart from that, I believe, the way that you are describing your use case, that you have a flaw in your model. If you create the same items for multiple users, then your discriminator is a reference to the user in your model, isn't it? So you need to pass the controller your blueprint of the winding and the list of users.