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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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