Do I need to create DTOs if I am using EF and Viewmodels?

Question

I have read that Entity Framework (I am using EF6) is an abstraction from the database. I am using viewmodels to serve up the data to my views so the EF entity would not go past my controller. I am using repositories with linq queries to get the data. In the controller I instantiate the repo and get the data.

So is there any reason to create a dedicated object for the transaction between the controller and the repo?

Example:

Database has a table Person.

In MVC app I create an edmx file, which creates a partial class called Person.

In my Repository:

class Person PersonRepository()
{
    public Person GetPerson()
    {
      using (var db = new MyEntity())
      {
        var data = db.Person.FirstOrDefault();

        var person = new Person()
        {
            Id = data.PersonId,
            FirstName = data.FirstName,
            LastName = data.LastName
        };
        return person;   
    }
}

Or do I need to do this:

class Person PersonRepository()
{
    public Person GetPerson()
    {
      using (var db = new MyEntity())
      {
        var data = db.Person.FirstOrDefault();

        var person = new PersonDTO()
        {
            Id = data.PersonId,
            FirstName = data.FirstName,
            LastName = data.LastName
        };
        return person;   
    }
}

Short answer no, given the fact that you're using POCOs, take a look here http://stackoverflow.com/questions/3779508/what-is-the-best-practice-for-sending-data-to-the-client-poco-or-dto — dnlgmzddr, Aug 06 '15 at 19:44
In the example you provide i would say there is no point in even doing what your are now, of course that may change if you need to add view specific data to your view models, but you can refactor as and when. Remember YAGNI (you ain't gonna need it). — Ben Robinson, Aug 06 '15 at 19:55

score 3 · Accepted Answer · answered Aug 06 '15 at 19:43

It all depends of the expected complexity of your application. So there is no one way to do such things. Basically a DTO class should contain only field that are needed to be transfered to front-end layers, whereas ViewModel classes contain data that is specifically adapted to the Views. You must ask yourself a question if the design of those objects will be the same, i.e. if the business layer won't be polluted with some view specific logic and concepts, or if the view layer won't be polluted with some data/business layer related logic. If the application is not so big, and the data needed for the views, and gotten from the repository is not expected to be much different, you can stick only with ViewModel classes, but if there are some differences, or may be in the future, it's better to have seperate classes and handle the differences on the mappers.

You mean that the Person class is send to the browser trough WebAPI and then some JS framework takes care of displaying it? If yes - I would say that in C# we make DTO classes available on the controllers, the ViewModel concept I would put into the JS side of the app — alek kowalczyk, Aug 06 '15 at 20:17

Do I need to create DTOs if I am using EF and Viewmodels?

1 Answers1