Architektura wtyczek w aplikacjach internetowych (przykłady czy fragmenty kodu?)

Nie mamy architektury wtyczek jako takiej, ale wyjaśnię, w jaki sposób utrzymujemy nasz kod klienta luźno powiązany, i może to da ci kilka pomysłów.

Używamy asp.net dostarczamy główne.strona aspx, która najpierw zawiera plik javascript mediatora. Definiuje globalny obiekt-nazwijmy go mediatorem-który jest jedynym globalnym obiektem, który definiujemy.

Mediator udostępnia prosty interfejs z publikacją i subskrybowaniem wiadomości:

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

Można zastosować podobne podejście-zdefiniować pojedynczy globalny obiekt (powiedzmy pluginFramework), który oferuje interfejs dla wtyczek do rejestrowania ich funkcjonalności. Podczas budowania strony html, aby dostarczyć do klient, najpierw Dołącz plik pluginFramework, a następnie dynamicznie Dołącz żądane pliki wtyczek JavaScript, które mogą zależeć od użytkownika lub urządzenia(np. różne wtyczki, jeśli urządzenie jest włączone touch?). Te pliki wtyczki dodają swoją funkcjonalność do pluginFramework z natychmiastową funkcją.

Oto przykład jak zezwolić wtyczkom na dodawanie funkcjonalności do menu w UI:

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)
})());

Mam nadzieję, że to było w jakiś sposób pomocne!

Twój komentarz sugeruje, że to, co budujesz, jest architekturą multi-tenant .

Jest to złożony wymóg-i taki, który zwykle jest dość trudny do dopasowania; w dużej mierze zależy od tego, od czego zaczynasz.

Po pierwsze, musisz mieć przyzwoicie przemyślaną aplikację internetową; jeśli używasz frameworka MVC, masz punkt wyjścia.

Po drugie, musisz zdecydować, gdzie zamierzasz obsługiwać rozszerzenia; dla instace, można Klient ma całkowicie oddzielną skórkę dla swojego interfejsu? Jeśli tak, potrzebujesz ramy skórowania. Klienci mogą zmienić wszystko lub po prostu podłączyć różne komponenty w kluczowych punktach (np. Niestandardowy dostawca płatności lub niestandardowy schemat uwierzytelniania). O wiele łatwiej jest obsługiwać ograniczony zestaw punktów rozszerzeń niż projektować framework, który pozwala na rozszerzenie czegokolwiek.

Następnie Twoja strategia danych; jest dobry artykuł na temat multi tenancy na MSDN ; jest nastawiony na relacyjne bazy danych, ale dostarcza pomysłów, które można zastosować do Mongo.

Wreszcie, musisz wymyślić architekturę komponentów, która obsługuje punkty rozszerzeń, których potrzebujesz. Ponieważ masz do czynienia z aplikacją internetową, musisz być w stanie modyfikować Model, widok, kontroler i persistance; najlepszym rozwiązaniem jest użycie sposobu, w jaki Framework MVC chce działać, i umieścić logikę "dla dzierżawcy x, do y; dla dzierżawcy z, do w" w warstwie kontrolera. Baw się tym, spraw, aby działało w niektórych przypadkach, których potrzebujesz, a potem zastanów się, co w tym złego i napraw to.

Jeśli sam robisz personalizację klienta, Django brzmi idealnie do tego. Stwórz swoją podstawową aplikację, która obsługuje wszystkie podstawowe funkcje, które chcesz. Następnie dla każdej logicznie oddzielonej rzeczy, którą musisz zrobić/wtyczka, Utwórz nową aplikację, którą możesz podłączyć do głównej, po prostu dodając tę aplikację do zainstalowanych aplikacji w Ustawieniach.

To obsługuje skórowanie (po prostu plop w nowym miejscu base_site.szablon html, niech wszystkie pozostałe odziedziczą po nim), obsługa wielu baz danych, wtyczek, i daje możliwość dość szybko rozwijać i wdrażać nowe wtyczki / funkcje.

Zobacz merengue lub pinax aby uzyskać bardziej ogólne przykłady tego, czym może być twój wewnętrzny system.