[x-yuri]

Panzermaus, ну что ж, похоже мы во мнениях сходимся Добавлю только немного

ИМХО, MVC не задумывался как эталон модульности и не является им (а в моем исполнении и подавно).

не задумывался, и когда его так воспринимают, не могу сдержаться...

MVC - это не ослабление связности, а ее сознательное перераспределение, если можно так выразится.

я бы сказал, что если компонент становиться большим, его нужно рефакторить, у него слишком много обязанностей. Т.е. высокая связность со временем может уменьшаться. И это не обязательно разбиение на несколько классов, составляющих компонент. Можно как вариант вынести какую-нибудь библиотечную функциональность (например, управление курсором в input type="text"), или создать промежуточный компонент (расширенный input type="text"). И MVC это один из вариантов решения проблемы, причем вид и контроллер обычно cильно связаны, т.е. разделять имеет смысл как-то так M/VC, если у модели не один вид/контроллер или нету однозначного соответствия. V+C если и разбивать, то по каким-то другим критериям. Все это, естественно, в контексте разработки клиентской части веб-приложения. Кстати, твой глобальный контроллер... я бы его все-таки каким-нибудь координатором/диспетчером назвал

Таким образом, только M можно считать модулем - ее можно перенести в другое приложение без переделок, и при этом она за собой не потянет других компонентов

ну это пожалуй редкое обоснование

C же тянет за собой M, а V - и M, и C (лично я ослаблять эти зависимости и не старался, поэтому компоненты общаются через интерфейсы, а не через события/подписку).

потому что у тебя конкретные компоненты для конкретной страницы. Для более общих компонентов исходящие события бы как раз пригодились, только связывать их не обязатльно через какой-то третий класс (Mediator)

Если бы модульность была требованием, ...

ну это по сути мой второй вариант. А по поводу событий, это по определению более сложный вариант взаимодействия. Когда мы видим вызов метода, мы знаем, что объект-назначение один, в случае события это уже не очевидно. Кроме того, в сложных случаях может выясниться, что некоторое событие возникает не очень во время и надо как-то переделать эту схему взаимодействия. В результате мы повысили реюзабельность за счет более сложного взаимодействия и большего количества компонентов (список/зависимый список), либо просто усложнили взаимодействие

p.s. кстати, B~Vladi, советую исходить из практики, типа сделал ряд приложений по определенной схеме и получил фреймворк в качестве бонуса. Чтобы чувствовать эффект от принятых решений. Если это, конечно, не так