Reputation: 9298
I'm using asp.net mvc 2 and I'm not sure howto structure the models and viewmodels. In the nerddinner there is only 1 of each.
Shall I have only 1 viewmodel of each entity (?) and then have 1 model for each form-modifing viewpage? So that viewmodel contains like all it ever would need, like: PagedFoo FooClass ..., FooClass, Foowithbunnies, FooClassStats... ?
/M
Upvotes: 0
Views: 150
Reputation: 5252
The way I view this is that (Domain) Model objects represent your business entities. Anything the business requirements dictate go there.
View Models are there to make the view as simple as it can be. So all the display logic, data massaging etc., goes there.
And yes, there will be times where one will seep into the other (Hey, you got your View Model/Peanut Butter in my Domain Model/Chocolate!), and it's OK.
But your goal should be to keep them as separate and clean as possible. This seems to lead to the most re-usable and easy to maintain code.
Upvotes: 1
Reputation: 7844
I inherited an app where one of the database tables has about 60 columns. This represents a persistent type that is constructed over the course of several pages within the app. To resolve this, I created about 8 different view models.
So... think of ViewModels in the same way as you would a SQL View table (if the metaphor helps). A ViewModel is a mechanism you use to help constrain the use of a Persistent Type to something that's useful for your view.
Also, I highly recommend using AutoMapper when working with transitions between ViewModels and Persistent Types, it makes dealing with ViewModels feel a lot more natural.
Upvotes: 0
Reputation: 4886
I generally have a ViewModel which will represent a View. This is to keep the view as dumb as possible. So, for now, it's a 1 to 1 relationship. View -> ViewModel, but my ViewModel has a one to many relationship with my Model
extract View |----| ViewModel ViewModel |----|< Model
Upvotes: 0