Search code examples
c#design-patternsdata-access-layerdto

DTO, Data Layer and types to return

At my job we use Entity Framework for data access. I am creating a Data Access Layer, a Business Access Layer and a few different types of projects to access the BLL (webAPI for client applications to interface with, multiple MVC websites and a few different desktop WinForm applications).

I added the DTOs to a separate project named "DTO". The goal of this project within this solution is to have a DLL with all the definitions for the classes and interfaces that will be past back and forth. That way this one project can be created as a git submodule within other solutions and updated for all the UI projects to use collectively. I will not be working on all the UIs as we bring more developers into the project and we will probably need to have multiple VS solutions.

My thought was to have the Data Access Layer pass back and take in DTOs instead of entity objects. This would decouple the process completely.

If we ever wanted to replace the DAL with something else as long it followed the interfaces defined in the DTO project we should be fine. I also think it would make testing easier as I can replace the DAL with a project to generate the DTOs with something like Seed.net. BTW replacement is a real possibility given our environment.

Is adding this layer of complexity bad or against design standards? Is there something I am missing?

Solution

  • This is the way I work, and having worked in the Cloud world for some years now, it seems to be the way everyone works. Typically you have the following Projects (each build to an individual Assembly)

    - REST controllers
- Models 
    that are used to pass information between Controller layer and Business Logic
- Business Logic Interfaces  (like ImyService)
- Business Logic  (like myService)
- DTOs
- IRepository (like ImyRepo)
- Repository (like myRepo)
     --> this is the same as DAL.

    The great thing with doing this is that if you add Dependency Inversion (IoC) then you can make a mock Repo, in order to isolate and test the Service (Business Logic) layer and so on by injecting it into NUnit unit tests.

    Quite often people in the industry (including me) use AutoMapper to convert Models to DTOs to Entities and the reverse.