Q&A

Stop Using Entity Framework as Just a DTO Provider

• By David Ramel
• 07/23/2024

Chris Klug keeps seeing developers using Entity Framework in less optimal ways.

Microsoft's open-source object-relational mapper (ORM) for .NET applications is not intended to be used to replicate the database structure in code with DTOs (Data Transfer Objects), he says.

"And if one more person tells me 'We used a micro-ORM for this project, since it does the same thing as EF but without the complexity,' I will blow a gasket!" he says.

To keep his gasket intact, Klug teaches developers how they can use Entity Framework so that it supports their code, instead of dictates how to write it. He noted the framework isn't one of those dev tools where you can just read the "Getting Started with EF" page and jump right to writing code to retrieve your data from the database.

Klug teaches how to use proper OOP and still use EF to persist and retrieve data objects, and he'll do just that in November at the huge Live360! developer conference that wraps a whole slew of targeted conferences -- including Visual Studio Live! -- in one venue in Orlando.

His Nov. 20 session comes in the Data Platform Live! part of the conference and is aptly titled Stop Using Entity Framework as Just a DTO Provider!

Attendees are promised to learn:

• That EF can do more than DTO retrieval
• That it might be a good idea to use EF to fetch more complex objects
• To see how EF can support retrieving Domain-Driven Design (DDD) style entities

We caught up with Klug, a developer at Active Solution, to get a sneak peek at his intermediate-level session in a short Q&A.

VisualStudioMagazine: What inspired you to present a session on this topic?
Klug: Having an interest in DDD, and the patterns that comes with it, made me want to use Entity Framework together with entities instead of just "dumb" DTOs. And having seen that work well in quite a few projects now, I felt it was a topic that was worth talking about.

Getting to grips on mapping entities using Entity Framework makes the code look a lot better in my opinion, as it allows you to use many more OOP features like encapsulation and inheritance.

What are the common misconceptions about using Entity Framework that you frequently encounter?
That Entity Framework can only work with "dumb" DTOs with public getters and setters, which puts all the business logic in other classes. Or causes people to do a lot of unnecessary mapping back and forth between different objects. One object for the "domain" and one for the data access. Something that is completely unnecessary and causes a lot of extra code to be maintained.

Can you elaborate on the drawbacks of using Entity Framework solely for DTO retrieval?
By mapping the database to pure DTOs you basically remove the ability to encapsulate business logic and validation in the entities themselves. Which in turn causes the business logic and validation to be spread out across the solution.

How can developers leverage Entity Framework to handle more complex objects?
By understanding how Entity Framework mappings work, beyond just the basic convention-based mapping, allows you to let EF do a lot of the heavy lifting that we often end up having to do instead. It also allows you to hide a lot of the quirks that EF sometimes forces you to do, inside the entity. Thus, giving the user of the entity, a much nicer, and easier to understand interface.

What are the benefits of using Entity Framework to support Domain-Driven Design (DDD) style entities?
This comes back to the drawbacks of using DTOs. Or rather the opposite of that. Using DDD style entities allow you to use OOP features to give the end user of the entity a better user experience. Hopefully making it easier to understand how the object is meant to be used, causing less problems and confusion.

Can you provide examples of proper OOP principles applied in conjunction with Entity Framework?
Mapping private fields, and properties with private setters enables us to encapsulate the data inside the entities. Which is a core feature of object-oriented programming. And by encapsulating the data, we can limit how the data is manipulated and get better control over the validity of the object's data.

How does Entity Framework compare to micro-ORMs in terms of complexity and functionality?
EF is definitely much more complex to work with than micro-ORMs. But I think this boils down to the fact that EF is able to do much more than just mapping a database record to an object. For example, it also contains change tracking logic, which simplifies developers' lives in a lot of cases. Unless you just need to do simpler CRUD operation against the database. In those cases, a micro-ORM is probably all you need. But I do think a lot of people prefer the micro-ORMs, due to lack of knowledge and experience with EF. Or potentially because of bad experiences with pre-Core versions of Entity Framework.

What are some best practices for optimizing Entity Framework performance in real-world applications?
I would say that one of the best ways to optimize EF performance is to separate the read from the write objects. For the writes, it is very often ok to have slightly slower queries, as reads often outnumber writes with order of magnitudes. And for the pure reads, you can have more specific DTOs being mapped, as this often allows you to retrieve less data. And makes the workload that EF carries out less taxing. You might even want to turn to custom T-SQL queries for those more complex but often used queries, and have EF map the returned values for you.

Note: Those wishing to attend the conference can save hundreds of dollars by registering early, according to the event's pricing page. "Save $500 when you Register by Aug. 16!" said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.