So I have an almost 1: 1 ratio of views for viewing models and things, it seems to be going well. If I understand their purpose correctly, it seems that view models should
- Break up Entity models so that only relevant properties are passed to the presentation layer.
- Add additional information needed for the presentation, such as a list of abbreviations or contact types when creating, say, an address.
Trying to maintain these principles, I kind of came across a wall with a report controller. Various reports created for a client require access to approximately 30 or so different properties. So my view model looks very similar to my Entity model.
Of course, the easiest solution is to simply pass the Entity model to the view so that I have access to all the properties, but I also need to be able to create reports for empty or "incomplete" clients. This causes issues to refer to exceptions when trying to access navigation properties in my Entity models.
That way, I can either use null checking for almost every field in the view, which doesn't seem too attractive ... OR I could implement a view model to avoid null reference exceptions. The problem is that I will have a view model that looks like this:
var customer = customersRepository.GetCustomer(id);
var viewModel = new CustomersViewModel()
{
FirstName = customer.FirstName,
LastName = customer.LastName,
Address = customer.MailingAddress.Address,
City = customer.MailingAddress.City,
// and on and on for about 30 different properties
};
return View(viewModel);
Putting all of these properties in is one of those things that just feel wrong. Is there a more elegant solution to this problem?