Should I implement DTOs in repository pattern with EF? [closed]

Question

In my project I'm using EF Code First approach. I have a repository layer, service layer and presentation layer (ASP.NET MVC). I'm using a dedicated viewmodel for each view.

What I'm confused about is that should my services return entities to the controller for mapping them to the viewmodels, or should I implements DTOs and return them from services?

So the question is when the flow is like "EF -> Repository -> Service -> UI", what will be the data transformation. "Entity -> DTO -> Viewmodel" or "Entity -> Viewmodel"?

It seems like if I use DTOs, they'll kinda repeat entities.

I'm trying to follow best practices.

Gilkey

Answer 1

Use the DTO approach.

This will help you a lot to keep your application independent from database structure changes.

Mapping the EF entities up into the presentation layer will make any DB changes a pain to maintain. So many places you will need to keep an eye on.

As two examples of the different aproaches: Right now, I am working on a huge project that was originally binding directly to EF entities. This leads to all sorts of complications. There are parts that require extensive code changes for even small DB adjustments. On the other hand, at my home pet project, I was able to change the entire database system 3 times without troubles because I had good abstraction layers in between.

Especially now at the start, where your project architecture ist still clean, the work to implement the DTOs seems to be duplicated. But that may change over time when your several application layer start their own lives.

If you dread the seemingly duplicate work for implementing the DTOs, there are mapping libraries like AutoMapper that can take a lot of that pain away from you.

Setose

Answer 2

It's very difficult to tell, because it all depends on your application and the complexity of it. If you have a lot of transformations, I'd say use a DTO, if not just go from entity to ViewModel.

In general, I'd start out with as little transformations as possible. When things get complicated you can still add another layer in between. Remember that it is easier to add a layer of abstraction then to remove one.

Cladoceran

If your entities are ridiculously simple, why would you ever create another layer with DTOs? I concur with Kenneth: it's a lot easier to add layers of DTOs and the like than it is to remove them. – Callicrates

Answer 3

the best way for MVC (and almost others in general) is to do EF -> DTO - > ViewModel -> View.

you should never use EF as entities bound to the View. you will shoot yourself in the foot but also defeats the purpose of MVC - your model part.

so create your EF but also then create your model which gets bound to the View. yes, seems like duplicate work but really, its not - it gives you more fine grain control one what to show or contain in your model for the view.

Battalion

I would argue that for less complex applications that DTO == View model. – Pithecanthropus

Sure but wouldn't be best practice. Less complex usually turns out to be complex in the end. Start correctly from the get-go and save time, hassle, trouble at all costs. – Battalion

Answer 4

In an ideal world, everything would be separated with no coupling. However, in the real world, that isn't always pragmatic.

Taking your scenario, unless you are using an N-tiered architecture (which you don't appear to be, more a layered one) or your service is only interested in a very limited amount of data from your entities, I would say DTOs are over kill. CodeFirst entities are very lightweight compared to the proxy entities generated by EF so the introduction of a DTO just to carry that same information to another layer is unnecessary.

Personally I would make my entities implement a common interface which I would then use to return from my service layer instead. It means your services are effectively tied to your DAL (which I guess isn't that great) but in your circumstance it would do the job. This gives you the flexibility to then swap out for actual DTOs later in your service layer if you change your mind later.

Cloudy