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