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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.