Suppose I'm creating a form in which you can edit a Person record. The Person record might look something like this:
public class Person
{
public string Id {get; set;}
public string Name {get; set;}
public string JobId {get; set;}
public string JobName {get; set;}
}
Let's say the JobName property is for display-only in the form. On the database, the job name is calculated via the JobId.
Load:
public Person GetPerson(string id)
When someone edits the form and saves it, ideally I would only need to send the first three properties to a Save function, to avoid any ambiguity about whether the JobName property needs to be supplied or not:
public class PersonToSave
{
public string Id {get; set;}
public string Name {get; set;}
public string JobId {get; set;}
}
Save:
public void SavePerson(PersonToSave person)
Is it a good idea to split out models like this such that you have a "Load" model and a "Save" model? Or is this overly complex?
My main concern with reusing the same model is that if another workflow needs to save a person model, they won't know which properties need to be filled out and which ones don't need to be filled out, especially if the class in question has many more properties, including some complex ones.
The pattern that you are mentioning has a name. It's called CQS (Command–query separation). It brings advantages and disadvantages. the most important advantage is the separation of concerns between writing and reading data. By separating these two, you can use different technologies (like ORMs) and class models (complex view objects for complex queries) for them.
If you go further you can apply CQRS (Command–query responsibility segregation) by introducing different data stores for reading and writing.