DTO, уровень данных и возвращаемые типы
На моей работе мы используем Entity Framework для доступа к данным. Я создаю уровень доступа к данным, уровень доступа к бизнесу и несколько различных типов проектов для доступа к BLL (webAPI для взаимодействия с клиентскими приложениями, несколько веб-сайтов MVC и несколько различных настольных приложений WinForm).
Я добавил DTO в отдельный проект под названием «DTO». Целью этого проекта в рамках этого решения является создание библиотеки DLL со всеми определениями для классов и интерфейсов, которые будут передаваться назад и вперед. Таким образом, этот один проект может быть создан как подмодуль git в других решениях и обновлен для всех проектов пользовательского интерфейса для совместного использования. Я не буду работать над всеми пользовательскими интерфейсами, поскольку мы привлекаем к проекту больше разработчиков, и нам, вероятно, потребуется несколько решений VS.
Я думал, что уровень доступа к данным вернется и будет принимать DTO вместо объектов сущностей. Это полностью отделит процесс.
Если мы когда-либо захотели заменить DAL чем-то другим, если он соответствует интерфейсам, определенным в проекте DTO, все будет в порядке. Я также думаю, что это упростит тестирование, поскольку я могу заменить DAL проектом для создания DTO с чем-то вроде Seed.net. Замена BTW - реальная возможность, учитывая нашу среду.
Добавление этого уровня сложности - плохо или противоречит стандартам дизайна? Что-то мне не хватает?
Нет, это не противоречит стандарту, а наоборот: это стандарт, известный как Многослойная архитектура дизайна. Я не совсем понимаю, что вы имеете в виду под DTO интерфейс. Если вы имеете в виду C# интерфейс, то довольно странно, чтобы DTO реализовал интерфейс. Если вы имеете в виду публичный интерфейс, то это нормально.
Ответы 1
Я так работаю, и, проработав несколько лет в облачном мире, похоже, так работают все. Обычно у вас есть следующие проекты (каждая сборка для отдельной сборки)
- 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.
Самое замечательное в этом заключается в том, что если вы добавите инверсию зависимостей (IoC), вы можете создать фиктивный репо, чтобы изолировать и протестировать уровень службы (бизнес-логика) и так далее, введя его в модульные тесты NUnit.
Довольно часто люди в отрасли (включая меня) используют AutoMapper для преобразования моделей в DTO в сущности и наоборот.
Хотя это самоуверенный вопрос, то, что вы описываете, IMHO довольно часто встречается в таких сценариях. DAL довольно часто получает и возвращает DTO вместо сущностей, и я бы не стал рассматривать это как дополнительную сложность, учитывая преимущества.