Większość (wszystkich?) Ram, na które patrzysz, rozwiązuje te same problemy, ale robią to w nieco inny sposób z nieco innymi celami.
Myślę, że można śmiało powiedzieć, że wszystkie te projekty rozwiązałyby problemy w tych kategoriach:
- Podaj rozsądny zestaw wartości domyślnych
- Zredukuj kod płyty kotłowej
- Zapewnij strukturę aplikacji na blokach konstrukcyjnych BackboneJS
- Wyodrębnij wzorce, których autorzy używają w swoich aplikacjach
Marionetka, którą buduję od grudnia 2011 roku, ma również na myśli kilka bardzo wyraźnych celów i ideałów:
- Architektura aplikacji złożonych
- Wpływ wzorca komunikatów korporacyjnych
- Opcje modularyzacji
- Zastosowanie przyrostowe (brak wymogu „wszystko albo nic”)
- Brak blokady serwera
- Ułatw sobie zmianę tych ustawień domyślnych
- Kod jako konfiguracja / konfiguracja ponad
Nie twierdzę, że żadne inne ramy nie mają tych samych celów. Myślę jednak, że wyjątkowość Marionetki wynika z połączenia tych celów.
Architektura aplikacji złożonych
Spędziłem ponad 5 lat pracując w grubych klientach, rozproszonych systemach oprogramowania przy użyciu WinForm i C #. Tworzyłem aplikacje na komputery stacjonarne, laptopy (smart-client), urządzenia mobilne i aplikacje internetowe, wszystkie współużytkują podstawowy zestaw funkcjonalny i wiele razy współpracują z tym samym zapleczem serwera. W tym czasie poznałem wartość modularyzacji i bardzo szybko przeszedłem ścieżkę projektowania aplikacji złożonych.
Podstawową ideą jest „skomponowanie” środowiska wykonawczego aplikacji i przetworzenie go z wielu mniejszych pojedynczych elementów, które niekoniecznie się znają. Rejestrują się w całym złożonym systemie aplikacji, a następnie komunikują się za pomocą różnych środków oddzielonych od siebie wiadomości i połączeń.
Pisałem o tym trochę na swoim blogu, przedstawiając Marionette jako architekturę aplikacji złożonej dla Backbone:
Kolejki / wzory wiadomości
W tej samej dużej skali systemy rozproszone korzystały również z kolejkowania wiadomości, wzorców integracji w przedsiębiorstwie (wzorców przesyłania komunikatów) i magistrali usług do obsługi komunikatów. To, bardziej niż cokolwiek innego, miało ogromny wpływ na moje podejście do oddzielnego tworzenia oprogramowania. Z tej perspektywy zacząłem widzieć jednoprocesowe aplikacje WinForm w pamięci i wkrótce mój wpływ na serwer i tworzenie aplikacji internetowych wpłynęły na to.
To bezpośrednio przełożyło się na moje spojrzenie na projekt aplikacji Backbone. Udostępniam agregator zdarzeń w Marionette, zarówno dla obiektu aplikacji wysokiego poziomu, jak i dla każdego modułu, który tworzysz w aplikacji.
Myślę o komunikatach, które mogę wysyłać między moimi modułami: komunikaty poleceń, komunikaty o zdarzeniach i inne. Myślę też o komunikacji po stronie serwera jako wiadomościach o tych samych wzorcach. Niektóre wzory już dotarły do Marionetki, ale niektóre jeszcze nie.
Modularyzacja
Modularyzacja kodu jest niezwykle ważna. Tworzenie małych, dobrze zamkniętych pakietów, które mają szczególny nacisk z dobrze zdefiniowanymi punktami wejścia i wyjścia, jest koniecznością dla każdego systemu o dowolnej wielkości i złożoności.
Marionetka zapewnia modularyzację bezpośrednio poprzez jej moduledefinicje. Ale zdaję sobie również sprawę, że niektórzy ludzie lubią RequireJS i chcą z tego skorzystać. Zapewniam więc zarówno kompilację standardową, jak i kompilację zgodną z RequireJS.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(Na razie brak dostępnego postu na blogu)
Zastosowanie przyrostowe
Jest to jedna z podstawowych filozofii, w których piekę każdą część marionetki, w której mogę: nie ma wymogu „wszystko albo nic” do używania marionetki.
Sam Szkielet ma bardzo inkrementalne i modułowe podejście do wszystkich swoich obiektów budulcowych. Możesz wybrać, które z nich chcesz użyć, kiedy. Mocno wierzę w tę zasadę i staram się, aby Marionetka działała w ten sam sposób.
W tym celu większość elementów, które wbudowałem w Marionetkę, zbudowano tak, aby działały samodzielnie, pracowały z podstawowymi częściami Kręgosłupa i współpracowały jeszcze lepiej.
Na przykład prawie każda aplikacja sieci szkieletowej musi dynamicznie pokazywać widok sieci szkieletowej w określonym miejscu na ekranie. Aplikacje muszą także obsługiwać zamykanie starych widoków i czyszczenie pamięci po zainstalowaniu nowego. To tutaj Regionprzychodzi grać Marionetka . Region obsługuje główny kod wyświetlania widoku, wywoływania renderowania i umieszczania wyniku w DOM. Następnie zamknie ten widok i wyczyści go dla Ciebie, pod warunkiem, że Twój widok ma metodę „Zamknij”.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
Ale nie musisz korzystać z widoków Marionetki, aby korzystać z regionu. Jedynym wymaganiem jest rozszerzenie z Backbone.View w pewnym momencie łańcucha prototypowego obiektu. Jeśli zdecydujesz się podać closemetodę, onShowmetodę lub inne, Region Marionetek zadzwoni po ciebie w odpowiednim czasie.
Brak blokady serwera
Tworzę aplikacje Backbone / Marionette na bazie wielu różnych technologii serwerowych:
- ASP.NET MVC
- Ruby on Rails
- Ruby / Sinatra
- NodeJS / ExpressJS
- PHP / Slim
- Jawa
- Erlang
- ... i więcej
JavaScript to JavaScript, jeśli chodzi o działanie w przeglądarce. JavaScript po stronie serwera jest również niesamowity, ale ma zerowy wpływ lub wpływ na to, jak piszę JavaScript w przeglądarce.
Ze względu na różnorodność projektów, które zbudowałem oraz technologii zaplecza, z których korzystają moi klienci, nie mogę i nie zablokuję Marionette w stosie technologii po jednym serwerze z jakiegokolwiek powodu. Nie dostarczę projektu płyty kotłowej. Nie dostarczę rubinowego klejnotu ani pakietu npm. Chcę, aby ludzie zrozumieli, że Marionette nie wymaga określonego serwera zaplecza. Jest oparty na przeglądarce JavaScript, a zaplecze nie ma znaczenia.
Oczywiście w pełni popieram inne osoby dostarczające pakiety dla ich języka i frameworka. Wymieniam te pakiety na Wiki i mam nadzieję, że ludzie będą nadal budować więcej pakietów, gdy tylko będą tego potrzebować. Ale to wsparcie społeczności, a nie bezpośrednie wsparcie Marionetki.
Łatwo zmień ustawienia domyślne
W moich staraniach o ograniczenie kodu podstawowego i zapewnienie rozsądnych wartości domyślnych (jest to pomysł, który „pożyczyłem” bezpośrednio od narzędzia LayoutManager Tima Branyena), zdaję sobie sprawę z potrzeby stosowania przez innych programistów nieco innych implementacji niż ja.
Zapewniam renderowanie w oparciu o <script>tagi wbudowane dla szablonów, domyślnie używając szablonów Underscore.js. Ale możesz to zastąpić, zmieniając Rendereri / lub TempalteCacheobiekty w Marionetce. Te dwa obiekty stanowią rdzeń możliwości renderowania, a istnieją strony wiki, które pokazują, jak to zmienić dla określonych silników szablonów i różnych sposobów ładowania szablonów.
Dzięki wersji 0.9 Marionetki jest jeszcze łatwiej. Na przykład, jeśli chcesz zastąpić użycie wbudowanych bloków skryptów szablonów wstępnie skompilowanymi szablonami, musisz zastąpić tylko jedną metodę w module renderującym:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
a teraz cała aplikacja będzie korzystać ze wstępnie skompilowanych szablonów, które dołączasz do templateatrybutu widoku .
Udostępniam nawet dodatek Marionette.Async z wersją v0.9, który pozwala na asynchroniczne wyświetlanie widoków. Nieustannie staram się jak najłatwiej zastąpić domyślne zachowania w Marionette.
Kod jako konfiguracja
Jestem fanem „konwencji nad konfiguracją” w niektórych kontekstach. Jest to potężny sposób na załatwienie sprawy, a Marionetka zapewnia trochę tego - choć nie za dużo, szczerze mówiąc. Wiele innych frameworków - zwłaszcza LayoutManager - zapewnia więcej konwencji w zakresie konfiguracji niż Marionette.
Odbywa się to celowo i celowo.
Zbudowałem wystarczającą liczbę wtyczek JavaScript, frameworków, dodatków i aplikacji, aby poznać ból związany z próbą uzyskania konwencji w sposób znaczący i szybki. Można to zrobić z szybkością, ale zwykle kosztem możliwości jej zmiany.
W tym celu podchodzę do Marionette metodą „kodowania jako konfiguracji”. Nie udostępniam wielu interfejsów API „konfiguracji”, w których można podać literał obiektu o wartościach statycznych, które zmieniają zakres zachowań. Zamiast tego dokumentuję metody, które posiada każdy obiekt - zarówno za pomocą opatrzonego adnotacjami kodu źródłowego, jak i faktycznej dokumentacji API - z zamiarem powiedzenia Ci, jak zmienić Marionette, aby działała tak, jak chcesz.
Zapewniając czysty i przejrzysty interfejs API dla obiektów marionetek, tworzę sytuację, w której zastąpienie zachowania określonego obiektu lub marionetki jako całości jest stosunkowo proste i bardzo elastyczne. Poświęcam „prostą” konfigurację API wymagającą elastyczności dostarczania własnego kodu, aby wszystko działało tak, jak chcesz.
W Marionette nie znajdziesz interfejsu API „konfiguruj” ani „opcji”. Ale znajdziesz wiele metod, z których każda służy bardzo konkretnemu celowi, z czystymi podpisami, które ułatwiają zmianę sposobu działania Marionetki.
