PDF-версия PPT Download Adder: http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture
Примечание. Во время процесса сбора я обнаружил, что мысли автора были повторены, поэтому он удалил некоторых из них. Если ваш английский хороший, пожалуйста, прочитайте английский PPT напрямую.
Ниже приведены основные главы этой статьи:
1. Что такое «Большая программа JavaScript»?
2. Рассмотрим текущую архитектуру программы
3. Долгосрочное рассмотрение
4. Мозговой штурм
5. Предлагаемая архитектура
5.1 Образец дизайна
5.1.1 Теория модулей
5.1.1.1 Обзор
5.1.1.2 Модульный режим
5.1.1.3 Объектный размер самообслуживания
5.1.1.4 Модуль CommonJS
5.1.2 Фасадный режим
5.1.3 Режим медиатора
5.2 Примените к вашей архитектуре
5.2.1 Facade - Основная абстракция
5.2.2 Mediator - ядро программы
5.2.3 Тесно работает
6. Публикайте Pub/Subs Extension: автоматические регистрационные события
7. Q & A
8. Благодарности
Что такое «Большая программа JavaScript»?
Прежде чем мы начнем, давайте определим, что такое большой сайт JavaScript. Многие опытные эксперты по развитию JS также были оспаривались. Некоторые люди говорят, что более 100 000 строк кода JavaScript считаются большими, и некоторые люди говорят, что код JavaScript должен быть размером более 1 МБ. На самом деле, ни один из них не является правильным, потому что количество кода не может быть измерено как количество установленных кодов. Много тривиального кода JS может легко превышать 100 000 строк.
Мое определение «Большого» заключается в следующем. Хотя это может быть неправильно, это должно быть относительно близко:
Я лично считаю, что крупные программы JavaScript должны быть очень важными, и включать в себя множество выдающихся разработчиков усилий по обработке тяжелых данных и отображения их в браузере.
Просмотрите текущую архитектуру программы
Я не могу подчеркнуть, насколько важна эта проблема. Многие опытные разработчики часто говорят: «Существующие творческие и дизайнерские модели очень хорошо работают в моем предыдущем проекте среднего размера, поэтому должно быть хорошо использовать их снова в немного большей программе, верно?», Это правда в определенных программах, но не забывайте, что, поскольку это большая программа, обычно должны быть большие проблемы, которые необходимо разбить и обратить внимание. Я кратко объясняю, как требуется время, чтобы просмотреть архитектуру программы, которая работала в течение длительного времени. В большинстве случаев текущая архитектура программы JavaScript должна выглядеть при этом (обратите внимание, что это архитектура JS, а не то, что все часто называет ASP.NET MVC):
пользовательские виджеты
модели
виды
Контроллеры
шаблоны
Библиотеки/инструментальные наборы
ядро приложения.
Вы также можете инкапсулировать программу в одни только несколько модулей или использовать другие шаблоны дизайна, что великолепно, но если эти структуры полностью представляют вашу архитектуру, могут возникнуть некоторые потенциальные проблемы. Давайте посмотрим на несколько важных моментов:
1. Сколько вещей в вашей архитектуре можно сразу же вывезти и повторно используют?
Есть ли отдельные модули, которые не зависят от другого кода? Это автономно? Если я перейду к базе кода, которую вы используете, а затем выберу несколько кодов модулей модуля и поместим их на новую страницу, можно ли использовать его немедленно? Вы можете сказать, что принцип в порядке. Я предлагаю вам планировать надолго. Если ваша компания разработала много важных программ раньше, вдруг однажды кто -то сказал, что модуль чата в этом проекте хорош, давайте вытащим его и поставим в другой проект. Можете ли вы просто использовать его без изменения кода?
2. Сколько модулей нужно полагаться на другие модули?
Все ли модули системы тесно связаны? Прежде чем я возьму этот вопрос в качестве беспокойства, я в первую очередь объясню. Дело не в том, что все модули не должны иметь никаких зависимостей. Например, мелкозернистая функция может быть расширена из базовой функции. Моя проблема отличается от этой ситуации. Я говорю о зависимостях перед разными функциональными модулями. Теоретически, все разные функциональные модули не должны иметь слишком много зависимостей.
3. Если что -то пойдет не так с одной частью вашей программы, будут ли другие части все еще работать?
Если вы создаете программу, аналогичную Gmail, вы можете обнаружить, что много модулей в Gmail загружаются динамически, например, модуль чата в чате, который не загружается при инициализации страницы, и даже если ошибка возникает после загрузки, другие части страницы могут использоваться нормально.
4. Можете ли вы проверить свои модули очень простым способом?
Каждый из ваших модулей может использоваться на больших сайтах с миллионами пользователей или даже несколько сайтов, поэтому ваши модули должны выдерживать тест, то есть, независимо от того, будь то внутри или за пределами архитектуры, они должны быть в состоянии протестировать очень просто, включая большинство утверждений, которые могут передаваться в разных средах.
Долгосрочное рассмотрение
При структурировании больших программ самое важное-быть вперед. Вы не можете рассмотреть ситуацию только один месяц или один год спустя. Вы должны рассмотреть возможность изменений в более длительный период времени? Разработчики часто связывают код операций DOM и слишком тесно программируют, хотя иногда они инкапсулируют отдельную логику в разные модули. Подумайте о том, почему это не очень хорошо в долгосрочной перспективе.
Моя коллега однажды сказал, что точная архитектура может не подходить для будущих сценариев, и иногда это правильно, но когда вам нужно это сделать, вы заплатите много денег. Например, вам может потребоваться заменить Dojo, Jquery, Zepto и Yui для определенных соображений производительности, безопасности и дизайна. В настоящее время есть проблема. У большинства модулей есть зависимости, которые требуют денег, времени и людей, верно?
Это нормально для некоторых небольших сайтов, но крупные сайты должны обеспечить более гибкий механизм, не беспокоясь о различных проблемах между различными модулями. Это экономит деньги и время.
Подводя итог, можете ли вы теперь быть уверенным, что вы можете заменить некоторые библиотеки классов, не переписывая всю программу? Если нет, то то, о чем мы собираемся поговорить ниже, более подходит для вас.
Многие опытные разработчики JavaScript дали несколько ключевых заметок:
Джастин Мейер, автор Javascriptmvc, сказал:
Самый большой секрет создания крупных программ - это то, что вы никогда не создаете большие программы, но разбиваете программы на небольшие модули, чтобы каждый небольшой модуль проверялся, значительно, а затем интегрировать их в программу.
Высокопроизводительный автор веб-сайтов JavaScript Nicholas, Zakas:
«Ключ состоит в том, чтобы с самого начала признать, что вы понятия не имеете, как это будет расти. -
Многие текстовые проблемы слишком неприятны. Подводя итог, все можно изменить, поэтому это должно быть абстрактным.
Автор основных основных принципов Ребекка Мерфи:
Чем ближе соединение между каждым модулем, тем менее повторно он используется, и тем больше сложности его изменения.
Вышеуказанные важные взгляды являются основными элементами построения архитектуры, и мы должны помнить их все время.
Мозговой штурм
Давайте мозговой штурм. Нам нужна свободно связанная архитектура, без зависимости между модулями, каждый модуль и программа общаются, а затем промежуточный слой вступает во владение и обрабатывает соответствующие сообщения.
Например, если у нас есть строительство JavaScript, программу онлайн -пекарни, модуль отправляет сообщение, которое может быть «42 раунда, которые необходимо доставить». Мы используем разные слои слоев для обработки сообщений, отправленных модулем, и делаем следующее:
Модули не получают напрямую доступа к ядро программы
Модули не вызывают напрямую и не влияют на другие модули
Это не позволит нам допускать ошибки во всех модулях из -за ошибок в определенном модуле.
Другая проблема - безопасность. Реальная ситуация заключается в том, что большинство людей не думают, что внутренняя безопасность является проблемой. В наших сердцах мы говорим, что программы созданы мной. Я знаю, какие из них являются государственными и частными. Нет проблем с безопасностью, но есть ли у вас способ определить, какой модуль доступа к ядру программы? Например, есть модуль чата в чате, который я не хочу, чтобы он вызвал модуль администратора, или я не хочу, чтобы он вызывал модуль с разрешениями на записи DB, потому что между ними есть хрупкость, и это легко вызвать атаки XSS. Каждый модуль не должен иметь возможность делать все, но код JavaScript в большинстве архитектур в настоящее время имеет эту проблему. Предоставьте промежуточный слой для управления тем, какой модуль может получить доступ к этой авторизованной части, то есть модуль может достичь только большей части части, которую мы разрешали.
Предлагаемая архитектура
Основное внимание в нашей статье уделяется тому, что на этот раз архитектура, которую мы предлагаем, использует шаблоны дизайна, которые мы все хорошо известны: модуль, фасад и посредник.
В отличие от традиционных моделей, чтобы отделить каждый модуль, мы позволяем модулю публиковать некоторые события событий. Режим медиатора может нести ответственность за подписку на сообщения сообщений из этих модулей, а затем контролировать ответ уведомления. Пользователи фасада ограничивают разрешения каждого модуля.
Ниже приведены части, на которые нам нужно обратить внимание:
1 шаблон дизайна
1.1 Теория модулей
1.1.1 Обзор
1.1.2 Модульный режим
1.1.3 Объект
1.1.4 Модуль CommonJS
1.2 Фасадный режим
1.3 режим медиатора
2 Примените к вашей архитектуре
2.1 Facade - Основная абстракция
2.2 Mediator - Программа Core
2.3 Работайте в тесном контакте вместе
Модальная теория
Каждый мог использовать модульный код более или менее. Модуль является частью полной и надежной архитектуры программы. Каждый модуль создан для отдельной цели. Возвращаясь к Gmail, давайте возьмем пример. Модуль чата, кажется, является отдельной частью, но на самом деле у него много отдельных подмодулей. Например, модуль выражения внутри на самом деле является отдельным подмодулем, который также используется в окне для отправки электронных писем.
Другое заключается в том, что модули могут быть загружены, удалены и заменены динамически.
В JavaScript у нас есть несколько способов реализации модулей. Все знакомы с модульными узорами и объектными литералами. Если вы уже знакомы с ними, пожалуйста, игнорируйте этот раздел и прыгайте непосредственно к части CommonJS.
Модульный режим
Модульный шаблон является относительно популярным шаблоном дизайна. Он может инкапсулировать частные переменные, методы и состояния через брекеты. Обертывая это содержимое, в целом глобальные объекты не могут быть доступны напрямую. В этом дизайне возвращается только один API, а все остальное содержимое инкапсулируется как частное.
Кроме того, этот шаблон аналогичен самостоятельному выражению функций. Единственное отличие состоит в том, что модуль возвращает объект, в то время как самообучение экспрессии функции возвращает функцию.
Как мы все знаем, JavaScript не хочет, чтобы у других языков были модификаторы доступа, и не может объявлять частные и публичные модификаторы для каждого поля или метода. Итак, как мы реализуем этот шаблон? То есть вернуть объект, включая некоторые публичные методы, которые имеют возможность вызывать внутренние объекты.
Посмотрите на код ниже. Этот код является самостоятельным кодом. Декларация включает в себя глобальный баттермодуль объекта. Массив корзины является частным, поэтому вся ваша программа не может получить доступ к этому частному массиву. В то же время мы возвращаем объект, который содержит 3 метода (например, Additem, GetItemCount, GetTotal). Эти 3 метода могут получить доступ к массиву частной корзины.
var basketmodule = (function () {var casket = []; // privateruturn {// inseed to public additem: function (values) {basket.push (values);}, getItemCount: function () {return Basket.length;}, getTotal: function () {var q = this.getemCount (), p = 0; } return p;}}} ());Также обратите внимание, что объект, который мы возвращаем, назначается непосредственно на корзину, поэтому мы можем использовать его как следующее:
// CAPTERMODULE - это объект со свойствами, который также может быть MethodBasketModule.additem ({item: 'хлеб', цена: 0,5}); casketmodule.additem ({item: 'масло', цена: 0,3}); console.log (basketmodule.getitemcount ()); console.log (basketmodule.gettotal ()); // однако, следующее не будет работать: console.log (basketmodule.basket); // (неопределенное, как не внутри возвращаемого объекта) console.log (корзина); // (существует только в рамках закрытия)Так как же это в различных популярных библиотеках классов (например, Dojo, jQuery)?
Додзё
Dojo пытается использовать Dojo.declare для обеспечения методов объявления в классе. Мы можем использовать его для реализации шаблона модуля. Например, если вы хотите объявить объект корзины в пространстве имен магазина, вы можете сделать это:
// Традиционный Wayvar Store = window.store || {}; Store.basket = store.basket || {}; // Использование dojo.setObjectDojo.setObject ("store.basket.object", (function () {var baske = []; function privatemethod () {console.log (basket);} return {publicmethod: function () {privatemethod ();}};} ()););Это очень мощно в сочетании с Dojo.provide.
Юи
Следующий код - это исходная реализация Yui:
Yahoo.store.basket = function () {// "private" переменные: var myprivatevar = "Можно получить доступ только в yahoo.store.basket."; // «Частный» метод: var myprivatemethod = function () {yahoo.log («« Можно получить доступ только из yahoo.store.basket »); } return {myPublicProperty: «Я публичная собственность», MyPublicMethod: function () {yahoo.log («Я публичный метод».); // Внутри корзины я могу получить доступ к «частным» вари и методам: yahoo.log (myprivatevar); Yahoo.log (myprivatemethod ()); // Приличный объем MyPublicMethod - это хранилище, поэтому мы можем // получить общественных членов, используя «это»: yahoo.log (this.mypublicproperty); }};} ();jQuery
В jQuery есть много реализаций модуля. Давайте посмотрим на другой пример. Функция библиотеки объявляет новую библиотеку. Затем при создании библиотеки метод инициации автоматически выполняется в Document.Ready.
Библиотека функций (module) {$ (function () {if (module.init) {module.init ();}}); return module;} var mylibrary = library (function () {return {init: function () { /*реализация* /}};} ());Объектный размер самооценка
Измерение самооценки объекта объявляется в скобках, а новое ключевое слово не требуется при его использовании. Если вы не заботитесь о общественных/частных полях атрибута в модуле, вы можете использовать этот метод, но обратите внимание, что этот метод отличается от JSON. Объект Self-Face Size: var item = {name: "tom", value: 123} json: var item = {"name": "tom", "value": 123}.
var mymodule = {myproperty: 'somevalue', // объектные литералы могут содержать свойства и методы. // Здесь другой объект определяется для конфигурации // Цели: myConfig: {useCaching: true, язык: 'en'}, // очень базовый метод myMethod: function () {console.log ('Я могу haz функции?'); }, // Вывод значения на основе текущей конфигурации myMethod2: function () {console.log ('Caching IS:' + (this.myconfig.usecaching)? 'enabled': 'отключен'); }, // переопределить текущую конфигурацию mymethod3: function (newConfig) {if (typeof newConfig == 'Object') {this.myconfig = newConfig; console.log (this.myconfig.language); }}}; mymodule.mymethod (); // я могу haz funcumentalitymymodule.mymethod2 (); // выводы enabledmymodule.mymethod3 ({language: 'fr', usecaching: false}); // фрCommonjs
Я не буду говорить о введении CommonJS здесь. Многие статьи представляли его раньше. Мы хотим упомянуть здесь, так это то, что в стандарте CommonJS есть два важных параметра и требуется. Экспорты представляют собой модуль, который должен быть загружен, и требует, чтобы эти загруженные модули должны полагаться на другие модули, а также должны быть загружены.
/*Пример достижения совместимости с AMD и стандартными CommonJs, разместив Cowerplate вокруг стандартного формата модуля CommonJS:*/(function (define) {define (function (revise, exports) {// Содержимое модуля var dep1 = require ("dep1"); exports.someexportedfunction = function ()}; define == "function"? Define: function (factory) {factory (require, exports)});Есть много реализаций загрузки стандартных модулей CommonJS. Я предпочитаю, чтобы это требовалось. Может ли он очень хорошо загружать модули и связанные с ними модули зависимостей? Давайте возьмем простой пример. Например, если вам нужно преобразовать изображение в код ASCII, мы сначала загружаем модуль Encoder, а затем получаем его метод incodetoAscii. Теоретически, код должен быть следующим:
var encodetoascii = require ("encoder"). encodetoAscii; exports.encodesomesource = function () {// после других операций, затем вызовите incodetoascii}Тем не менее, приведенный выше код не работает, потому что функция encodetoAscii не используется для прикрепления к окно, поэтому ее нельзя использовать. Это то, что должно сделать улучшение кода:
define (function (require, exports, module) {var encodetoAscii = require ("encoder"). encodetoAscii; exports.encodeSomesource = function () {// затем вызовы incodetoAscii}});CommonJS обладает большим потенциалом, но, поскольку дядя не очень знаком с ним, я не буду его осознавать.
Фасадный режим
Модель фасада занимает важную роль в архитектуре этой модели. Многие библиотеки класса JavaScript или фреймворки отражаются в этой модели. Самая большая функция состоит в том, чтобы включить API высокого уровня, чтобы скрыть конкретные реализации. Это означает, что мы только выставляем интерфейсы, и мы можем принимать решения внутренних реализаций сами, что также означает, что внутренний код реализации может быть легко изменен и обновлен. Например, сегодня вы используете jQuery для его реализации, а завтра вы хотите изменить YUI, что очень удобно.
В следующем примере мы видим, что мы предоставляем много частных методов, а затем раскрываем простой API, позволяющий внешнему миру выполнять и вызовать внутренние методы:
var module = (function () {var _private = {i: 5, get: function () {console.log ('текущее значение:' + this.i);}, set: function (val) {this.i = val;}, run: function () {console.log ('running');} jump: functade (); Функция (args) {_private.set (args.val);Разница между фасадом и о том, о чем мы говорим ниже, заключается в том, что Facade предоставляет только существующие функции, в то время как посредники могут добавлять новые функции.
Режим медиатора
Прежде чем говорить о модиаторе, давайте приведем пример. Система управления полетом в аэропорту, которая является легендарной башней, обладает абсолютной властью. Он может контролировать время взлета и посадки и места любого самолета. Самолет и самолеты не разрешают общаться раньше, что означает, что башня является ядром аэропорта, а посредник эквивалентен этой башне.
Mediator используется, чтобы иметь несколько модулей в программе, и вы не хотите, чтобы у каждого модуля имели зависимости, тогда режим медиатора может достичь цели централизованного управления. В реальных сценариях посредник инкапсулирует многие модули, которые они не хотят делать, позволяя им быть связаны через медиаторов, а также свободно связывали их, чтобы они должны общаться через посредников.
Так каковы преимущества режима посредника? Это развязка. Если у вас было хорошее понимание шаблона наблюдателя раньше, будет относительно просто понять диаграмму медиатора ниже. Следующий рисунок представляет собой диаграмму схемы медиатора высокого уровня:
Подумайте об этом, каждый модуль является издателем, а посредник - и издатель, и подписчик.
Модуль 1 транслирует реальную вещь для посредника, говоря, что что -то нужно сделать
После того, как посредник захватит сообщение, немедленно запустите модуль 2, который необходимо использовать для обработки сообщения. После завершения обработки модуля 2 верните информацию в посредника.
В то же время Mediator также запускает модуль 3 и автоматически входит в систему в модуль 3 при получении ответного сообщения модуля 2.
Видно, что между модулями нет связи. Кроме того, медиатор также может реализовать функцию мониторинга состояния каждого модуля. Например, если в модуле 3 есть ошибка, медиатор может временно хотеть только другие модули, а затем перезапустить модуль 3, а затем продолжать выполнять.
Оглядываясь назад, мы видим, что преимущество медиатора заключается в том, что свободно связанный модуль контролируется одним и тем же посредником. Модуль должен только транслировать и слушать события, и нет необходимости в прямом соединении между модулями. Кроме того, для обработки информации могут использоваться несколько модулей, что также облегчает нам добавлять новые модули в существующую логику управления в будущем.
Несомненно, что, поскольку все модули не могут общаться напрямую, может быть небольшое снижение производительности во всех относительно относительно, но я думаю, что это того стоит.
Давайте используем простую демонстрацию на основе приведенного выше объяснения:
var mediator = (function () {var inti -function = function (канал, fn) {if (! mediator.channels [Channel]) mediator.channels [Channel] = []; mediator.channels [Channel] .push ({контекст: this, wallback: fn}); return this;} publish = function (wanlish) vare. Array.prototype.slice.call (Arguments, 1); Подписаться: подписаться, installto: function (obj) {obj.subscribe = subscribe;Тогда есть 2 модуля под названием:
// pub/sub на централизованном посредничестве Mediator.name = "tim"; mediator.subscribe ('NameChange', function (arg) {console.log (this.name); this.name = arg; console.log (this.name);}); Mediator.publish ('NameCange', 'David'); // Тим, Дэвид // pub/sub через сторонний медиатор var obj = {name: 'sam'}; mediator.installto (obj); obj.subscribe ('nameChange', function (arg) {console.log (this.name); this.name = arg; console.log (this.name);}); obj.publish ('NameCange', 'John'); // Сэм, ДжонФасад приложения: абстракция ядра приложения
Фасад работает в качестве абстрактного ядра приложения и отвечает за связь между посредником и модулем. Каждый модуль может общаться только с ядром программы через этот фасад. Ответственность в качестве реферата состоит в том, чтобы в любое время было обеспечено обеспечение этих модулей с последовательным интерфейсом, что похоже на роль контроллера Sendbox. Все компоненты модуля общаются с посредниками через него, поэтому фасад должен быть надежным и заслуживающим доверия. В то же время, в качестве функции, обеспечивающего интерфейс для модуля, фасад должен играть другую роль, то есть контроль безопасности, то есть определить, к какой части программы можно получить модуль. Компоненты модуля могут вызывать только свои собственные методы и не могут получить доступ к какому -либо несанкционированному контенту. Например, модуль может транслировать DataValidationCompletedWriteToDB, где проверки безопасности должны убедиться, что у модуля есть разрешения на запись в базу данных.
Короче говоря, посредник может выполнять обработку информации только после обнаружения авторизации фасада.
Посредник применения: ядро приложения
Mediator работает в качестве основной роли для приложения, давайте кратко поговорим о своих обязанностях. Наиболее основной задачей является управление жизненным циклом модуля. Когда это ядро отражает любую информацию, ему необходимо судить, как программа обрабатывает ее - то есть решить, какой модуль начать или остановиться. Когда модуль запускается, он должен быть в состоянии выполнять автоматически, без ядра приложения, чтобы решить, следует ли его выполнить (например, следует ли его выполнять, когда DOM будет готов), поэтому сам модуль должен определить.
У вас может быть вопрос, при каких обстоятельствах остановится модуль? Когда программа обнаруживает, что модуль выходит из строя или допускает ошибку, программе необходимо принять решение о предотвращении продолжения метода в модуле, чтобы компонент можно было перезапустить с основной целью улучшения пользовательского опыта.
Кроме того, ядро должно иметь возможность динамически добавлять или удалять модули, не влияя на какие -либо другие функции. Распространенным примером является то, что модуль недоступен в начале загрузки страницы, но после работы пользователя он должен динамически загружать модуль, а затем выполнить его. Как и функция чата в Gmail, его следует легко понять с целью оптимизации производительности.
Обработка ошибок исключений также обрабатывается ядром приложения. Кроме того, когда каждый модуль транслирует информацию, он также транслирует любые ошибки в ядро, чтобы ядро программы мог остановить/перезапустить эти модули в соответствии с ситуацией. Это также очень важная часть свободно связанной архитектуры. Нам не нужно вручную менять какие -либо модули. Мы можем сделать это, используя публикацию/подписаться через посредника.
Собирать
Каждый модуль содержит различные функции в программе. Когда у них есть информация, которая будет обработана, они выдают информацию, уведомляющую программу (это их основная ответственность). В следующем разделе QA упоминается, что модули могут полагаться на некоторые методы работы инструмента DOM, но они не должны зависеть от других модулей системы. Модуль не должен обращать внимания на следующий контент:
1. Какой объект или модуль подписываются на информацию, опубликованную этим модулем
2. Это объекты клиентских или серверных объектов
3. Сколько объектов подписано на вашу информацию
Ядро приложения для абстракции фасада позволяет избежать прямой связи между модулями. Он подписывается на информацию из каждого модуля, а также отвечает за обнаружение авторизации, гарантируя, что каждый модуль имеет свое отдельное разрешение.
Mediator (Core Core) использует режим Mediator, чтобы играть роль менеджера публикации/подписки, отвечающего за управление модулями и выполнение модуля запуска/остановки, и может динамически загружать и перезагрузить модули с ошибками.
Результатом этой архитектуры является то, что между модулями не существует зависимости из -за свободно связанных приложений, их можно легко протестировать и поддерживать, каждый модуль может быть легко использован в других проектах или может быть добавлен динамически и удаляется, не влияя на программу.
Publish Pub/Sub расширение: автоматическая регистрация событий
Что касается автоматической регистрации событий, необходимо соблюдать определенные спецификации именования. Например, если модуль публикует событие с именем MessageUpdate, то все модули с методом MessageUpdate будут выполнены автоматически. Есть преимущества, преимущества и недостатки. Для конкретных методов реализации вы можете увидеть от меня еще один пост: магическая обновленная версия jQuery Custom Binding.
QA
1. Возможно ли не использовать фасад или аналогичный режим песочницы?
Хотя схема архитектуры предлагает, чтобы фасад мог реализовать функции проверки авторизации, на самом деле вполне возможно, что посредники могут это сделать. То, что должна сделать легкая архитектура, почти одинаково, то есть развязка и обеспечение того, чтобы каждый модуль был непосредственно связан с ядром приложения, в порядке.
2. Вы улучшили, что модуль не может быть напрямую зависимым. Означает ли это, что он не может полагаться на какую-либо стороннюю библиотеку (например, jQuery).
Это на самом деле двухсторонняя проблема. Как мы упоминали выше, у модуля могут быть некоторые подмодули или основные модули, такие как базовые классы инструментов операции DOM и т. Д. На этом уровне мы можем использовать стороннюю библиотеку, но, пожалуйста, убедитесь, что мы можем легко заменить их.
3. Мне нравится эта архитектура, и я хочу начать использовать эту архитектуру. Существуют ли какие -нибудь образцы кода, которые можно использовать для обозначения?
Я планирую сделать образец кода для вашей ссылки, но до этого вы можете обратиться к модульному JavaScript от Andrew Burgees.
4. Это возможно, если модуль должен напрямую общаться с ядром приложения?
Технически, нет никаких причин, по которым модули не могут напрямую общаться с ядром приложения сейчас, но для большинства приложений это все еще не разрешено. Поскольку вы выбрали эту архитектуру, вы должны соблюдать правила, определенные архитектурой.
Благодарности
Спасибо Николасу Закасу за оригинальный пост, чтобы подвести итоги идей вместе, Андри Ханссону за технический обзор, Ребекку Мерфи, Джастину Мейеру, Джону Ханну, Питеру Михокс, Полу Ирриш и Алексу Секстону, все они предоставили много информации, связанной с этой сессией.