Как я могу постепенно перейти к логике персистентности NHibernate из существующей логики персистентности ADO.NET?

Question

Приложение использует ADO.NET для вызова sprocs практически для каждой операции с базой данных. Некоторые из этих sprocs также содержат достаточное количество логики домена. Логика доступа к данным для каждого объекта домена находится в самом классе домена. т. е. нет разделения между логикой домена и логикой доступа к данным.

Я хочу сделать следующее:

• отделить доменную логику от логики доступа к данным
• делает постоянство модели домена невежественным
• осуществить переход к NHibernate постепенно между выпусками, рефакторинг отдельных частей DAL (если это можно так назвать) за один раз

Вот мой подход к переходу одного класса на постоянство NHibernate

1. создать сопоставление для класса домена
2. создать репозиторий для класса домена (базовые операции CRUD, унаследованные от универсального базового репозитория)
3. создать метод в репозитории для каждого sproc, используемого старым DAL (выполняя некоторый рефакторинг по пути извлечения логики домена)
4. изменить потребителей для использования хранилища, а не логики доступа к данным в самом классе
5. удалить старую логику доступа к данным и sprocs

У меня проблемы с № 1 и № 4.

(# 1) Как сопоставить свойства типа без сопоставления NHibernate?

Рассмотрим класс Person со свойством Address (Address является объектом домена без сопоставления NH, а Person является классом, который я отображаю). Как я могу включить Адрес в отображение Персона, не создавая полное сопоставление для Адреса?

(# 4) Как мне управлять зависимостями от старой логики доступа к данным во время перехода?

Классы в модели предметной области используют старую логику доступа к данным, которую я хочу удалить. Рассмотрим класс Order со свойством CustomerId. Когда Заказу требуется информация о Клиенте, он вызывает логику доступа к данным ADO.NET, которая находится в классе Customer. Какие есть варианты, кроме поддержки старой логики доступа к данным до тех пор, пока зависимые классы не отобразятся сами?

Answer 1

Я бы подошел к этому так:

1. Рефакторинг и перемещение логики доступа к данным из классов домена на уровень данных.
2. Рефакторинг и перемещение доменной логики из цепей в слой данных. (Этот шаг не является обязательным, но его выполнение определенно сделает переход более плавным и легким.)
3. Вам не нужен репозиторий, но вы, безусловно, можете создать его, если хотите.
4. Создайте отображение NHibernate для каждого класса домена (есть инструменты, которые делают это).
5. Создание API доступа к данным, ориентированного на NHibernate, который медленно заменяет уровень данных sproc.

Шаги 1 и 2 являются самыми сложными, так как кажется, что у вас тесная связь, чего в идеале никогда бы не было. Ни один из этих первых двух шагов вообще не включает NHibernate. Вы строго переходите к более поддерживаемой архитектуре, прежде чем пытаться поменять уровень данных.

Хотя может быть возможно создавать сопоставления NHibernate одно за другим и использовать их без полного графического объекта, кажется, что это требует ненужной боли. Вы должны действовать очень осторожно, если вы выберете этот путь, и я просто не рекомендую его. Для этого вы можете оставить внешний ключ отображенным как обычный int / guid, а не как отношение к другому классу домена, но вы должны быть очень осторожны, чтобы не повредить ваши данные, наполовину передавая таким образом NHibernate. Автоматизированные модульные / интеграционные тесты - ваш друг.

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

Answer 2

поиск в Интернете для электронных книг nhibernate

1. Рефакторинг и перемещение логики доступа к данным из классов домена на уровень данных.
2. Рефакторинг и перемещение доменной логики из цепей в слой данных. (Этот шаг не является обязательным, но его выполнение определенно сделает переход более плавным и легким.)
3. Вам не нужен репозиторий, но вы, безусловно, можете создать его, если хотите.
4. Создайте отображение NHibernate для каждого класса домена (есть инструменты, которые делают это).
5. Создание API доступа к данным, ориентированного на NHibernate, который медленно заменяет слой данных sproc