2

Self explanatory, I have a model that map 1:1 with my DB for example:

public class User
{
    [Key]
    public int UserID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Is there any downside if I use this in my View cshtml for example :

@model User

Or should I create another ViewModel like this

public class UserViewModel
{
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
}

and bind it to my View

@model UserViewModel
tickwave
  • 3,335
  • 6
  • 41
  • 82
  • Refer [What is ViewModel in MVC?](http://stackoverflow.com/questions/11064316/what-is-viewmodel-in-mvc) –  Jul 02 '15 at 07:02
  • View-model can be any type the view can use to render itself without relying on external calls. However, in your particular case, the `User` entity may eventually contain some sensitive data (like a `Password` property), and in case you'll have to serialize your view-model for some client-side script usage, it could be a problem. – haim770 Jul 02 '15 at 07:07

2 Answers2

3

The idea of a good programming is that a View should not know anything about where the data comes from ... using the Database model in the View breaks that sign.

The best is always use a ViewModel, and in the future you will be pleased about this choice as for example, a View might be only a 1:1 from a database table, but imagine that the designer wants you also to add the most recent "messages", that's just a new table call based on the user...

With a ViewModel you can easily add it and just edit your view and controller, but if you use 1:1 you will need to create a brand new ViewModel... then, some Views have ViewModels and some don't... it will be messy!

To help you out, you can always use AutoMapper to help with the ViewModels construction, AutoMapper automagically populates the destination class with the data from the original class.

var userViewModel = AutoMapper.Mapper.Map<UserViewModel>(user);

Keep in mind to separate concerns, a Controller should not know where the data comes from (hence, using Repositories) and a View should not do data manipulation (hence the Controller).

balexandre
  • 73,608
  • 45
  • 233
  • 342
0

In general using multi-tier architecture is good point if we are speaking of extensibility and maintenance, even if you are pretty sure that you will not have to display any other data than properties from entity you could not say that for 100%. In the situation when you decided to display some other data you have to extend entity what for sure won't be ok. Another reason is fact to not multiply references in your solution and in general loosing coupling. It won't be very good to have reference between Presentation layer and Data layer.

Of course your example is really simple, but for sure it won't be always that kind of scenario so direct reference between Presentation layer and Data layer is not an option.

Piotr Czarnecki
  • 1,688
  • 3
  • 14
  • 22