Владение данными и производительность

Question

Мы разрабатываем новое приложение и столкнулись с некоторым архитектурным вопросом, когда думали о владении данными.

Мы разбили систему на компоненты, например, Заказчик и Заказ.каждый из этих компонентов / модулей отвечает за конкретный бизнес-домен, т. е. клиент имеет дело с CRUD клиентов и бизнес-процессами, ориентированными на клиентов (регистрация нового клиента, блокировка учетной записи клиента и т. д.).каждый модуль является владельцем набора таблиц базы данных, и только этот модуль может получить к ним доступ.если другому модулю нужны данные, принадлежащие другому модулю, он извлекает их, запрашивая их у этого модуля.

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

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

Answer 1

У вас есть 2 общие формы ответственности объекта - CRUD и только для чтения. Модули Customer и Order владеют соответствующими данными (таблицами, правами и т. Д.) И иногда делятся ими с другими.

Я бы просто выбрал самую быструю и наиболее эффективную форму владения - не требуется, чтобы модуль Отчет запрашивал что-либо из ваших стандартных бизнес модулей. Ваши бизнес-модули будут загружены другими обязанностями. Отчеты должны запускаться как независимый модуль с собственным набором правил, доступом и т. Д. С максимально возможным использованием хранимых процедур.

Answer 2

У вас могут быть разные владельцы (или философия владения) для разных уровней решения.

Может иметь смысл применять владение данными на основе физической схемы (хотя это не всегда так).

Как только вы дойдете до уровня бизнес-логики, у вас может появиться целый ряд новых «владельцев» и областей действия - им будет принадлежать «представление» (фрагмент данных), которое они показывают, но не отдельные биты.данных, которые составляют его.Я думаю, что это совершенно нормально.

Даже на уровне хранимых процедур это нормально.То, что что-то принадлежит, не означает, что им нельзя делиться.

Answer 3

Я предложу один из двух подходов здесь

• Используя ваш пример, если вы строите корпоративную систему с потребностями в отчетах, вам следует рассмотреть возможность отделения реализации отчетности от кода и использования инфраструктуры отчетов для извлечения данных из хранилища данных и их представления. Вы примете осознанное решение обойти уровень бизнес-домена
• Вторым предложением будет создание нового уровня домена представления, который будет обслуживать данные, доступные только для чтения, в вашей системе, в этом случае он может получать / подготавливать денормализованные данные или DTO специально для индивидуальных нужд отчета. Уровень внутренних данных для предоставления этих данных может быть хранимой процедурой или другим механизмом, доступным вам в вашей среде программирования (например, LINQ в .NET), который обеспечит вам необходимую производительность. Все ваши транзакционные операции по-прежнему должны проходить через уровень бизнес-домена, поскольку уровень представления предлагает только операцию и объект только для чтения.

Answer 4

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

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

Вы можете получить больше информации о шаблоне хранилища здесь и здесь

Answer 5

Я использовал другой подход к одной и той же проблеме: каждый модуль имеет свои собственные интерфейсы, правильно?В данном случае под интерфейсом подразумевается программный интерфейс, такой как интерфейс EJB (в java) или файл .h (в старом простом C) и т. Д. Но если у вас есть одна база данных (даже если каждый модульЕсли у вас есть группа таблиц, у вас может быть вся эта база данных), вы можете представить некоторую часть вашего интерфейса как представление в БД.В этом случае каждый модуль будет определять набор программных интерфейсов и набор «интерфейсов БД» только для целей запроса.Вы сможете читать данные для своего отчета, используя простой SQL и объединения, и получать доступ только к тому, что модуль хочет предоставить.