Архитектура плагина в веб-приложениях (примеры или фрагменты кода?)

Я пытаюсь научиться разрабатывать веб-приложение (желательно NodeJS/MongoDB, хотя раньше я использовал PHP и Python), который можно расширять и настраивать с помощью плагинов, чтобы включить отключенные функции.

Один из возможных вариантов заключается в использовании Wordpress с перехватами для подключаемых модулей и виджета, но при этом отсутствует надлежащее разделение представления и логического кода. Это остается одним из вариантов изучения. Есть ли другие варианты?

Есть ли у вас какие-либо фрагменты кода или пример приложения, из которого я могу учиться? Язык или рамки не так важны, я, вероятно, мог бы составить концепцию, стоящую за

Ответ 1

Хорошая архитектура плагинов трудно достичь с нуля, но предлагает свои собственные награды. Это делает программное обеспечение гибким и простым в обслуживании путем локализации сложности. Первым навыком, который он требует, является способность писать свободно связанный код. Это требует очень прочного понимания полиморфизма, Закона о Демерете и связанного с ним принципа Command Pattern: дает модули плагинов постоянную точку входа, позволяя им легко переключаться и выходить, a Веб-пример от IBM.

Memento: захват, удержание и экстренное состояние без нарушения инкапсуляции, позволяет плагинам настраиваться контейнером. Обратный звонок: позволяет модулям плагинов обращаться к "службам" из контейнера/среды. Injection of Dependency : способ ослабления связи модулей подключаемых модулей от их среды. Аннотация Factory Шаблон: установка и создание экземпляра плагина в среде. Builder Pattern: требуется для любой нетривиальной архитектуры плагинов, где модули плагина зависят друг от друга.

Как только вы их поймете, изучите некоторые из существующих реализаций и архитектур Plugin Framework, чтобы узнать, как они были использованы. Apache имеет несколько в Struts, сборные серверные сборки Geronimo и Tomcat JNDI Resources; Также плагин Eclipse framework.

Ответ 2

У нас нет плагиновой архитектуры как таковой, но я объясню, как мы поддерживаем наш клиентский код слабо связанными, и, возможно, это даст вам некоторые идеи.

Мы используем asp.net. Мы доставляем страницу main.aspx, которая сначала включает в себя файл javascript посредника. Он определяет глобальный объект - называет его посредником - который является единственным глобальным объектом, который мы определяем.

Медиатор предоставляет простой интерфейс с публикацией и подпиской на сообщения:

mediator.subscribe(messageName, callback);
mediator.publish(messageName);

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

Вы можете следовать аналогичному подходу - определить один глобальный объект (скажем, pluginFramework), который предлагает интерфейс для плагинов для регистрации их функциональности. Когда вы создаете страницу html для доставки клиенту, сначала включайте файл pluginFramework, а затем динамически включаете нужные файлы плагина JavaScript, которые могут зависеть от пользователя или устройства (например, различные плагины, если сенсор включен?). Эти файлы плагинов будут добавлять их функциональность в pluginFramework с немедленной функцией.

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

pluginFramework.js:

var pluginFramework = (function() {
    var menuItems = [];
    function addMenuItemPrivate(itemName, callback) {
        // e.g. add itemName and callback to menuItems
    }
    return {
        addMenuItem: addMenuItemPrivate;
    }
})());

photoPlugin.js:

(function() {
    function addPhoto() {
        //...
    }
    pluginFramework.addMenuItem('add photo', addPhoto)
})());

Надеюсь, это было в некотором роде полезно!

Ответ 3

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

Это сложное требование - и обычно довольно сложное для ретро-фит; это во многом зависит от того, откуда вы начинаете.

Во-первых, вам нужно иметь в своем распоряжении прилично-факторизованное веб-приложение; если вы используете структуру MVC, у вас есть отправная точка.

Во-вторых, вам нужно решить, где вы собираетесь поддерживать расширения; для instace, может ли клиент иметь отдельный отдельный скин для своего интерфейса? Если это так, вам нужна скин-рамка. Могут ли клиенты изменить все или просто подключить разные компоненты в ключевых точках (например, пользовательский поставщик платежей или специальная схема проверки подлинности). Гораздо проще поддерживать ограниченный набор точек расширения, чем создавать структуру, которая позволяет продлить что-либо.

Далее, ваша стратегия данных; там хорошая статья о многократной аренде на MSDN; он ориентирован на реляционные базы данных, но предоставляет идеи, которые вы можете применить к Mongo.

Наконец, вы должны придумать архитектуру компонента, которая поддерживает требуемые точки расширения. Поскольку вы имеете дело с веб-приложением, вы должны иметь возможность изменять Model, View, Controller и persistance; лучшее решение - использовать то, как хочет работать ваша MVC-инфраструктура, и поставить логику "для арендатора x, do y, для арендатора z, do w" на уровне контроллера. Играйте с этим, заставьте его работать в некоторых случаях, в которых вы нуждаетесь, а затем выясните, что с этим связано и исправьте.

Ответ 4

Если вы сами настраиваете клиент, Django идеально подходит для этого. Создайте основное приложение, которое будет обрабатывать все основные функции, которые вам бы хотелось. Затем для каждой логически разделенной вещи вам нужно сделать /plugin создать новое приложение, которое вы можете подключить к основному, просто добавив это приложение к установленным приложениям в настройках.

Это обрабатывает скининг (просто plop в новом шаблоне base_site.html, у вас есть все остальные), поддержка нескольких баз данных, плагины и дает вам возможность быстро разрабатывать и развертывать новые плагины/функции.

Смотрите merengue или pinax для более общие примеры того, чем может быть ваша внутренняя система.