Делая OR / M слабо связанным и абстрагированным от других слоев - PullRequest
Новая
       17

Делая OR / M слабо связанным и абстрагированным от других слоев

1 голос
/ 27 марта 2010

В n-уровневой архитектуре лучшее место для размещения кода объектно-реляционного отображения (OR / M) - это уровень доступа к данным. Например, запросы и обновления базы данных могут быть делегированы такому инструменту, как NHibernate.

Тем не менее, я хотел бы сохранить все ссылки на NHibernate на уровне доступа к данным и абстрактные зависимости от уровней ниже или выше него. Таким образом, я могу заменить или подключить другой инструмент OR / M (например, Entity Framework) или какой-либо подход (например, простые вызовы хранимых процедур ванили, фиктивные объекты), не вызывая ошибок во время компиляции или серьезной перестройки всего приложения. Тестируемость является дополнительным бонусом.

Может ли кто-нибудь предложить обертку (то есть интерфейс или базовый класс) или подход, который бы позволял OR / M быть слабо связанным и содержаться в 1 слое? Или укажите мне ресурсы, которые могли бы помочь?

Спасибо.

Ответы [ 2 ]

2 голосов
/ 27 марта 2010

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

0 голосов
/ 27 марта 2010

Шаблон сервисного фасада - это одно имя. Простые контракты между бизнес-логикой и уровнем данных.

Сервисные классы или компоненты (назовите это как хотите) определяют и реализуют контракт, а также организуют нижний уровень данных, часто обрабатывая логику транзакций для объектов данных.

В Spring вы определяете интерфейс, а затем внедряете его. Одна реализация может быть OR / M, другая может быть необработанной JDBC или ADO.NET. В некоторых средах Аспектно-ориентированное программирование позволяет вводить декларативную транзакционную логику без написания кода. Это избавляет от головной боли.

Одно предостережение: при работе с некоторыми OR / M, такими как Hibernate, используются прокси-классы. Это загрязняет вещи, потому что есть несколько случаев, когда прокси-классы вызывают проблемы. На мой взгляд, это деталь реализации, которая не должна выходить за пределы сервисного уровня. Но с Hibernate это так. Не уверен насчет реализации .NET.

...