Роль ZODB в проектировании приложений с использованием bluebream. Мультисайтовая архитектура

В bluebream термином local site принято называть персистентный контейнер, содержащий в числе прочих локальный реестр компонент. Термин локальный применяется к персистентным объектам, реализующим интерфейс zope.location.interfaces.ILocation

Общепринятая структура

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

Говорится, что первичная роль ZODB в BlueBream - это не роль пользовательской базы данных, но роль хранилища для локальной компонентной архитектуры.

Роль контентной БД сугубо вторична и опциональна (хотя и удобна) - и это одна из причин, по которой многие вещи, по умолчанию, присутствовавшие в Zope3 Application Server сейчас убраны или оставлены только в качестве не-обязательных компонент.

Таким образом, имеем корневой и заказной локальные сайты. Виртуальный хост фронт-энд сервера настраивается на заказной локальный сайт, а поиск компонент осуществляется вверх по иерархии, сначала в реестре заказного, затем в реестре корневого. Последнее полезно, кроме всего прочего, при построении мултисайтовой архитектуры, когда добавляется не один, а множество заказных local site. Компоненты, не найденные в их реестрах, ищутся в корневом реестре, и, таким образом, являются общими для всех сайтов.

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

В 99% случаев приведенного шаблона достаточно для проектирования сколь угодно сложных систем.

Вторая схема

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

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

Как избежать overkill? Очень просто. Не нужно думать о такой архитектуре преждевременно. Когда такая надобность (а это 1%, грубо говоря) возникает, то в основном имеем дело с добавлением новых обработчиков событий (вместо изменения существующего кода) + миграция БД с помощью zope.app.generations

При построении специализированных enterprise приложений это могут быть вложенные контейнеры на основе zope.site.folder.Folder и являющиеся локальными сайтами изначально или только по надобности, т.е. с момента когда пользователь инициирует такое изменение, которое влечет за собой создание альтернативной, локальной, "персональной" компоненты в противовес более общей.

Предлагается: вложенную мультисайтовую архитектуру реализовывать в контексте проектирования по требованию.

Третий вариант

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

Четвертый вариант

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

Математически, реестры компонент лучше всего представлять как МИРЫ. В пределах этих (независимых) миров существует океан (также независимых) компонент, выстраивающихся в систему по требованию (запросу). При использовании предложенной архитектуры имеем дело с многократно вложенными и взаимно пересекающимися и даже переключаемыми по требованию мирами. В каждом из этих миров один и тот же объект имеет различные свойства, поведение и окружение.

Обсуждение - здесь