Should I think of Entities in EF as Domain Models or DTO's?

Question

I am new to Entity Framework (Code first, if it matters). As I have been using it, I have been building my POCO classes, thinking of them as final domain models. With things like Lazy Loading, I like the Idea that I can use these entities directly in my presentation layer, getting to lazy load the stuff that I actually need.

However, I also recently learned about Data Transfer Objects, something I hadn't heard of before. It absolutely makes sense; the behavior of my final Domain Model might have some business rules that don't belong in the DAL. For instance, should the POCO SalesOrder that i give to Entity Framework include it's final methods like AddItem(Product), which throws an exception if Product has a DiscontinuedDate that is before the SalesOrder.OrderDate. That definitely sounds like stuff that belongs in the BLL.

So, I suppose this means that the POCO classes that I give Entity Framework should be more like DTO's?, like SalesOrderDto and EmployeeDto just simple little data holders with just properties and no methods that then get mapped (probably using AutoMapper) to Domain Objects in my BLL, which then get passed to the Presentation Layer?

Am I on the right track here, Or am I missing something. I feel confused because the idea of DTO's make perfect sense, but I have never seen them used in the context of Entity Framework.

Answer 1

Entity Framework is an Object Relatonal Mapper. Entities are therefore mappings to your relational tables.

They are

simple little data holders with just properties and no methods

yes.

Answer 2

It's up to you. Only properties are mapped, so you can freely add methods (and with Database First partial classes get generated so you can do the same).

Usually, business objects don't necessarily directly map to storage objects. In that case your business object can exist out of one or more storage objects, whether or not to (auto)map these to DTO's first is also up to you.

Note however that business logic should not reside in entities anyway. While it might be tempting to just stick the Customer.FullName property (which returns Customer.FirstName + " " + Customer.LastName), you will want logic like this (just as the RegisterCustomer() method) in the appropriate class.

Answer 3

In some simple cases, entities may be DTOs, view models and domain models (in very simple cases - at the same time).

But, in general, it is better to keep separate DTO's, separate view models, and separate domain models. There are many specific things, that can be required, for example, for presentation layer or DTOs, but you don't need them to be implemented in your entity classes.