CODEWITHSUNDEEP
c#asp.net-mvcdesign-patternsasp.net-mvc-5asp.net-mvc-viewmodel
ca9163d9
ca9163d9

Reputation: 29159

ViewModel for a model with a lot of properties?

I plan to create a Asp.Net MVC app which contains edit/create pages for a large model with many-to-many relationship with other models. I found the Saving Many to Many relationship data on MVC Create view and plan to use it.

In the example, the create page uses the following ViewModel.

public class UserProfileViewModel
{
    public int UserProfileID { get; set; }
    public string Name { get; set; }
    public virtual ICollection<AssignedCourseData> Courses { get; set; }
}

And the UserProfile model has only two properties so the ViewModel just duplicates all the properties.

public class UserProfile
{
    public UserProfile()
    {
        Courses = new List<Course>();
    }
    public int UserProfileID { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Course> Courses { get; set; }
}

However, in my case, there will be a lot of properties (with data annotations), say 50 properties. Should the ViewModel duplicate all these properties (with data annotations too)? (looks ugly?) Or is there a better way?

Update Is it a good practice to define ViewModel as

public class UserProfileViewModel
{
    public UserProfile UserProfile { get; set; } 
    .... // Other properties needed by the view.
}

One shortcoming of this way is it expose all the properties in the Model even it's not needed in the view.

Upvotes: 0

Views: 2085

Answers (2)

MikeSW
MikeSW

Reputation: 16348

The thing with View Models is very simple: the View Model should consist only from data needed by the View. That is, the view model design is driven by the (static) view. Static because you can updates parts of the view via ajax in the browser so it makes no sense for your model to contain that info (except if it's required as init values for the JavaScript).

How the data is stored or how it's used by the business layer (if any) is not the view model concern.

Updated

The cleanest and safest way is to define the view models with the properties you need (you can copy paste them from the other model it's ok in this scenario) then use AutoMapper to map the business object to the view model. This way you can evolve both models differently. Personally, very rarely my view model is identical to a business model, they resembles a lot but there those tiny differences that complicate the things.

From a Separation of Concerns point of view, the busines model is for business usages, persistence model is for persistence usage while view model is for the view usage. Don't mix them or you'll have one model serving too many masters, which leads to complications down the road.

Upvotes: 2

BLoB
BLoB

Reputation: 9725

Taken from: This excellent explanation of ViewBag, ViewData and TempData

The type of data that suits ViewModels well is as follows:

  • Master-detail data
  • Larger sets of data
  • Complex relational data
  • Reporting and aggregate data
  • Dashboards
  • Data from disparate sources

So in summary, yes the ViewModel is what to use when the view requires a lot of complexity, it suits your needs. As for using and populating every property that should be determined by what the particular view requires. ViewModels are not necessarily one to one representations of a model / entity. That should be dictated by your view requirements, e.g. UserCourseViewModel could aggregate the UserProfile and Course entities, but not necessarily all of both of their properties, unless of course all properties are required by the view.

Rachels summary:

The ViewData and ViewBag objects give you ways to access those extra pieces of data that go alongside your model, however for more complex data, you can move up to the ViewModel. TempData, on the other hand, is geared specifically for working with data on HTTP redirects, so remember to be cautious when using TempData.

Upvotes: 1

Related Questions