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

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

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

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

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

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


linq-to-sql domain-driven-design ddd-repositories
person M4N    schedule 28.10.2009    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

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

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

Хочу ли я начать процесс удаления этой устаревшей БД или она останется на все время существования приложения?

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

Если ответ таков, что устаревшая БД останется на все время существования проекта, то ваша задача будет намного проще. Используйте службы вашего домена (например, UserEmployeeService) для доступа к UserFacade и EmployeeFacade антикоррупционной защиты (аналогично концепции «удаленного обслуживания»).

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

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

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

person eduncan911    schedule 28.10.2009

arrow_upward
1
arrow_downward

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

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

person Manu    schedule 28.10.2009