CODEWITHSUNDEEP
asp.net-mvc-3asp.net-membershipregistration
Alnedru
Alnedru

Reputation: 2655

MVC3 Registration form and model

I have a question regarding the MVC 3 and more exaclty about the views and models. I want to mention that I'm new to MVC so I'm oly learning it.

Basically for example lets take te registration form:

I have a controller, view and model, to register a new user.

Now, in registration model i have all the datamembers with data annotations, for example:

    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

This are then rendered in view.

What bothers me, or I don't really understand how to do it properly:

Ok I have RegistrationModel ... but later on, for example if i want to render the profile of the user, should i call registrationmodel again or then it will be profilemodel? So basically I will have a lot of the same models just to render the same thing ... no?

Can't I have then one general Model, something like user, and then User i can pass with RegistrationModel/ProfileModel to view.

Maybe it is a bit difficult to understand what I mean exactly, but how I imagine it: for example a user submits a form, everything is parsed and a User object is created with all the data members, then this User object is pased to DAL, where it is submitted to DB. Later on someone visits the profile of this user and the DAL, will return User object back which is then displyed.

Upvotes: 0

Views: 764

Answers (1)

Marko
Marko

Reputation: 13263

The answer to your question is no you should generally separate your domain models from your view models. Consider a following scenario. Let's say you have a User model and your business logic allows you to both add a new user and edit an existing user. Let's say your user model looks like this:

public class User
{
    [Required]
    public int? UserId {get; set;}
    [Required]
    public string LastName {get; set;}
    [Required]
    public string FirstName {get; set;}
    [Required]
    public string Password {get; set;}
    public bool IsAdmin {get; set;}
}

Now in order for your user model to be valid you have to have User ID to make the user identifiable. When you're inserting a new user you don't need the ID because that is something database will automatically take care of on insertion. However when you're doing an update of the user then you need the user ID to be populated. So now you have a model that in one case requires a field (UserId) but in another it doesn't. How are you going to handle that?

The answer is view models and this is the reason why they exist and why it's advised to create one for each entry form you have in your project. In this case you would end up with a different insert and update user view models. I know it's tedious to convert these view models into the underlying domain models but there are libraries to help you do that automatically like AutoMapper (https://github.com/AutoMapper/AutoMapper/wiki/Getting-started).

2nd and probably more serious problem is over posting. Suppose you are using the above User model to edit the user in your database. Now the model has an IsAdmin field which specifies whether user is an admin or not. Now your edit user view will omit this field since you don't want the general user to be able to make themselves an admin. But let's say you're dealing with a really smart user and he make a hidden field with id of IsAdmin and makes it value to be true:

 <input type="hidden" id="IsAdmin" value="true" />

and then he/she posts the form to your save user url. Because you are using the domain logic user model which has IsAdmin property this hidden field will map to your model and this user just managed to make himself/herself and admin in your site. This is precisely why you need view models so this scenario can never happen.

Upvotes: 1

Related Questions