MVC vs API. Ваше мнение.
 

Всем мир.

В приложении есть набор модулей/плагинов/виджетов. Необходимо реализовать взаимодействие между ними.

Давайте с вами разберём два основных подхода клиентского программирования:

Первый вариант для многих знаком и привычен. Суть его в том, что каждый модуль имеет внешнее API, посредством которого можно управлять им (модулем) из стороннего модуля. Схематично это выглядит примерно так:
http://javascript.ru/forum/attachmen...1&d=1279616659

Обращение одного модуля к другому указано стрелками между ними. Так же может быть (может и не быть) контроллер этих плагинов со своим API. Контроллер может иметь функционал добавления/удаления модулей, получение API определённого модуля, если ссылка была потеряна и так далее.

Что я думаю о таком варианте:
+ API позволяет напрямую изменять другие модули. На первый взгляд все логично и удобно.

- Модули зависят друг от друга. Логика обращений из одного модуля к другому зашита внутри кода первого и наоборот. При смене API одного, менять нужно все, которые его (API) используют.
- Изменение ответов сервера влечет изменение клиентской части.
- Не соответствует архитектуре MVC. Если один модуль отвечает за бизнес логику и в нем происходят какие-либо изменения, их должен отобразить другой модуль. В этом случае граница между ними становится размытой.

Такой подход я наблюдаю повсюду. Всеми любимый jQuery тому пример.

Второй вариант использует событийную архитектуру. Суть его в том, что каждый модуль реагирует на определённые события, присылаемые контроллером, которые в свою очередь генерирует источник события. Схематично это выглядит так:
http://javascript.ru/forum/attachmen...1&d=1279618583

Источник события может быть данными, а может быть и самим модулем. Чтобы это работало, при инициализации каждый модуль регистрируется контроллером и передаёт ему список событий, на которые он может реагировать. Таким образом, любой источник события может повлечь за собой изменение сразу нескольких модулей, о которых он совершенно ничего не знает, поэтому ни от кого не зависит.

Что я думаю о таком варианте:
При таком подходе все минусы первого варианта становятся плюсами и наоборот.

Для меня выбор очевиден, но хотел бы спросить вас:
в каком варианте вам было бы удобнее поддерживать/развивать чужое приложение? К примеру, если вы работаете в команде, какой подход бы вы выбрали? Или может у кого есть другие варианты? Спасибо.

B~Vladi,
Мне кажется это зависит от поставленной задачи и в каком виде это будет применяться.
Я бы выбирал так:
Если нужно более безопасное приложение то 2, а если более гибкое то 1.

Алейкум ассалам.

ИМХО, нельзя сказать, что jQuery несовместим с MVC, так как это всего лишь библиотека, а не фреймворк. Каждый пишет как ему заблагорассудится. Кстати, bind() и trigger() из jQuery вполне можно использовать для "событийного" подхода.

В чем гибкость первого подхода? Наоборот - зависимость одного от другого сильно мешает при расширении/изменении приложения.

Почему? В jQuery вообще нет никаких границ. К примеру тот же вызов:

$('input[name=data].active:checked')

подразумевает, что приложение должно знать какие данные ему нужны, какое представление они сейчас имеют и какое логическое состояние оно должно иметь.
Любой плагин для jQ имеет API. Некоторые используют разметку (по классам и т.п.) вместо него, но суть от этого не меняется - плагин должен знать представление (класс), чтобы находить элементы.
Так что иди читай.

В чем разница?
Ты, видимо, немного не допонял. События не являются стандартными для DOM.

B~Vladi,
Ну так второй вариант вообще исключает взаимозависимость.
В любом случаи что-то зависит от чего-то.

Во втором случае модули никак не связаны друг с другом.

B~Vladi,
Но они зависят от контролёра. То есть при изменение контролёра, возможно потребуется изменение модулей.

B~Vladi,
В любом случаи независимого кода не существует.
Поэтому я считаю этого надо бояться в тех случаях когда безопасность на первом плане.

К сожалению, я вебдев и ни разу не GUI'овец, поэтому могу сказать только со своей колокольни.

Допустим, у нас есть два с виду независимых компонента: отправка формы аяксом и кастомные селекты с фенечками. Живут себе, мирно сосуществуют (каждый из них ненавязчив, ошибкоустойчив и выполняются в разных scope, ожидая событий через live).

И вдруг нужно, чтобы при использовании фенечки в «псевдоселекте», срабатывала бы отправка формы. И тут те же самые два пути: можно добавить в псевдоселект вызов что-то типа «ajaxFormSend()», либо генерировать событие «jsonSuggestApply».

В первом случае получаем лишнуюю зависимость (if (ajaxFormSend) ajaxFormSend() — так, цветочки), во втором, компонент сам отлавливает нужное событие (события) и реагирует на них.

Лично мне ближе второй вариант.

Из библиотеки можно использовать в приложении только ту часть, которая нужна, например одну функцию.
Фреймворк (бурж. "каркас") жестко диктует всю архитектуру приложения, во всю используя паттерны Шаблонный метод и Стратегия. То есть состоит из "заглушек", которые переопределяются приложением по мере надобности. Для примера: стандартные функции php - это библиотека. Zend Framework, CodeIgniter, CakePHP - фреймворки.

Допонял. jQuery позволяет создавать custom events:

// module #1
$('body').bind('myevent', handler1);

// module #2
$('body').bind('myevent', handler2);

// module #3
$('body').trigger('myevent'); // вызовутся handler1() и handler2()

Разве не это требовалось?