To Model Or ViewModel, That Is the Question
Okay, so here is the question. Let's say you are writing an application for managing your hardware inventory. You need to create a view for editing a piece of inventory. You also have an object in the class library that you have associated with the site called "HardwareItem" that is your "BL" representation of an individual piece of hardware. Do you a) pass that model to the view as the model for the view or b) do you create a separate object to be consumed by the view (that you might call a "view model") and map the model to it before passing it to the view?
The authors of ASP.NET MVC In Action (a great book, link in sidebar) termed this distinction between a "BL" model and view model the domain model versus the presentation model. That's a good way to think about it.
This question will probably be asked for a long time though I am hoping a consensus will develop (though most that I follow tend to as a rule create view model classes even when a model might work. The argument for not always doing this primarily comes simply from a desire to write/maintain less code. It is obvious why creating new view models all of the time will lead to more code. But, in pretty much any app, there will be a need to do it sometimes. Here is why:
Reasons to Use a View Model
- If you need to pass more than one thing to a strongly-typed view (which is very common), you will generally want to create a separate class to do so. Otherwise you would end up poluting your model objects with extraneous properties just to get data to the view.
- When it makes sense (and this has happened to me), this allows you to validate your view model differently than your model for attribute-based validation scenarios (more on that later).
- View model objects can be used to help shape and format data. Need a date or money value formatted a particular way? You can do that in the view, in the controller, or in the view model. If all you are doing is formatting and such, you can make a case that the view model is the best place to do it.
- The use of a view model can make the interaction between model and view more simple. A model can sometimes be rather complicated having other model objects as members, which could have model objects as member, and so on. By using a view model you have a good mechanism to flatten out and simplify what the view deals with. This will also filter down what can be seen in intellisense, so if you have different people developing the models than those working on the views, creating a simple view model can make it much easier for those just dealing with the UI.
Why I Always Use a View Models Even When I Don't Need To
For some people, having only a partial separation between model and view model is not enough. They want to have separate view models all of the time. When I first started with ASP.NET MVC I followed the mixed approach. Over time I have moved to always creating a separate view model for the following reasons:
- It helps you avoid putting code where it does not belong. If you have to have a bit of data in a particular way for a view, you might be tempted to add that logic to your model, even if it's only a presentation concern and is not directly related to the concerns of the domain. By having the model/view model split explicit, it helps to keep the code where it belongs.
- I like consistency in my coding practices. Mixing model and view model got annoying after a while.
Regardless of the choice, the discussion for the rest of this section would be relevant for either approach. Soon we will get into fun subjects like validation, but first we should say a bit about the model binder.
Speak Your Mind!
Have something to say? Find a grammatical mistake? Think I said something incorrect? Don't like my perspective? Hate my color scheme? Whatever it is, you can let me know. I would appreciate it if you did.
