Делая OR/M слабо связанным и удаленным от других слоев
В n-уровневой архитектуре лучшее место для размещения кода объектно-реляционного отображения (OR/M) - это уровень доступа к данным. Например, запросы и обновления базы данных могут быть делегированы такому инструменту, как NHibernate.
Тем не менее, я хотел бы сохранить все ссылки на NHibernate в пределах уровня доступа к данным и абстрактных зависимостей от уровней ниже или выше его. Таким образом, я могу заменить или подключить другой инструмент OR / M (например, Entity Framework) или какой-либо подход (например, простые вызовы хранимых процедур ванили, фиктивные объекты), не вызывая ошибок во время компиляции или капитального ремонта всего приложения. Тестируемость является дополнительным бонусом.
Может кто-нибудь предложить, пожалуйста, оболочку (то есть интерфейс или базовый класс) или подход, который позволил бы OR / M свободно соединяться и содержаться в 1 слое? Или укажите мне ресурсы, которые могли бы помочь?
Благодарю.
2 ответа
Похоже, вы ищете шаблон хранилища. Если вам нужна дополнительная развязка, вы можете внедрить зависимости данных с помощью контейнера Inversion of Control.
Схема обслуживания фасада - это одно имя. Простые контракты между бизнес-логикой и уровнем данных.
Классы обслуживания или компоненты (называемые так, как вы хотите) определяют и реализуют контракт, а также организуют нижний уровень данных, часто обрабатывая логику транзакций в объектах данных.
Весной вы определяете интерфейс, а затем внедряете его. Одна реализация может быть OR/M, другая может быть необработанной JDBC или ADO.NET. В некоторых средах Аспектно-ориентированное программирование позволяет вводить декларативную транзакционную логику без написания кода. Это избавляет от головной боли.
Одно предостережение: при работе с некоторыми OR/M, такими как Hibernate, используются прокси-классы. Это загрязняет вещи, потому что есть несколько случаев, когда прокси-классы вызывают проблемы. На мой взгляд, это деталь реализации, которая не должна выходить за пределы сервисного уровня. Но с Hibernate это так. Не уверен насчет реализации.NET.