0

I'm looking at creating my first ASP.NET MVC application using MVC3.

The project template I used included some models for registering users, logging in and updating a forgotten password.

I want users to be authenticated against my own data store (probably using Entity Framework) and using google OAuth.

I assumed that I'd want a User model class that contained a few standard properties and some business logic which handled the "local" authentication and the OAuth call but the project template has confused me.

Should I be creating multiple view-models for different actions like Login, Register, etc and then using the controller to instantiate and invoke my model to perform the business logic or should I use my User model for all the different actions?

Thanks Ben

Animesh
  • 4,926
  • 14
  • 68
  • 110
BenCr
  • 5,991
  • 5
  • 44
  • 68

1 Answers1

4

Should I be creating multiple view-models for different actions like Login, Register, etc and then using the controller to instantiate and invoke my model to perform the business logic or should I use my User model for all the different actions?

View model per view. That's the rule. There might even be 2 view models per view (one for rendering data in the GET and one for receiving data from the view in the POST action). Don't be shy in creating view models. You definitely shouldn't be using a User model for all different actions, that would be catastrophic. The model should be used by your service layer. A User model will be manipulated by this layer, and never passed to a view.

You may also checkout AutoMapper for mapping between your model classes and view models. It's a great tool and comes in handy especially when the number of view models start to increase.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 1
    @BenCr, because each view has different requirements in terms of formatting and validation. An Insert view is not the same as Update view which is not the same as List view. If you use the same model in all those views your next question on StackOverflow will be *How do I write conditional data annotations validation attributes based on the controller action* once you find yourself confronted in a situation where for example some property is required in the Update view (like the Id for example) and not required/not existing in the Insert view. So always create and use specific view models. – Darin Dimitrov Apr 20 '11 at 21:41
  • So should the view-model be aware of some other "BE" type layer that it uses to perform the actual application logic? It seems like MVC is actually more like MVVMC – BenCr Apr 20 '11 at 21:46
  • @BenCr, a controller action queries the service layer and fetches a model. Then it uses a mapping layer to convert this model to a view model. Finally it passes the view model to the view. This works also the other way round: a controller action receives a view model from a view (in a POST action for example). It maps this view model back to a model and passes the model to the service layer for processing. All formatting and surface validation should be done in the view model. – Darin Dimitrov Apr 20 '11 at 21:48
  • So the controller basically marshals the VM into a M and back. Okay. By "mapping layer" do you mean something like [AutoMap](http://lostechies.com/jimmybogard/2009/01/23/automapper-the-object-object-mapper/)? – BenCr Apr 20 '11 at 21:51
  • @BenCr, exactly. And, yes by mapping layer I absolutely mean AutoMapper. Perfect example as Jimmy Bogard is actually the creator of this framework. – Darin Dimitrov Apr 20 '11 at 21:52
  • Okay, thanks Darin for your prompt answer and further comments. – BenCr Apr 20 '11 at 21:56
  • @Darin - What bugs me about this is the amount of data duplication. It's very un-DRY, and requires that changes be made in numerous places when you change something. I understand that this is how MVC has shaken out as a best practice, but it seems short sighted in the long run. – Erik Funkenbusch Apr 20 '11 at 22:50