Большинство (всех?) Платформ, на которые вы смотрите, решают одни и те же проблемы, но они делают это немного по-другому с немного другими целями.
Я думаю, что будет справедливо сказать, что все эти проекты решат проблемы в следующих категориях:
- Обеспечить разумный набор значений по умолчанию
- Уменьшить шаблон кода
- Обеспечить структуру приложения поверх строительных блоков BackboneJS
- Извлекать шаблоны, которые авторы используют в своих приложениях
Марионетка, которую я строю с декабря 2011 года, также имеет в виду несколько совершенно разных целей и идеалов:
- Архитектура составного приложения
- Влияние корпоративного обмена сообщениями
- Варианты модуляции
- Инкрементальное использование (без требования «все или ничего»)
- Нет блокировки сервера
- Сделать это легко изменить эти значения по умолчанию
- Код как конфигурация / сверх конфигурации
Я не говорю, что ни одна из других платформ не имеет таких же целей. Но я думаю, что уникальность марионеток заключается в сочетании этих целей.
Композитная прикладная архитектура
Я провел более 5 лет, работая в распределенных программных системах с толстыми клиентами, используя WinForms и C #. Я создавал приложения для настольных компьютеров, ноутбуков (смарт-клиентов), мобильных устройств и веб-приложений, все из которых имели общий функциональный набор и много раз работали с одним и тем же сервером. За это время я понял ценность модульности и очень быстро пошел по пути разработки составных приложений.
Основная идея состоит в том, чтобы «составить» среду выполнения вашего приложения и обработать множество мелких отдельных частей, которые не обязательно знают друг о друге. Они регистрируются в общей составной системе приложений, а затем общаются с помощью различных средств разъединенных сообщений и вызовов.
Я немного написал об этом в своем блоге, представляя Marionette в качестве архитектуры составного приложения для Backbone:
Очереди сообщений / Шаблоны
Такие же крупномасштабные распределенные системы также использовали преимущества очереди сообщений, корпоративных схем интеграции (шаблонов обмена сообщениями) и служебных шин для обработки сообщений. Это, больше всего на свете, оказало огромное влияние на мой подход к развязке разработки программного обеспечения. С этой точки зрения я начал видеть однопроцессные приложения WinForms в памяти, и вскоре моя серверная сторона и разработка веб-приложений повлияли на это.
Это напрямую переросло в то, как я смотрю на дизайн приложений Backbone. Я предоставляю агрегатор событий в Marionette как для объекта приложения высокого уровня, так и для каждого модуля, который вы создаете в приложении.
Я думаю о сообщениях, которые я могу отправлять между моими модулями: командные сообщения, сообщения о событиях и многое другое. Я также думаю о связи на стороне сервера как о сообщениях с теми же шаблонами. Некоторые из моделей уже пробились в Марионетку, но некоторые еще нет.
Модульность
Модуляризация кода чрезвычайно важна. Создание небольших, хорошо инкапсулированных пакетов, которые имеют особый фокус с четко определенными точками входа и выхода, является обязательным условием для любой системы любого значительного размера и сложности.
Марионетка обеспечивает модульность непосредственно через свои moduleопределения. Но я также признаю, что некоторые люди любят RequireJS и хотят использовать это. Поэтому я предоставляю как стандартную сборку, так и совместимую с RequireJS сборку.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(Пока нет сообщений в блоге)
Инкрементное использование
Это одна из основных философий, которые я вношу в каждую часть марионетки, которую я могу: нет требования «все или ничего» для использования марионетки.
Сама система Backbone использует очень инкрементный и модульный подход со всеми объектами строительных блоков. Вы можете выбирать, какие из них вы хотите использовать, когда. Я твердо верю в этот принцип и стараюсь, чтобы Марионетка работала так же.
С этой целью большинство частей, которые я встроил в Marionette, созданы для того, чтобы работать в одиночку, работать с основными компонентами Backbone и работать вместе еще лучше.
Например, почти каждое приложение Backbone должно динамически отображать представление Backbone в определенном месте на экране. Приложения также должны обрабатывать закрытие старых представлений и очистку памяти при установке новых. Это где Марионетт Regionвходит, чтобы играть. Регион обрабатывает стандартный код для создания представления, вызова для него рендера и помещения результата в DOM для вас. Затем закроете это представление и очистите его для вас, при условии, что ваше представление имеет метод close.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
Но вы не обязаны использовать взгляды Марионеток, чтобы использовать регион. Единственное требование заключается в том, что вы расширяетесь из Backbone.View в некоторый момент в цепочке прототипов объекта. Если вы решите предоставить closeметод, onShowметод или другой метод, регион Marionette будет вызывать его для вас в нужное время.
Нет блокировки сервера
Я создаю приложения Backbone / Marionette на основе самых разнообразных серверных технологий:
- ASP.NET MVC
- Рубин на рельсах
- Рубин / Синатра
- NodeJS / ExpressJS
- PHP / Slim
- Ява
- Erlang
- ... и больше
JavaScript это JavaScript, когда дело доходит до запуска в браузере. Серверный JavaScript тоже потрясающий, но он никак не влияет на то, как я пишу свой браузерный JavaScript.
Из-за разнообразия проектов, которые я создавал, и внутренних технологий, которые используют мои клиенты, я не могу и не буду привязывать Marionette к одному стеку технологий на стороне сервера по любой причине. Я не буду предоставлять шаблонный проект. Я не буду предоставлять рубиновый камень или пакет npm. Я хочу, чтобы люди поняли, что Marionette не требует определенного внутреннего сервера. Это JavaScript на основе браузера, и бэкэнд не имеет значения.
Конечно, я полностью поддерживаю других людей, предоставляющих пакеты для их языка и структуры. Я перечисляю эти пакеты в Wiki и надеюсь, что люди продолжат создавать больше пакетов, когда они видят необходимость. Но это поддержка сообщества, а не прямая поддержка со стороны Марионеток.
Легко изменить настройки по умолчанию
В моих усилиях по сокращению стандартного кода и предоставлению разумных значений по умолчанию (это идея, которую я непосредственно «позаимствовал» из LayoutManager Тима Браньена), я признаю необходимость для других разработчиков использовать немного отличающиеся реализации, чем я.
Я предоставляю рендеринг на основе встроенных <script>тегов для шаблонов, используя шаблон Underscore.js по умолчанию. Но вы можете заменить это, изменив объекты Rendererи / или TempalteCacheобъекты в Marionette. Эти два объекта обеспечивают ядро возможностей рендеринга, и есть вики-страницы, на которых показано, как это изменить для конкретных шаблонизаторов и различных способов загрузки шаблонов.
С v0.9 от Marionette это становится еще проще. Например, если вы хотите заменить использование встроенных блоков сценариев шаблонов предварительно скомпилированными шаблонами, вам нужно заменить только один метод в Renderer:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
и теперь все приложение будет использовать предварительно скомпилированные шаблоны, которые вы прикрепляете к templateатрибуту вашего представления .
Я даже предоставляю дополнение Marionette.Async с v0.9, которое позволяет поддерживать асинхронную визуализацию представлений. Я постоянно стремлюсь сделать так, чтобы как можно проще заменить поведение по умолчанию в Marionette.
Код как конфигурация
Я фанат "соглашения по конфигурации" в определенных контекстах. Это мощный способ добиться цели, и Marionette предлагает немного этого - хотя и не слишком много, если честно. Многие другие фреймворки, особенно LayoutManager, предоставляют больше возможностей для настройки, чем Marionette.
Это сделано с целью и намерением.
Я создал достаточно плагинов, фреймворков, надстроек и приложений для JavaScript, чтобы понять, насколько сложно пытаться заставить соглашения работать осмысленно и быстро. Это может быть сделано со скоростью, но обычно ценой возможности изменить это.
Для этого я использую подход «код как конфигурация» к марионеткам. Я не предоставляю много API "конфигурации", где вы можете предоставить литерал объекта со статическими значениями, которые изменяют диапазон поведения. Вместо этого я документирую методы, которыми обладает каждый объект - как с помощью аннотированного исходного кода, так и с помощью фактической документации API - с целью рассказать вам, как изменить Marionette для работы так, как вы хотите.
Предоставляя чистый и понятный API для объектов Marionette, я создаю ситуацию, в которой замена поведения определенного объекта или Marionette в целом относительно проста и очень гибка. Я жертвую «простым» API-интерфейсом настройки и требует гибкости предоставления собственного кода, чтобы все работало так, как вы хотите.
Вы не найдете API "configure" или "options" в Marionette. Но вы найдете большое количество методов, каждый из которых служит определенной цели, с чистыми подписями, которые позволяют легко изменить работу Marionette.
