C# Entity Framework – Should Data Access Layer Return DTOs or EF Models?

centity-framework

So say I have a controller Method

    // GET: TimeEntries
    [HttpGet("[action]")]
    public IEnumerable<TimeEntryDTO> GetLast(int value)
    {
        return dal.GetLast(value);
    }

And a data access layer method of (using AutoMapper to convert TimeEntry to TimeEntryDTO)

    public IEnumerable<TimeEntryDTO> GetLast(int value)
    {
        return db.TimeEntries.TakeLast(value).ProjectTo<TimeEntryDTO>();
    }

My Question is should I do this, and have the DAL (Data Access Layer) return the DTO (Data Transfer Object) or should I have the DAL return an IQuerable of the EF Model, and then convert it to a DTO in the controller method?

EDIT:

After doing some more reading, isn't the DBsets exposed by an EF context, in fact, the repository surface? So you wouldn't really ever see the actual DAL right, because it is a layer inside EF? So I should not call a layer that is on top of the EF Context, a DAL?

Best Answer

...should I have the DAL return an IQuerable of the EF Model...

Please don't do this. As Mark Seemann explains in IQueryable is Tight Coupling, this interface suffers from a number of problems.

It's what's often referred to as a "header interface". This term refers to the bad practice in languages like C whereby a .h file simply details all the public functions found in the corresponding .c file. No consideration is given to the needs of the consumer, they simply get everything in one big lump. This means that IQuerable is a huge interface that is incredibly difficult to mock when writing unit tests around methods that return it. Have a look at the 16 part series on how to write an implementation of IQuerable to get an idea of how hard this can be.
It's a leaky abstraction. It's effectively an interface written to reflect the design of the Entity Framework ORM. As such, it exposes much of the functional design of that ORM in the interface, ie those implementation details "leak out" through the interface. So by exposing IQuerable in your DAL API, you couple your DAL to it and you couple consumers of that API to it.

The whole purpose of abstractions is to decouple parts of your code. Using an interface that actually couples things together defeats the whole purpose of an abstraction. So don't do this.

Instead, stick to your other suggestion: convert those implementation details of IQuerable into DTOs that are focused on supplying just what the caller needs. This requires a bit more work as you have to write the DTOs and the conversion code, but it pays dividends in keeping things decoupled and easier to understand and test.

Related Solutions

Data Access Layer – Using Business Objects in C#

Your DAL should return your data objects

Ideally your DAL should be a "black box" object, that your application code can use to ask for a data object or manipulate existing data objects. Sometimes there is another layer put between the DAL and the application code called the Repository, which further separates the two layers, although this is not always needed.

In addition, you usually do not want your business objects being able to create themselves. This can cause security holes where someone can use your library, and create a new instance of your object by calling .Load(someId) on it, and it merges together two layers that should be completely separate.

I also don't recommend providing a.Load(DataSet ds) method because if the data set definition changes, you'll have to hunt down the data objects which use that data set and change them. It's easier to keep all your data access code in one place, so if you change the data access query, you should only have to change your DAL layer.

C# – Confused on how to properly employ a Repository Pattern with Service/Business Layer on top

How large is your application? There's a good chance you're overthinking this. Unless the application is a large, enterprise-grade application, the high degree of loose coupling you are advocating is probably unnecessary.

If you decide that this level of loose coupling is still necessary, create a service layer that returns "service" objects. This fulfills a similar function to View Models in MVC. You will then write code in your service layer that maps objects from your domain model to your service model.

Note that part of your struggle may be due to the fact that, while your Data Repository is returning CRUD objects, your Service Layer should be returning the result of actions. For example:

public InvoiceView GetInvoice(int invoiceID);

returns a InvoiceView object containing whatever data you wish to expose to the public, including Name, Address, Line Items and so forth, from several different tables/objects in your domain.

public class InvoiceView
{
    public int InvoiceID;
    public Address ShippingAddress;
    public Address BillingAddress;
    public List<LineItem> LineItems;
    ...
}

Similarly, there will be Service Layer methods that simply performs an action and returns an object indicating the result of the action:

public TransactionResult Transfer(
    int sourceAccountID, int targetAccountID, Money amount, ValidationToken token);

IMPORTANT: You'll never be able to completely decouple from your data. Your consumer will always have to have some knowledge of the data, even if it's just an object ID or UUID.

Best Answer

Related Solutions

Data Access Layer – Using Business Objects in C#

C# – Confused on how to properly employ a Repository Pattern with Service/Business Layer on top

Related Topic