Создать & quot; Движок & quot; разрешить интеграцию в основное веб-приложение?

Фон:

В настоящее время у меня есть веб-приложение, основанное на PHP-фреймворке MVC Kohana, которое позволяет пользователям продавать электронные книги своим клиентам.

Весь код веб-приложения соединен воедино и все, кроме API-ориентированных.
Он запускает чистый MVC, а затем использует усы для системы шаблонов.

Что я хотел бы сделать:

Я хотел бы интегрировать различные бухгалтерские услуги (от более крупных нордических провайдеров, таких как e-conomic.com), а также собственные интеграции, которые позволят пользователям оптимизировать свои продажи и так далее.

То, что я хотел бы заархивировать, — это сделать что-то, назовите это движком, который позволяет функционально интегрировать (гибко) в части веб-приложения, будь то в части представления или в контроллере / логике.

Исходя из предыстории и с технической точки зрения, какие есть способы сделать это?

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

Будет ли это даже работать? Чтобы ты делал?


Обновление пытается сделать его более понятным:

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

Скажем так, у меня есть папка с именем интеграция /, и здесь есть две разные интеграции, которые влияют на разные части системы.

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

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

Как работает жирный шрифт? Поставщик интернет-магазина, такой как Shopify, имеет Приложения, которые делают это, и все другие SaaS с Приложениями имеют это техническое решение.

Интересно это? Как я могу позволить отдельным функциям влиять на базовое веб-приложение?

Надеюсь, теперь стало понятнее.


Новое обновление:

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

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

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

13

Решение

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

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


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

  1. Плагины / модули

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

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

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

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

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

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

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


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

Вам потребуется новая функциональность в существующем приложении, чтобы начать поддерживать плагины.

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

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

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

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

    • Визуализация заполнителя — это активирует все подписанные функции для отображения частичного представления внешнего интерфейса / внутреннего интерфейса.

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

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

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


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

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

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

MVC против 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, но он выполняется на сервере без дополнительного вызова. Это довольно мощно, и я думаю, что это путь для описанных вами случаев.

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

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

2. Модули Кохана

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

2

Другие решения

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

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

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

введите описание изображения здесь

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

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

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

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

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

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

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

4

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector