While working with ASP.NET MVC, one of the mind shifts I made was to embrace the concept of the view or presentation model. Elegantly presented in ASP.NET MVC In Action, the idea is that you have your domain model as one set of classes and then another set of classes optimized for your user interface. Optimizing for user interface means understanding the limitations of the UI, in this case web pages and markup.
HTML is less friendly to debug and test, and the constructs within MVC markup are not as rich as within C#. So presentation models should be leaner, meaner, flattened out versions of your domain model. If your screen is not going to display it, it should not in your presentation model. If your screen is going to display it, it should be easy to get at. For example, if your Person domain object has a .Address.State property and you are displaying a mail order receipt for that user, you might have a MailOrderReceipt presentation model class with an AddressState string property.
The logical end state of embracing the concept of a presentation model is ending up with one model class per view or screen. At first blush this seems to fly in the face of good OO practices of object reuse and DRY. However, if you focus exclusively on these practices, you are ignoring the value of cohesion; meaning for a system to work well the parts should fit together. When views and models are tightly coupled then the views are simpler to write, debug and test.
There is one more pain though, you know have map from the domain to the presentation model. This code is easy to write, but also easy to mess up if you have to write a lot of it. The errors you might make here, such as forgetting to map a property should be quite obvious in testing, but an alternative is to use a library like AutoMapper to do the work for you.
