Javascript-форум (https://javascript.ru/forum/)
-   Общие вопросы Javascript (https://javascript.ru/forum/misc/)
-   -   MVC vs API. Ваше мнение. (https://javascript.ru/forum/misc/10776-mvc-vs-api-vashe-mnenie.html)

x-yuri 23.07.2010 01:20

Цитата:

Сообщение от B~Vladi
Для меня важна отказоустойчивость, расширяемость, легкость в поддержке.

Цитата:

Сообщение от B~Vladi
компоненты будут использоваться многократно, на любой странице любого сайта и изменения может вызвать любой из них (компонентов)

расширяемость обратно-пропорциональна легкости в поддержке. Возьмем автокомплит. Какие бывают автокомплиты? Получающие данные через ajax, или через массив; показывающие все варианты со скроллом или ограниченное количество без скролла; ищущие только по началу, ищущие во всем значении. Думаю, можно еще что-нибудь придумать, но остановимся. Какое должно быть расширяемое решение?
var AutoComplete = new Class({
    initialize: function( ArraySource|AjaxSource dataSource, CompleteList|BriefList list ){...}
    ...
});

var ArraySource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

var AjaxSource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

Итого, семь классов. Что мы получили? Правильно, Hello, world! in patterns. И оно так же не легко в поддержке, как и в использовании. Да можно сделать это не таким расширяемым и оно станет проще. Но это не MVC и я не вижу причин разбивать этот автокомплит на модель-вид-контроллер. А вы?

Цитата:

Сообщение от B~Vladi
Именно не "удобное API", а интерфейс взаимодействия. Что посоветуешь?

т.е. не библиотеку, а фреймворк. Посоветую не ограничивать пользователя (MVC/неMVC, события/несобытия). Просто предоставь пользователю удобные средства для реализации разных способов взаимодействия, реализации модулей

Цитата:

Сообщение от B~Vladi
Модули же эти должны реализовывать логику. Представление данных, отдаваемые ими, может быть совершенно разным (один модуль на 10 сайтах).
Сам модуль будет состоять из описания логики, представления и данных.

ты себе противоречишь, или шаблон будет преобразовываться в конкретную разметку на каждом конкретном сайте? А что с css/js. Ведь они с DOM работать будут, т.е. должны зависеть от этой конкретной разметки. Или тоже будут преобразовываться/работать через промежуточный слой?

кроме того, ты уверен, что у тебя MVC, а не HtmlCssJs? Ведь можно сказать, для того же select, что модель там - пункты списка и какой из них текущий, вид - html+css, контроллер - js

Цитата:

Сообщение от B~Vladi
Т.е. при нахождении этого элемента в состоянии (классе) show и клике по нему, будет изменятся цвет. Причем для этого нужно всего лишь описать это в состоянии (тег status) и всё.

звучит как маркетинговый ход:
- Посмотрите, как просто в нашей программе сделать вот ЭТО!
- Вау, прикольно, а как насчет вот такого?
- А... Э... Ну, я вам потом расскажу... если захотите :)
(ну это так, подумалось)

da_ff (и не только), не обязательно подробно рассказывать реализацию. Просто пример привести. Например, связанные списки. Они не могут просто реагировать на изменение любого другого списка, потому что я добавлю третий список и обновляющийся список будет реагировать на события от двух списков. Т.е. должен быть какой-то код, специфичный для формы, который связывает списки. Надо сделать так?
<pr:list id="list1"></pr:list>
<pr:list link-with="list1"></pr:list>

И чем это отличается от
var list1 = new List();
new List({'link-with': list1});

просто другая форма записи
Хотите Mediator? Пожалуйста, надо только дважды расширить list, придумать для них какое-то свое событие, один его будет отправлять, а второй слушать
<pr:list-1></pr:list>
<pr:list-linked-with-list-1></pr:list>

ваши варианты?

Panzermaus, интересно, т.е. у тебя полный MVC один большой MVC? Т.е. много моделей, много видов и один контроллер и нету соответствия между видами и моделями? Ну да, раз должно быть undo/redo, должен быть какой-то координатор. Да и взаимодействие там, наверное, сложное, так что наличие координатора вдвойне имеет смысл. Но я говорил про нечто не такое высокоуровневое. Т.е. у тебя виды как реализованы? Один класс? Или разбиты по принципы input/output, один класс изменяет DOM, второй реагирует на события? Или как удобно в каждом конкретном случае?
И еще, я правильно понял, что виды не принимают уведомления напрямую от модели и контроллер не уведомляет виды о каждом отдельном изменении, потому что некоторое действие вызывает цепь изменений, а контроллер дожидается пока это все завершится и сообщает видам, что изменилось пакетом, а не про каждое изменение по отдельности?

Panzermaus 27.07.2010 21:09

Отпуск. Продержался без компьютера целых четыре дня! :)

Цитата:

Сообщение от x-yuri
Т.е. много моделей, много видов и один контроллер

Да.

Цитата:

Сообщение от x-yuri
и нету соответствия между видами и моделями?

Нету: одно V одновременно отображает множество объектов M; один и тот же объект M отображается одновременно несколькими Vs.

Цитата:

Сообщение от x-yuri
Т.е. у тебя виды как реализованы? Один класс? Или разбиты по принципы input/output, один класс изменяет DOM, второй реагирует на события?

Каждый V - один класс-синглтон, который работает со своими элементами DOM и обрабатывает все события этих элементов. Деления input/output нет.

Цитата:

Сообщение от x-yuri
И еще, я правильно понял, что виды не принимают уведомления напрямую от модели и контроллер не уведомляет виды о каждом отдельном изменении, потому что некоторое действие вызывает цепь изменений, а контроллер дожидается пока это все завершится и сообщает видам, что изменилось пакетом, а не про каждое изменение по отдельности?

Все верно.

ИМХО, MVC не задумывался как эталон модульности и не является им (а в моем исполнении и подавно). MVC - это не ослабление связности, а ее сознательное перераспределение, если можно так выразится. Сознательно исключаются зависимости M от С и от Vs, а также Vs друг от друга, в то время как зависимости С от M, Vs от M, Vs от С остаются. Таким образом, только M можно считать модулем - ее можно перенести в другое приложение без переделок, и при этом она за собой не потянет других компонентов. C же тянет за собой M, а V - и M, и C (лично я ослаблять эти зависимости и не старался, поэтому компоненты общаются через интерфейсы, а не через события/подписку). Короче, MVC решает задачу модульности лишь отчасти.

Цитата:

Сообщение от x-yuri
Но это не MVC и я не вижу причин разбивать этот автокомплит на модель-вид-контроллер. А вы?

Подойдем к примеру чисто схоластически :)
Цитата:

Сообщение от x-yuri
Какие бывают автокомплиты? Получающие данные через ajax, или через масив [1]; показывающие все варианты со скроллом или ограниченное количество без скролла [2]; ищущие только по началу, ищущие во всем значении [3].

[1] и [3] - ответственность модели, а [2] - ответственность представления. Применение MVC (отделение M) оправдано, если M используется по-разному и/или в разных местах, то есть когда существуют другие V/C, кроме инпута с выпадающим списком. Например, когда юзер ограничен имеющимися в списке значениями, а набирает что-то левое, то ему предлагается тот же список, но уже в виде ссылок (возможно, вы имели в виду...). Или вместо списка - карта города с флажками, и по мере ввода названия фирмы/рубрики этих флажков становится меньше. Если никаких подобных V нет, то единственное оправдание для использования MVC - это то, что M уже отделена от V/C. Например, по привычке :)

Цитата:

Сообщение от x-yuri
Они не могут просто реагировать на изменение любого другого списка, потому что я добавлю третий список и обновляющийся список будет реагировать на события от двух списков. Т.е. должен быть какой-то код, специфичный для формы, который связывает списки.

Цитата:

Сообщение от x-yuri
ваши предложения?

Если бы модульность была требованием, то я бы сделал так: допустим, есть три списка - страны, города (связанный со странами) и пол (не связанный с предыдущими). Есть диспетчер модулей/событий. Каждый модуль-список является источником соответствующего события: CountryChange, CityChange, GenderChange. Второй список подписан на CountryChange, чтобы отфильтровывать свои строки. А на CityChange и GenderChange подписана, например, кнопка submit, чтобы делаться enabled. (Она же может быть подписана на BirthdayChange и CaptchaGuessed, причем последнее событие генерируется сервером.) Что дает такая схема? Например, можно продублировать список стран картой мира. И список стран, и карта генерируют одно и то же событие CountryChange. Тут, правда, есть нюанс: генератор некоторого события должен автоматически становится и подписчиком этого события, чтобы список и карта были синхронизированы. Кроме того, можно подменить каптчу-рисунок на арифметический пример, два инпута плюс список - на полноценный календарь, и даже убрать либо список стран, либо карту. Функционирование оставшихся модулей не изменится.

x-yuri 27.07.2010 23:09

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

Panzermaus 28.07.2010 16:55

x-yuri, с MVC пришли к консенсусу :) Даже по вопросу M/V/C vs. M/VC, что вдвойне приятно. Это на серверной стороне отдельные V/С уместны, так как там input и output естественным образом разделяются.

Цитата:

Сообщение от x-yuri
Кстати, твой глобальный контроллер... я бы его все-таки каким-нибудь координатором/диспетчером назвал

Согласен, надо назвать этот паттерн Model-View-Dispatcher aka MVD :)

Цитата:

Сообщение от x-yuri
ну это по сути мой второй вариант.

Разница есть. Это не list2 = new List({'linked-with': list1}), а скорее list2evt = new List({'filter-when': 'event1'}). Кто является источником event1, сколько тех источников (и есть ли они) для list2evt все равно.

Цитата:

Сообщение от x-yuri
А по поводу событий, это по определению более сложный вариант взаимодействия.

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

Цитата:

Сообщение от x-yuri
Когда мы видим вызов метода, мы знаем, что объект-назначение один, в случае события это уже не очевидно.

Снова-таки в зависимости от конкретной ситуации, это может быть и недостатком, и достоинством. Пример: получателями события CountryChanged могут быть не только cityList, но и imgFlag, yourRegionalDealerContacts, да и мало ли что еще.

Цитата:

Сообщение от x-yuri
Кроме того, в сложных случаях может выясниться, что некоторое событие возникает не очень во время и надо как-то переделать эту схему взаимодействия.

А вот это чегтовски серьезное возражение! Поскольку ни одного законченного event-driven фреймфорка я не написал, то со скользкими случаями мог попросту не сталкиваться. Правда есть подозрение, что в действительно сложном случае взаимодействие через интерфейсы тоже хлебнет горя :) Пример бы...

Цитата:

Сообщение от x-yuri
В результате мы повысили реюзабельность за счет более сложного взаимодействия и большего количества компонентов (список/зависимый список), либо просто усложнили взаимодействие

В случае двух списков так и выходит: было 2 компонента и 1 зависимость, стало 3 компонента (+диспетчер) и 2 зависимости. Но допустим, взаимодействующих компонентов 10. Между ними может быть от 9 до 90 зависимостей - это и есть "конкретная ситуация". И это еще не все: зависимости могут быть очень разнообразны, например, если компоненты A, B, C зависят от X, и X потребовалось заменить на Y с другим интерфейсом, то A, B, C нужно будет подвергнуть переделке неизвестно какой глубины - от названий методов до всей логики.

А при взаимодействии через события количество компонентов хотя и увеличивается до 11, но зависимостей будет строго 10, причем зависимости исключительно однообразны и просты (подразумевается, что интерфейс диспетчера стабилен.)

x-yuri 28.07.2010 19:14

да и по поводу событий тоже сходимся во мнениях. Я может разве что больше делал упор на недостатки событий. Потому что ТС их как-то слишком превозносит. Т.е. уведомления от компонентов это хорошо, тем более что речь идет о библиотечных компонентах. Но компоненты, рассчитанные реагировать на события... я такого еще не видел, или не припоминаю. Во-первых, это навязывает наличие Mediator'а. Но даже если он предоставляется фреймворком, думаю, такой подход не всегда подойдет, скорее для простых случаев. А так, да, события бывают уместны, а бывают не уместны...

Цитата:

Сообщение от Panzermaus
Кроме того, в сложных случаях может выясниться, что некоторое событие возникает не очень во время и надо как-то переделать эту схему взаимодействия.
А вот это чегтовски серьезное возражение!

помню когда-то пытался кастомизировать TextBox в Delphi, перехватывал события от клавиатуры, но так и не добился, чтобы оно работало как надо. Но может они либо на это не рассчитывали, либо неудачно как-то организовали все это дело. Там правда, наверняка, использовался стандартный элемент управления Windows, так что все еще сложнее. Но это так, вспомнилось, да и деталей уже не помню

Или есть допустим схема с какими-то компонентами и модель. Модель обновляется и сообщает об этом компонентам. И тут я понимаю, что для какого-то компонента, нужно предыдущее состояние знать, а модель-то уже изменилась. Ну я сначала сделал еще одно событие beforeUpdate. А потом просто решил запоминать в компонентах нужную информацию (типа локальная модель). Ну т.е. можно считать, что совместил модель и компоненты, соотношение один-к-одному, так что нормально. Правда я к тому же до этого считал, что модель в DOM хранить можно (типа по состоянию DOM все нормально выясняется). Зачем еще дублировать в javascript-объекте? Оказалось лучше дублировать. Так вот в результате я получил более простое и понятное решение, чем с "большим MVC" и большим количеством событий

B~Vladi 27.08.2010 12:05

Цитата:

Сообщение от Panzermaus
с MVC пришли к консенсусу

Цитата:

Сообщение от x-yuri
и по поводу событий тоже сходимся во мнениях

Вам нужно работать в одной команде.

Давайте ещё немного поговорим :)
Начну с описания того, что у нас есть, а потом уже решим что с этим делать. А есть у нас тупо:
1. HTML в связке с CSS.
2. JS-код. Все-таки мы пишем приложение.

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

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

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

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

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

Вот это я и хочу проверить. Как что-то будет готовое - отпишу.

x-yuri 28.08.2010 10:48

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

B~Vladi 28.08.2010 14:06

Цитата:

Сообщение от x-yuri
ты нечетко выражаешь свои мысли, поэтому я и говорю, что лучше обсуждать на конкртном примере

Что не понятно то?! Будет пример, погоди.

x-yuri 28.08.2010 18:11

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

Цитата:

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

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

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

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

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

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

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

B~Vladi 28.08.2010 19:24

Цитата:

Сообщение от x-yuri
что вопроса в по сути два: как связывать компоненты и to MVC или не to MVC

Ну в общем то да. Для решения их конечно же надо писать код, а не рассуждать постоянно.
Цитата:

Сообщение от x-yuri
только javascript-код

Ну да, вообще описание классов, внутреннего функционала. Без каких-то конкретных действий.
Цитата:

Сообщение от x-yuri
генерация событий моделью?

Воздействие на отображение и на другие модули. Как вариант - генерация событий.
Цитата:

Сообщение от x-yuri
если модули должны взаимодействовать, их нужно как-то связать. Как это будет реализовано - другой вопрос, но делать это в компоненте, естественно не стоит

Ну вот и я о том же.
Цитата:

Сообщение от x-yuri
один на все виды/модели?

Да. По-сути он и будет фреймворком.
Цитата:

Сообщение от x-yuri
я просто затрудняюсь сказать, что такое классическая MVC-архитектура

Я понимаю что это, но рассказать навряд ли получиться:)
Цитата:

Сообщение от x-yuri
почему синхронное?

Ой, я имел ввиду двухстороннее. Любой может генерировать события.
Цитата:

Сообщение от x-yuri
непонятно зачем Команда и у кого какая будет роль

Ну он хорошо подходит на это место. Контроллер будет командовать. Реализация не сложная. Конечно, я готов рассмотреть другие варианты.
Цитата:

Сообщение от x-yuri
не обязательно, виды могут подписываться на события от контроллера

т.е. ты предлагаешь пробрасывать события V <-> C <-> M ?!
Цитата:

Сообщение от x-yuri
о разметке забудем навсегда (как это?

Имеется ввиду, что фреймворк никак не будет изменять разметку (отображение), а будет только инициализировать/связывать модули.
Цитата:

Сообщение от x-yuri
не вижу, откуда высосана причинно-следственная связь

А так как фреймворк не работает с разметкой, эта задача перекладывается на модули.
Цитата:

Сообщение от x-yuri
в чем чистота заключается?

В том, что модуль реализует только бизнес-логику. Мало кода, все красиво и понятно оформлено (ну если руки не из жопы).
Цитата:

Сообщение от x-yuri
компоненты не так сильно связаны? Так же, только информация о связах по-разному хранится

Да, так же связаны.
Цитата:

Сообщение от x-yuri
в первом варианте модели сделаны правильно, а при написании компонентов правильно их сделать может не получиться?

:)
Нет, просто так показалось. Посмотрим что выйдет.


Часовой пояс GMT +3, время: 11:05.