Ответ 1

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

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

Теоретическая сторона вещей

• Плагины/Модули

Каждый плагин будет включать набор конкретных функций и должен работать независимо от других плагинов, которые включены в данный момент. Все плагины должны будут соблюдать общий набор правил и соглашений, чтобы быть распознанными вашим приложением. Это упростит дальнейшее обслуживание и расширение. Например, каждый плагин должен:

• Имеет свой собственный подкаталог в папке "Плагины/Модули", которая следует за предопределенной структурой (например, Backend/Portlets/InstallScripts и т.д.).

• Используйте отдельную тестовую среду хранения в своей базе данных, предназначенную только для этого плагина. Возьмите Kashflow - все таблицы, которые используются плагином, могут начинаться с префикса ksflw_.

• Принесите свои собственные частичные представления представления Frontend (вместе с базовой логикой контроллера и моделью), которые реализуют определенные наборы функциональных возможностей (например, отображать предварительно выбранные книги на оранжевой границе )

• Принесите свои собственные частичные представления (-ы) представления Backend (-ов) (вместе с базовым контроллером и моделью), которые обрабатываются на бэкэнд сайта (в случае Kashflow у вас есть визуализация портлета, которая может отображать кнопка для ручного выполнения синхронизации, позволяет запланировать ее и отображать дату и время последней выполненной синхронизации)

• Установщик script, который создает таблицы, вставляет элементы меню и инициализирует подписки на крючки (см. следующий маркер)

• Инициализировать подписки на крючки. Все подписанные функции Plugin вызываются всякий раз, когда зарегистрированное событие происходит где-то в системе.

2. Основные функциональные изменения

Для запуска плагинов вам понадобятся новые функции в вашем существующем приложении.

• Менеджер плагинов - графический интерфейс, который позволяет устанавливать, удалять, включать/отключать плагины и разрешать доступ к ним для ваших клиентов.

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

• Заполнитель для частичных представлений на страницах в тех местах, где вы хотите, чтобы ваши пользователи отображали пользовательский интерфейс плагина и информацию

• Крючки по всему приложению. Всякий раз, когда происходит "интересное" событие, система проверяет, подключены ли какие-либо плагины к этому событию и вызывает/уведомляет их, а затем отображает результат. Некоторые примеры событий, которые заслуживают "Крюки", могут быть:

  • Отказ от размещения - это приведет к тому, что все подписанные функции отображают частичный вид интерфейса /backend

  • Конкретные бизнес-события. Всякий раз, когда новая книга добавляется в каталог или продается

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

Я уверен, что вы подумаете о других релевантных событиях, поскольку вы знаете свое дело лучше всего.

Практическая сторона вещей (на основе второго обновления вопроса)

1. Использование HMVC для визуализации частичных представлений (виджетов) внутри существующих представлений

Как я уже говорил ранее, Kohana поддерживает HMVC или шаблон иерархического представления модели. Это означает, что у вас может быть иерархия таких контроллеров (уже описанная в следующем вопросе):

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

Вы можете внести небольшую модификацию в файл boostrap.ini, чтобы включить Маршруты, такие как widget_controller/controller_action/action_parameter (это подробно описано в учебнике, которое я даю ниже). Затем вы можете иметь следующий код внутри основного шаблона просмотра, где вы хотите отобразить свою оранжевую книжную коробку:

<div class="widget_sidebar">
     <?php echo Request::factory('widget_orangebook/display/3')->execute(); ?>
</div>

При выполнении это действует как "крючок" и вызывает метод action_display контроллера widget_orangebook с параметром 3 - например. вы хотите показать 3 книги.

Действие контроллера будет выглядеть примерно так:

public function action_display ($number_of_books){...}

В результате внутри <div> вы увидите содержимое шаблона, заданного контроллером widget_orangebook после выполнения действия.

В некотором смысле это дает иллюзию частичного рендеринга AJAX, но его выполнение выполняется на сервере без дополнительного вызова. Это довольно мощно, и я думаю, что это способ пойти на описанные вами случаи.

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

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

2. Модули Kohana

Kohana поддерживает модули, которые позволяют организовывать организованные вами плагины. По мере внедрения более сложных плагинов это станет важным. Вы можете увидеть подробнее о Kohana Modules здесь.

Ответ 2

Позвольте мне начать с самого начала.

То, что вы ищете, называется service layer, которое должно быть реализовано в вашем приложении. Что он делает, это

Определяет границу приложения со слоем служб, который устанавливает набор доступных операций и координирует ответ приложения в каждой операции.

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

Уровень обслуживания определяет границу приложения [Cockburn PloP] и его набор доступных операций с точки зрения сопряжения клиентских слоев. Он инкапсулирует бизнес-логику приложения, контроль транзакций и координирующие ответы в осуществление его операций.

Позвольте мне объяснить это простые термины, чтобы вы могли понять. То, что вам нужно сделать, это определить уровень обслуживания в вашем приложении. Поскольку вы собираетесь с MVC, это могут быть другие контроллеры, обрабатывающие все запросы, связанные с этой конкретной задачей. У вас могут быть отдельные контроллеры для каждой пары операций. В конце ваш двигатель будет этим набором контроллеров.

Если вы хотите перейти на следующий уровень, вы можете справиться со всей этой интеграцией через ESB (Enterprise Service Bus).

Корпоративная служебная шина (ESB) - это используемая модель архитектуры программного обеспечения для разработки и реализации связи между взаимодействующих программных приложений в сервис-ориентированной архитектуре (SOA). В качестве архитектурной модели программного обеспечения для распределенных вычислений является специальным вариантом более общей модели клиентского сервера и повышает гибкость и гибкость в отношении Приложения. Его основное использование - интеграция корпоративных приложений (EAI) гетерогенных и сложных ландшафтов.

Если вам нужна дополнительная информация, дайте мне знать.

Update

Есть хорошо документированные сообщения в блогах. См. Ссылки ниже.

• Насколько важно создавать уровень сервиса?
• Правила уровня обслуживания