4

I am building a web application with ASP.NET MVC and am still a beginner with this technology.

I have learned that it is best practice to have a ViewModel for each View. I can understand why this is a good idea. However, in my situation it seems to create a lot of extra work.

I have a model called Rule. It contains an Id, Title, Description, LastModifiedDate, CreatedDate, among other fields.

I have an Edit, Create and Details view for the Rule model.

According to the best practice, I have to make a ViewModel for each of the above Views. But the ViewModels for above Views are nearly identical. One of the only differences is that the Create-ViewModel has no Id, but the Details and Edit ViewModels do. Other than that, the ViewModels are nearly identical. That is, they contain the same attributes and same DataAnnotation validation fields.

Why do I think this is troublesome? Suppose I want to change some of the Data Annotations. E.g. chaneg a Maximum Length of a string attribute. If I wish to do so, I have to do so in both the Rule model, the Create ViewModel and Edit ViewModel. And likewise if I wish to add new attributes, I must do so in all the models.

Am I doing this right, or can it be simplified?

bjoeg
  • 53
  • 4
  • you can use same view model for create, view and edit. – anand Jun 01 '17 at 09:50
  • 1
    *best practice to have a ViewModel for each View* no it's not. It's helpful but you don't **have** to do this. If it warrants a view model, make one, it doesn't that's also fine – Liam Jun 01 '17 at 09:53
  • You can use class inheritance to reduce code duplication. If you use the same model for all view, watch out for over-posting. – Teodor Kurtev Jun 01 '17 at 09:54
  • Also read [What is ViewModel in MVC?](https://stackoverflow.com/questions/11064316/what-is-viewmodel-in-mvc) – Liam Jun 01 '17 at 09:55
  • 1
    As others have said, you don't _have_ to. Keep it [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) – rickvdbosch Jun 01 '17 at 09:55

4 Answers4

3

Well this is more an implementation decision rather than a best practice rule. You have to take in consideration some of the pros and cons:

Different ViewModel for each view

  • Modify only the ViewModel associated with the view
  • Flexibility
  • Hard to maintain with very large applications

Reuse ViewModels for different views

  • Modify all the ViewModels at once
  • Much easier to maintain
  • Limited flexibility

My advice would be to create the base RuleViewModel without the ID property and for the edit and details actions inherit the model and add the additional column.

Cristian Szpisjak
  • 2,429
  • 2
  • 19
  • 32
2

It is/was never a rule to make ViewModel per View. It is all about how your architecture is. As per your requirement if you feel both the views are exact same then use same ViewModel.

IMO do not use data annotation, if possible go for Fluent Api.

FosterZ
  • 3,863
  • 6
  • 38
  • 62
0

For all operations: add, update, remove - you can use one view model - Rule. It is completely fine as you want to manipulate with this single object, right?

The only difference would be the displaying of multiple Rule objects - list view page, here you might want to create an extra viewmodel like RuleListViewModel which will contain a collection (IEnumerable<Rule>) of objects and maybe some more properties for filtering and so on.

pitersmx
  • 935
  • 8
  • 27
0

It sounds like you are mixing your view models and business objects. I usually try to keep these separate as they serve different purposes.

Your business object can have CRUD methods. Your view model can have a property that exposes your object, and can in fact expose other objects if required.

Doing it this way preserves the single use rule and makes it very maintainable.

But, this really is a design choice rather than "best practice" which (let's be honest) changes with the wind.

CompanyDroneFromSector7G
  • 4,291
  • 13
  • 54
  • 97