CODEWITHSUNDEEP
c#asp.netasp.net-mvcasp.net-mvc-3
Jaggu
Jaggu

Reputation: 6428

What approach to choose for ViewModels?

I am using ViewModels with asp.net MVC3. One of the thing I am curious about is, suppose I have an entity named Customers and it has Add, Edit, Delete screens. Assume that they all have different properties requirements.

For eg. Add may have address field but the edit screen may not have edit screen, delete may only use customer name more than anything else.

My question is, how do you create ViewModels for this? Do you go with the approach of shared ViewModels between add, edit and delete i.e a single viewmodel class that handles all for you or do you prefer to create viewmodels classes / page?

Advantage with shared viewmodel is it reduces development time and we can reuse classes. But big problem with this is that if you are using tool like Automapper you may expected results for different screens.

Disadvantage with one viewmodel/page is that it increases development time. Which way should I go?

Upvotes: 2

Views: 293

Answers (3)

jgauffin
jgauffin

Reputation: 101194

All fields that exists in a model can be changed. It doesn't matter if they are hidden or not. All the user has to do is to inspect your pages and try to figure out what fields exist in the model.

Then he can add those fields (for instance with Chrome Dev Tools) to make changes to them.

The safest way to get rid of that problem is to just have models that only have the fields that are allowed to be changed.

That said, go ahead and use the same model if all fields in the model should be allowed to be changed by all users. (And simply do not show the fields that should not be modified)

Upvotes: 1

saintedlama
saintedlama

Reputation: 6898

My approach to view models is to use shared view models until the requirements (the data transported) to the view is different. That means I'm using a shared view model for example for CreateAddress and EditAddress in case all data transported to the view is the same. In case an additional field needs to be displayed in the view for example in the CreateAddress view I'm refactoring my view models and using different view models for CreateAddress and EditAddress.

For example for DeleteAddress I'd use a distinct view model from start because I know that the data displayed in the DeleteAddress view is almost never the same as in Create/EditAddress.

Another approach is to use dynamic view models, since view models should/must not implement business logic and act as DTOs between controller and view this approach has some benefits (No need to create logic free, throw away DTOs).

Upvotes: 1

Muhammad Adeel Zahid
Muhammad Adeel Zahid

Reputation: 17794

It depends upon situation. if you have similar requirements for different screens (validation, properties to render etc.) you can use the viewmodel across different views. If there is difference of one or two properties, i would still use the same viewmodel and where these properties are not needed i will put them in hidden inputs so they travel back with the form post not allowing unwanted results. Hidden fields, as all know, can be tweaked and its upon developer to decide if it is safe to use hidden fields. However, if i have different validation requirements for two screens then i definitely have to go with viewmodel/page approach. You can mix both approaches according to requirements as they say "there is no best way of doing things"

Upvotes: 1

Related Questions