Looking for some opinions here. I'm working in an ASP.Net MVC2 application. We've built a collection of "domain objects", ie, the data that represents our "real world" problem we're going to solve, and it's also the representation of what will be serialized to the database. Each of these objects has been decorated with DataAnnotations Attributes to denote which properties are required. We plan on doing data validation before the object is persisted to the database.
The app itself is kind of like a "wizard"-- we're going to be configuring various parameters on one of the domain objects we're working with. But, each page of the wizard might be a subset of properties that the domain object might have. We're going to need to have validation on each of those pages, to make sure all required values are input.
Here's my question: If you were in this situation, what you use as your Model for each of these pages? Would you use the entire domain object, or would you build a view-specific model that is a subset of the domain object's properties, then validate that? I'm leaning towards the latter, because it seems cleaner. At some point, you'd take the 3-4 view-models and populate the domain object from those. Then, you'd validate the domain object, and persist that.
Am I off base here? MVC is kind of misleading of a term, in that the "Model" isn't actually what's getting persisted, it's just the data a specific view needs to get its job done.
As a followup, here's a link I found about doing partial validation on a single domain object:
So you can validate a subset of properties on one object, but it just seems really ugly... My argument AGAINST this approach is that reusing the same object in this case just seems lazy-- why not go on and create a view-model specific to your view, and work WITH the platform?