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

Question

Я создаю приложение поверх устаревшей базы данных (которую я не могу изменить). Я использую Linq для 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. Уровень Anti-Corruption используется для взаимодействия с устаревшей системой, использующей Facades, Translators и Adapters, чтобы изолировать устаревшую БД с помощью вашей чистой модели домена.

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

Хочу ли я, чтобы начать процесс трогания этого наследия БД, или это останется для жизни приложения?

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

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

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

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

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

Answer 2

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

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