шаблон репозитория с устаревшей базой данных и Linq to SQL

Question

Я создаю приложение поверх устаревшей базы данных (которую я не могу изменить).Я использую Linq to SQL для доступа к данным, что означает, что у меня есть класс (Linq to SQL) для каждой таблицы.

Моя модель домена не совпадает с базой данных.Например, есть две таблицы с именами Users и Employees, и поэтому у меня есть два класса Linq to SQL с именами User и Employee.Но в моей предметной области я бы хотел иметь User класс, который должен содержать некоторые поля из любой таблицы (но меня не волнует множество других полей этих таблиц).

Я не уверен, как мне следует проектировать свои репозитории:

• должны ли репозитории выполнять сопоставление между классами Linq и SQL (например User, Employee) к классам предметной области (User) и возвращать приложению только доменные классы
• или мои репозитории должны возвращать Linq к классам SQL и оставлять сопоставление вызывающему

Первый подход кажется мне более осмысленным, но является ли это правильным способом реализации моих репозиториев?

Answer 1

Пурист (я стараюсь оставаться чистым) скажет вам, что ваша модель представляет ваши данные.И поэтому все, что необходимо сохранить, делается только тогда, когда это необходимо, через репозитории.Кроме того, когда у вас есть сложные объекты, вы хотите использовать сервис для их объединения.Например, объект User + Employee = UserEmployee, доступный только через IUserEmployeeService.

С этими расплывчатыми заявлениями у вас здесь есть прекрасная возможность.

Создайте уровень защиты от коррупции, который позволит вам одновременно начать отказываться от устаревшей базы данных.

Это еще одна глава в сборнике пьес DDD.Уровень защиты от коррупции используется для взаимодействия с устаревшей системой с использованием фасадов, трансляторов и адаптеров, чтобы изолировать устаревшую базу данных от вашей чистой модели предметной области.

Теперь, возможно, потребуется намного больше работы, чем вы хотели.Итак, на этом этапе вы должны спросить себя:

Хочу ли я начать процесс удаления этой устаревшей базы данных, или она останется на весь срок службы приложения?

Если ваш ответ таков, что вы можете начать миграцию, то смоделируйте свой реальный домен так, как вы этого хотите.Сохраняйте его в обычных репозиториях и сервисах.Получайте удовольствие, оформляя его так, как ВЫ хотите, чтобы он хранился.Затем воспользуйтесь сервисами aggregate roots, чтобы получить доступ к уровню защиты от коррупции и извлечь объекты, сохранить / обновить их локально и преобразовать в объекты вашего домена.

Если ответ заключается в том, что устаревшая база данных останется на весь срок службы проекта, то ваша задача намного упрощается.Используйте сервисы вашего домена (напримерUserEmployeeService) для доступа к интерфейсам пользователя и сотрудника антикоррупционной службы (аналогично концепции "Удаленного сервиса").

Внутри фасадов получите доступ к устаревшей базе данных с помощью адаптеров (например,LegacyDbSqlDatabase), чтобы получить необработанный legacyUser().Следующим шагом было бы использовать UserTranslator() и EmployeeTranslator() mapper, которые преобразуют устаревшие пользовательские данные в версию объекта User () вашего фактического домена и возвращают их с пользовательского интерфейса обратно в ваш UserEmployeeService, где они объединяются с объектом Employee, который пришел из того же места.

Ого, это было очень много машинописи...

С помощью ваших адаптеров и фасадов вашего антикоррупционного уровня вы можете выполнять Linq-to-Sql или все, что вы хотите сделать.Это не имеет значения, потому что вы полностью изолировали устаревшую базу данных / систему от вашего приятного и чистого Домена - вашего домена, который имеет свою собственную версию сущностей User() и Employee () и объектов value.

Answer 2

DDD и Linq To SQL не очень хорошо сочетаются друг с другом, потому что созданные классы не должны существенно отличаться от структуры таблицы вашей базы данных.Вам придется либо сопоставить свои классы таким образом, чтобы работа с Linq to SQL была болезненной, либо просто смириться с неидеальной объектной моделью.

Если вы действительно хотите использовать DDD и шаблон репозитория, выберите Entity Framework или даже лучше NHibernate.