ASP.net working with entities

Question

I have some kind of misunderstanding of working with entities in asp.net mvc concept.

I am pretty new to asp.net mvc and when I was studying I was told that whenever I work with databases I have to create a Model which will be a copy of generated by EF. And sending to views and all the calculations are done with that model..

For example if I have entity Person with something like:

public int EmployeeId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public Nullable<System.DateTime> DateOfBirth { get; set; }

I have to generate class (EmployeeViewModel) in my Model folder:

public class EmployeeViewModel
{
   public int EmployeeId { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public Nullable<System.DateTime> DateOfBirth { get; set; }
}

and in my controller I was usually doing something like this to get data about one Employee from database to my model (something similar if list of employees):

var Employee = db.Employees.Where(item => item.EmployeeId == someId).Select(item => new EmployeeViewModel
            {
                EmployeeId = item.EmployeeId ,
                FirstName = item.FirstName ,
                LastName = item.LastName ,
                DateOfBirth = item.DateOfBirth 
            }).FirstOrDefault();

This code works, but the concept of working with this custom model, which is just a copy of an entity seems to be strange.. I understand that this concept of creating custom models is useful if our custom model differs from the entity.

So do I have to do it anyway, or I can work straight with entities in some cases. I would be glad if you could recommend some articles or something else to get the idea, how do I have to work with databases in my mvc projects, so as it would be correct in sense of its original concept.

[What is ViewModel in MVC?](http://stackoverflow.com/questions/11064316/what-is-viewmodel-in-mvc) (and note that they should be in a separate folder (say `ViewModels`) not your `Models` folder) — , Mar 15 '17 at 11:55
You can do it any way you like, as long as it works. However, doing it this way is best practice and allows you further functionality. For example, if you create a `View` and pass through `@model EmployeeViewModel` you can simply use `Html.LabelFor(m => m.FirstName)` and `Html.TextBoxFor(m => m.FirstName)` which will automatically generate a `label` with `FirstName` and a `textbox` for you. — Christopher Lake, Mar 15 '17 at 11:57

score 3 · Accepted Answer · answered Mar 15 '17 at 11:59

You don't have to create copies of all of your models. In fact, if they are nothing more than carbon copies which don't add any value of any kind, then you really shouldn't be making them.

Just about any C# class can be the model that is bound to the view. If your Entity Framework model fits the business need of the view, then there's little-to-no value in adding a translation layer between the two.

There is often personal preference in which the developer wants to keep the database models and the application models separate. The objective need for this separation depends on the architecture of the system being built. (No details of which are described in this question.)

Conversely, there's equally an argument to be made of a single set of dependency-free business models which are used throughout every layer of the application. This side is often proposed by asking the question... If your use case (what the user does in the view) doesn't line up with your system architecture, shouldn't the latter be changed to better facilitate the former?

In short, you certainly can create a hard line of separation between different classifications of models for different layers of the application. But whether or not you should is a larger matter. If in your case doing so creates additional work and additional complexity without any additional value, then that seems to indicate that it's not necessary.

ASP.net working with entities

1 Answers1