Question

I’m writing a console application that does a good amount of data retrieval from stored procedure recordsets. For each recordset type I’m working with, I have a Repository that uses EF with custom complex types to retrieve the data:

public interface IBalanceSheetRepository
{
    IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords();
}

public class BalanceSheetRepository : IBalanceSheetRepository
{
    DBContext _context;

    ...

    public IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords()
    {
        ObjectResult<BalanceSheetRecord> results = _context.GetBalanceSheet();
        return results.Select(CreateBalanceSheetDTOFromDAO);
    }

    private static BalanceSheetRecordDTO CreateBalanceSheetDTOFromDAO(BalanceSheetRecord dao)
    {
        return new BalanceSheetRecordDTO { ... };
    }
}

Here, BalanceSheetRecord is a complex data type that I created in the designer. I created a DTO to avoid coupling since the BLL should not know about the BalanceSheetRecord type.

Here’s my question: Since the DTO type is used in the method signature of the repository interface, and since my BLL will ultimately use the repository & be returned a collection of the DTOs, it seems to be a cross-cutting concern. Therefore I have the DTO living in a separate “Infrastructure” assembly, along with the repo interfaces. Is this good practice for what I’m trying to achieve, or did I take a wrong turn somewhere?

Also: Is it bad practice to new up the data context in my repository? Is some amount of coupling OK when both components belong to the DAL? I want to use DI but it seems more useful for swapping out the DBContext implementation of the repo for a TestBalanceSheetRepository, for instance.

Answer 1

I prefer to return actual entities from my repositories. This way when you need to orchestrate complex interactions between different entities in the service layer, there’s no converting back and forth to DTO’s. The service layer then projects entities into DTO’s when returning data to the application layer.

I know there are purists who say that all interaction between layers should be done with DTO’s, but I find that impractical. The service layer will end up coupled to the entities anyway, so it’s not like you’re adding coupling.

It also limits the projection/flattening of DTO’s to entities to the service layer. Which to me is a plus since these activities add to complexity and decreases performance.

Your data context is your unit of work. The “one unit of work per repository” idea is an anti-pattern. Units of work should be scoped by the service layer, which may involve 1-many entities from 1-many repositories. If each repository has a different unit of work, you lose your ability to have service layer calls maintain consistent transactions easily.