Проектирование уровня доступа к данным - PullRequest
Новая
       9

Проектирование уровня доступа к данным

4 голосов
/ 04 октября 2009

Я сталкиваюсь с проблемой дизайна относительно того, как проектировать мой DAL. Как мы все знаем, в самом базовом определении DAL означает слой который отвечает за связь с некоторым хранилищем данных (конечно, я не говорю о шаблоне хранилища), обычно база данных. Теперь вот где подвох. Некоторые из наших бизнес-объектов должны будут получать свои данные из базы данных, а некоторые - свои данные из других источников, то есть веб-сервисов. Несколько наших членов в команде предложили, чтобы BO были достаточно умны, чтобы знать, следует ли вызывать DAL (который знает только, чтобы общаться с базой данных) или позвоните в требуемый веб-сервис. Другие полагали, что это не может быть оптимальным решением, полагая, что все должно проходить через DAL, где он будет содержать, скажем, адаптеры или что-то еще, для каждого метода извлечения данных.

Как бы вы разработали систему с такими потребностями в доступе к данным? Может ли какое-либо из предложенных решений быть достаточно хорошим в долгосрочной перспективе (второе может занять больше времени для разработки) или нам нужен совершенно другой подход? Возможно, есть шаблон дизайна, который подходит для такого рода проблем ...

Спасибо, Ави Шилон

1 Ответ

6 голосов
/ 04 октября 2009

Я бы настоятельно рекомендовал второй подход. Бизнес-логика не должна ничего знать об источнике данных.

Когда он не знает, в дополнение к обычным преимуществам (более простое обслуживание благодаря изоляции и более чистому дизайну), у вас также есть гибкость (в зависимости от того, насколько хорошо разработан ваш DAL):

  • Как указано в вашем минимальном требовании, получить данные из различных источников данных

  • Извлечение данных из приоритетного набора источников данных для достижения отработки отказа.

    например. вы получаете последние котировки цен от службы Reuters в режиме реального времени, но когда это происходит из-за проблем с глобальной сетью, вы прибегаете к альтернативному сервису или к более старым ценам, кэшированным в базе данных.

    Очевидно, что источники данных упорядочены в приоритетном порядке: не увеличивается качество и не уменьшается надежность.

  • Извлечение данных из приоритетного набора источников данных для достижения кэширования

    например. получить цену из локального кэша, если она отсутствует, получить из локальной базы данных, если она отсутствует, запросить службу поставщика.

Кроме того, просто для того, чтобы наглядно продемонстрировать простоту сопровождения, если ваш источник данных из службы запрашиваемого поставщика в реальном времени изменится на внутреннюю базу данных с золотым копированием, заполняемую push-рассылкой от поставщика, вам потребуется только изменить DAO вместо каждого из множества BO, которым нужны данные. Легче изменить и безопаснее тестировать и внедрять изменения.

...