[x-yuri]

читаю, вроде примерно понятно, но потом натыкаюсь на какую-то фразу и ломаю об нее голову... дай-ка попробую продемонстрировать

Так, есть куча функционала в ТЗ. Если я все это дело раскидаю на отдельные логические составляющие, мне будет проще ориентироваться по всему проекту, а значит и поддерживать его. Сначала я опишу каждую составляющую более абстрактно, без привязке к отображению (только javascript-код? Такое получиться только для невизуальных компонентов) или к чему либо ещё, на какой-нибудь тестовой страничке. В такой среде код сам будет писаться как самостоятельный модуль. Аха, мы получили первый модуль. Получили второй. Третий. Внутри у них четко определённый функционал, раскиданный по нужным полочкам. О внутреннем устройстве вскоре можно будет забыть, но сначала нужно определить способ воздействия на внешний мир (генерация событий моделью?). API может вытащить наружу? Нет, связывать модули мы не будем. (если модули должны взаимодействовать, их нужно как-то связать. Как это будет реализовано - другой вопрос, но делать это в компоненте, естественно не стоит) Может медиатор? Может. Наблюдатель? Тоже вариант не плохой.

А может нам объявить модули как модели, разметку как вид и реализовать для всего этого контроллер (один на все виды/модели?), превратив функционал всего проекта в одну классическую MVC-архитектуру? (я бы поспорил по поводу классичности, т.е. я просто затрудняюсь сказать, что такое классическая MVC-архитектура) Хм... Это бы решило проблему с взаимодействием модулей... (если проблема в менее связанных компонентах, она решается событиями) Но как? О, точно, у нас для этих целей уже давно придуман патерн Observer. Хорошо, он поможет нам реализовать синхронное (почему синхронное?) взаимодействие контроллер <-> модель. Так. А что там у нас с видами? Задача контроллера - обновлять виды при изменениях состояний моделей. Прикроем-ка мы разметку классом вида и упростим общение с контроллером посредством, например, патерна Команда (непонятно зачем Команда и у кого какая будет роль) или того же API. Хм. В таком случае контроллер должен знать от кого в какой вид что посылать и поэтому может разрастись (не обязательно, виды могут подписываться на события от контроллера) - моделей/видов-то много. Что-то больно тяжелый микс патернов получается, но вполне рабочий. Надо реализовать.

Что мы ещё можем придумать? А можем сделать все намного проще, как я уже намекал выше... Есть наша куча модулей... Реализуем общение между ними при помощи медиатора или наблюдателя, а о разметке забудем навсегда (как это?). Тогда (не вижу, откуда высосана причинно-следственная связь), для качественной разработки модулей необходимо разделять их внутреннее устройство на составляющие, например на M, V и C. Решение рабочее, будем реализовывать.

Что получили в итоге. Самое интересное для нас - это модули. Мозг и логика всего приложения. Каждый кусок этого мозга влияет на все приложение в целом, а значит должно эффективно решать свои задачи. В первой реализации мы получили чистый функционал в коде модулей, без примесей (в чем чистота заключается?). Во втором варианте же каждый сам за себя - плевать на все приложение в целом (компоненты не так сильно связаны? Так же, только информация о связах по-разному хранится). Но не будет ли чистота первого варианта испорчена реализациями остальных компонентов - C и V? (в первом варианте модели сделаны правильно, а при написании компонентов правильно их сделать может не получиться?)

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

и в целом вроде похоже, что первый вариант - то, о чем я говорил, а второй вариант - твой. Так вот я не о том говорил, если что

p.s. на всякий случай напомню, что вопроса в по сути два: как связывать компоненты и to MVC или не to MVC