Да не зависит это от задачи, потому что архитектура приложения не решает задач, это немного другое. Просто первый вариант легко реализуем и, как следствие, более понятен на первый взгляд.

Все же хотел бы увидеть другие варианты. Ну или хотя бы ссылки на наиболее популярные патерны (или реализации), использующие архитектуру MVC.

А это точно MVC называется? Вроде не похоже (хотя я только начал во всем этом разбираться). И еще по второму рисунку (тот который вроде как MVC), выглядит так, как будто модули и источники события это совсем разное. Вроде модули как раз и должны быть основными источниками?

MVC - идеология или архитектура.
Патерны - подход к реализации той или иной идеологии. Т.е. законченный логический вариант. То, что я описывал в первом посте - патерны. Второй вариант даже имеет своё название (как и другие), но я его не помню. Другие патерны, с которыми я знакомился, не соответствуют идеологии MVC. Поэтому второй вариант сейчас для меня наиболее симпатичен.

На самом деле вторая картинка иллюстрирует не MVC, а патерн.

Да, источник события вынесен отдельно, так как он может быть не только модулем. Если данные сообщают контроллеру о наступлении события, это не должно привязываться к конкретным модулям. Другими словами, цепочка: данные -> модуль -> контроллер не приемлема.

Вот мое представлении о структуре Web-приложения, соответствующее идеологии MVC:
http://javascript.ru/forum/attachmen...1&d=1279640337

Т.е. у нас складывается некая иерархия. В этом топике второй вариант - третий шаг.

[off] - не нашел такого тега
Как и любая другая библиотека, jq годится на любые вещи :) И еще, я протестую :) против формулировки "писать на jq". Пишем на JavaScript с использованием каких-то библиотек. Или без них.

На то она и библиотека. Пользоваться только тем, что нужно. Не понимаю, в чем ты видишь проблему.

ППКС.

А вот с этим - не согласен. Делая Views, не грешно использовать $().append(), $().attr() и т. д. для работы с DOM. Делая обмен с сервером - $.ajax(). А ведь обмен с сервером - это уже Controller. Так зачем мне писать диспетчеризацию событий (еще одну функцию Controller-а) с нуля, если jq и так уже подключен и там есть нужный функционал? Отлаженный и кроссбраузерный.

Это не архитектура, и не пародия, а только иллюстрация того, как можно использовать jq для передачи сообщений, если того требует архитектура.

All
Честно говоря, обcуждение MVC vs. jQuery кажется мне бессмысленным. Как, например, MVC vs. Math. У jQuery свое место - сбоку припеку. Я бы не стал ставить знак равенства между jQuery и тем кошмаром, который пишут непоймикто, используя jQuery.
[/off] и покончим с этим :)

B~Vladi
Пришлось отдуваться за Резига, так и не ответил по существу :) Всегда стремлюсь (но не всегда успешно :() ко второму варианту. Кроме перечисленных плюсов есть еще один: облегчается повторное использование модулей.

Почему HTML - это Model, а не View?

А не надо за него отдуваться. Он сделал отличную библиотеку, но, имхо, это только библиотека, а вовсе не фреймворк.

Опять-таки, имхо,
DOM — упорядоченные данные и методы для управления вообще-всем. Т.е., модель плюс данные, которыми она оперирует.

CSS — отображение. В идеале, в документе каждый элемент должен содержать лишь данные о том, чем семантически он является

Javascript — контроллер. Опять-таки, в идеале меняет семантическую роль элементов и их связи методами, предоставленными DOM.

В итоге выходит что-то около знакомого «серверностороннего» MVC, только полувывернутого наизнанку.

На сервере фронтенд — отображение, а данные, контроллер и модель — бекенд.
Данные ← Модель ← Контроллер → Отображение

На клиенте фронтенд — данные и отображение, бекенд — модель и контроллер.

                  ,----------------------------↓
Отображение → Браузер ← Данные ← Модель ← Контроллер
Отображение по-прежнему не связано напрямую с данными (для любителей $(…).animate() уже придуман css transition)

по поводу jQuery... он совместим с MVC, если использовать его как библиотеку для работы с DOM. А разница между библиотекой и фреймворком очень нечеткая, чтобы что-то определенное сказать. Т.е. на сайте сказано, что "jQuery is designed to change the way that you write JavaScript" (типа посмотрите исходники, скоро вы будете писать так :) ), так что в каком-то смысле фреймворк, но с другой стороны им можно пользоваться в дополнение к некоторой архитектуре. Кстати, насколько я помню с помощью jQuery можно генерировать события на javascript-объектах

и почему обязательно MVC? Такое впечатление, что MVC выбирается потому что круто. Зачем, например, отделять модель от вида/контроллера? Чтобы можно было их отобразить с помощью другого вида/контроллера, или чтобы вид/контроллер могли использовать данные из нескольких моделей. Зачем отделять вид от контроллера? Чтобы можно было подменить контроллер. Ты с таким сталкивался? Значит используй. Я, например, пока что нет. Кроме того, есть разные производные от MVC

а зачем нужны отложенные события?

http://www.aspiringcraftsman.com/200...-architecture/

а исходя из чего выбирается архитектура?

что касается взаимодействия между компонентами: если это какие-то общие/повторно-используемые - лучше события, если что-то присутствующееся лишь на одной странице - зачем события непонятно.

p.s.
"My experience with MVC is of three extremely vague categories, which are only recognized after the fact, where one looks at a well-modularized system and places the function of each category into one of these roles, where Model pertains to state management, View to interface, and Controller to program logic. Controller ends up being the most vague of all these categories, and a satisfactory explanation is never given - mostly because MVC was designed for a very specific requirement in a specific environment, and is something of a square peg when it comes to describing architectures such as web apps or even event-driven GUI toolkits. As a high-level definition of roles, MVC has its uses, but attempting to reify it simply leads to madness, or at least frustration. Good design practice can succeed perfectly well regardless of whether it's MVC in one of its million varying guises, and indeed whether or not the designer is aware of the MVC design philosophy at all."
http://www.c2.com/cgi/wiki?WhatsaControllerAnyway

UPD хотя по поводу взаимодействия... события хороши когда заранее неизвестно, кому их посылать или когда не хочется связывать компоненты (причем скорее повторно-используемые). В примере subzey можно на нужной странице создать экземпляр "псевдоселекта", которому передать обработчик события использования фенечки и в этом обработчике отправлять форму. Таким образом, сам компонент не привязан к отправке формы аяксом, всего лишь обработчик события на конкретной странице

Мне нравится такая идея, почему бы и нет? И я даже на в курсе что это круто:)

Оптимизация, например. Если визуально элемент скрыт, а обновление данных поступило в модуль, совсем не обязательно их применять. Возможно, они и не понадобятся пользователю, по крайней мере в момент обновления.
Для меня важна отказоустойчивость, расширяемость, легкость в поддержке.
Конечно, компоненты будут использоваться многократно, на любой странице любого сайта и изменения может вызвать любой из них (компонентов). Поэтому необходимо отделить их от данных и представления (html, css) как можно дальше.

Может на русском есть? А то я не осилю:(

О чем я и говорю. Поездка на такси Козлевича не подразумевает растрату казенных денег, использование jQuery не подразумевает продажу души диаволу :)

А, вон оно как. А у меня и модель, и контроллер, и представления - это все JavaScript. Представления и контроллер используют DOM, HTML, CSS, SVG/VML. А вот модель - чистые JavaScript-классы - обо всем этом не знает ничего, как и о представлениях. А о контроллере знает крайне мало: только то, что его нужно извещать, когда данные изменяются.

Вашей точки зрения не оспариваю! Просто изложил свою трактовку MVC.

Ага, а у меня одинаково и на сервере, и на клиенте - данные (модель) всегда в бэкенде.

Или просто привычка :) (Я вот в JavaScript пришел из программирования под венду.)

ИМХО, только первый вариант. Ведь отделение одностороннее: модель не зависит от контроллера/видов, а они зависят от модели по полной.

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