Является ли DTO плюс шаблон UnitOfWork хорошим подходом к разработке DAL для веб-приложения?
Я реализую DAL с использованием entity framework. В нашем приложении у нас есть три уровня (DAL, бизнес-уровень и презентация). Это веб-приложение. Когда мы начали внедрять DAL, наша команда думала, что DAL должен иметь классы, методы которых получают ObjectContext, предоставленный службами на бизнес-уровне, и работают над ним. Обоснование этого решения состоит в том, что разные ObjectContexts видят разные состояния БД, поэтому некоторые операции могут быть отклонены из-за проблем с сопоставлением внешних ключей и других несоответствий.
Мы заметили, что создание и распространение контекста объекта из уровня сервисов порождает сильную связь между слоями. Поэтому мы решили использовать DTO, отображаемые Automapper (не неуправляемые сущности или сущности с самопроверкой, аргументирующие высокую степень связи, подвергая сущности верхним уровням и низкую эффективность) и UnitOfWork. Итак, вот мои вопросы:
- Это правильный подход к разработке веб-приложения? s DAL? Почему?
- Если вы ответили «да» на 1., как это согласовать концепцию DTO с шаблонами UnitOfWork?
- Если вы ответили «нет» на 1., это могло бы быть правильным подходом к разработать DAL для веб-приложения?
Пожалуйста, по возможности дайте библиографию, подтверждающую ваш ответ.
О текущем дизайне:
Приложение планировалось разрабатывать на трех уровнях: презентация, бизнес и DAL. Бизнес-уровень имеет и фасады, и сервисы
. Существует интерфейс, называемый ITransaction (только с двумя методами для удаления и сохранения изменений), видимый только в сервисах. Для управления транзакцией существует класс Transaction, расширяющий ObjectContext и ITransaction. Мы разработали это с учетом того, что на бизнес-уровне мы не хотим, чтобы другие методы ObjectContext были доступны.
В DAL, мы создали абстрактный репозиторий, используя два общих типа (один для объекта, а другой для связанного с ним DTO). В этом репозитории есть CRUD-методы, реализованные общим способом, и два универсальных метода для сопоставления DTO и сущностей универсального репозитория с помощью AutoMapper. Конструктор абстрактного репозитория принимает ITransaction в качестве аргумента и ожидает, что ITransaction будет ObjectContext, чтобы назначить его своему защищенному свойству ObjectContext.
Конкретные репозитории должны получать и возвращать только типы .net и DTO.
Мы теперь столкнулись с этой проблемой: общий метод create не генерирует временный или постоянный идентификатор для прикрепленных сущностей (пока мы не используем SaveChanges () , что нарушает транзакционность, которую мы хотим); это означает, что методы службы не могут использовать его для связывания DTO в BL)