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)

B~Vladi 20.07.2010 12:44

MVC vs API. Ваше мнение.
 
Вложений: 2
Всем мир.

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

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

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

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

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

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

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

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

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

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

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

Skipp 20.07.2010 13:28

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

Panzermaus 20.07.2010 13:58

Цитата:

Сообщение от B~Vladi (Сообщение 64482)
Всем мир.

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

Цитата:

Сообщение от B~Vladi (Сообщение 64482)
Всеми любимый jQuery тому пример.

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

B~Vladi 20.07.2010 14:23

Цитата:

Сообщение от Skipp
а если более гибкое то 1

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

Цитата:

Сообщение от Panzermaus
ИМХО, нельзя сказать, что jQuery несовместим с MVC

Почему? В jQuery вообще нет никаких границ. К примеру тот же вызов:
$('input[name=data].active:checked')

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

Цитата:

Сообщение от Panzermaus
так как это всего лишь библиотека, а не фреймворк

В чем разница?
Цитата:

Сообщение от Panzermaus
Кстати, bind() и trigger() из jQuery вполне можно использовать для "событийного" подхода.

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

Skipp 20.07.2010 14:34

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

B~Vladi 20.07.2010 14:52

Цитата:

Сообщение от Skipp
В любом случаи что-то зависит от чего-то.

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

Skipp 20.07.2010 15:05

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

Skipp 20.07.2010 15:11

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

subzey 20.07.2010 15:14

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

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

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

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

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

Panzermaus 20.07.2010 15:24

Цитата:

Сообщение от B~Vladi (Сообщение 64503)
В чем разница?

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

Цитата:

Сообщение от B~Vladi (Сообщение 64503)
Ты, видимо, немного не допонял. События не являются стандартными для DOM.

Допонял. jQuery позволяет создавать custom events:
// module #1
$('body').bind('myevent', handler1);

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

// module #3
$('body').trigger('myevent'); // вызовутся handler1() и handler2()
Разве не это требовалось?

Gozar 20.07.2010 15:32

в моем понимании первый
путь:
>--------------|@#$%%^&&**)(*&&^%%$#@@!~
и второй путь:
>--------------------------------------------------------

схемы(любой символ какое-то кол-во времени)
символ | - означает начало внесения изменений в логику (описанную subzey) лишняя зависимость и понеслось

Gozar 20.07.2010 15:37

Panzermaus,
если пытаться написать на jq что-то более серьезное чем плагин в виде галереи получается страшное месиво. jq нормально годиться только на простые вещи.

B~Vladi 20.07.2010 15:46

Цитата:

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

Да, ты правильно меня понял.
Цитата:

Сообщение от Panzermaus
Из библиотеки можно использовать в приложении только ту часть, которая нужна, например одну функцию.

И что же ты можешь выдернуть из jQuery? Ты можешь только либо пользоваться, либо нет, той или иной функциональностью, но она всё равно там остается.
Цитата:

Сообщение от Panzermaus
Разве не это требовалось?

События должны поступать в контроллер, а не через DOM, jQuery и все остальное. Именно контроллер должен активировать тот или иной модуль, в зависимости от события. То что ты привел, как минимум, пародия на архитектуру приложения.
Цитата:

Сообщение от Skipp
Но они зависят от контролёра.

Если модулем никто не управляет - значит модуль не должен сам ничего делать. Контроллер лишь пробрасывает ему инструкции. Менять же его не придется, так как это всего лишь мост.

Skipp 20.07.2010 15:54

B~Vladi,
А почему не иметь возможность использовать такую конструкцию контролёр -> модуль -> модуль, дать возможность модулям самодополнять друг друга, такая структура сложнее другой но всё же.

B~Vladi 20.07.2010 16:12

Цитата:

Сообщение от Skipp
А почему не иметь возможность использовать такую конструкцию контролёр -> модуль -> модуль

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

Есть ещё одно удобство, которое я называю "отложенное событие".
1. Модуль получил инструкцию по событию.
2. По внутренней логике, он не может на него отреагировать, пока не наступит другое событие. Поэтому он все (но не дублирующие) события (имена) откладывает до наступления нужного (а не хранит полученные данные - вдруг не пригодятся?).
3. Когда необходимое событие наступило - реакцией будет проброс накопившихся событий в контроллер и последующее обновление (если таковое необходимо).

Логика обработки событий может быть разная, главное, что она не затрагивает лишнее.

Skipp 20.07.2010 16:17

B~Vladi,
А я бы всё равно выбрал бы первый вариант=)

B~Vladi 20.07.2010 16:19

Цитата:

Сообщение от Skipp
А я бы всё равно выбрал бы первый вариант=)

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

Skipp 20.07.2010 16:21

B~Vladi,
Надеюсь оно наступит не скоро=) Или когда наступит найду ещё более интересное решение)

B~Vladi 20.07.2010 16:24

Цитата:

Сообщение от Skipp
Или когда наступит найду ещё более интересное решение)

Хорошо. Объясни тогда, почему тебе такой вариант не удобен/понятен/логичен/...

Skipp 20.07.2010 16:34

B~Vladi,
Ну вообще оба варианта ничего, это зависит от задачи.

B~Vladi 20.07.2010 16:44

Цитата:

Сообщение от Skipp
Ну вообще оба варианта ничего, это зависит от задачи.

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

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

Riim 20.07.2010 17:09

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

B~Vladi 20.07.2010 17:27

Цитата:

Сообщение от Riim
А это точно MVC называется?

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

Цитата:

Сообщение от Riim
выглядит так как будто модули и источники события это совсем разное.

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

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

B~Vladi 20.07.2010 18:43

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

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

Panzermaus 21.07.2010 00:27

[off] - не нашел такого тега
Цитата:

Сообщение от Gozar (Сообщение 64524)
если пытаться написать на jq что-то более серьезное чем плагин в виде галереи получается страшное месиво. jq нормально годиться только на простые вещи.

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

Цитата:

Сообщение от B~Vladi (Сообщение 64528)
И что же ты можешь выдернуть из jQuery? Ты можешь только либо пользоваться, либо нет, той или иной функциональностью, но она всё равно там остается.

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

Цитата:

Сообщение от B~Vladi (Сообщение 64528)
Именно контроллер должен активировать тот или иной модуль, в зависимости от события.

Цитата:

Сообщение от B~Vladi (Сообщение 64528)
События должны поступать в контроллер

ППКС.

Цитата:

Сообщение от B~Vladi (Сообщение 64528)
а не через DOM, jQuery и все остальное.

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

Цитата:

Сообщение от B~Vladi (Сообщение 64528)
То что ты привел, как минимум, пародия на архитектуру приложения.

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

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

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

Цитата:

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

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

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

subzey 21.07.2010 01:36

Цитата:

Сообщение от Panzermaus
Пришлось отдуваться за Резига

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

Цитата:

Сообщение от Panzermaus
Почему HTML - это Model, а не View?

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

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

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

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

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

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

                  ,----------------------------↓
Отображение → Браузер ← Данные ← Модель ← Контроллер

Отображение по-прежнему не связано напрямую с данными (для любителей $(…).animate() уже придуман css transition)

x-yuri 21.07.2010 07:07

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

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

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

Цитата:

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

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

Цитата:

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

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

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

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 можно на нужной странице создать экземпляр "псевдоселекта", которому передать обработчик события использования фенечки и в этом обработчике отправлять форму. Таким образом, сам компонент не привязан к отправке формы аяксом, всего лишь обработчик события на конкретной странице

B~Vladi 21.07.2010 10:38

Цитата:

Сообщение от x-yuri
и почему обязательно MVC? Такое впечатление, что MVC выбирается потому что круто.

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

Цитата:

Сообщение от x-yuri
а зачем нужны отложенные события?

Оптимизация, например. Если визуально элемент скрыт, а обновление данных поступило в модуль, совсем не обязательно их применять. Возможно, они и не понадобятся пользователю, по крайней мере в момент обновления.
Цитата:

Сообщение от x-yuri
а исходя из чего выбирается архитектура?

Для меня важна отказоустойчивость, расширяемость, легкость в поддержке.
Цитата:

Сообщение от x-yuri
если это какие-то общие/повторно-используемые - лучше события

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

B~Vladi 21.07.2010 10:41

Цитата:

Сообщение от x-yuri
http://www.aspiringcraftsman.com/200...-architecture/

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

Panzermaus 21.07.2010 15:18

Цитата:

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

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

Цитата:

Сообщение от subzey (Сообщение 64594)
DOM — упорядоченные данные и методы для управления вообще-всем. Т.е., модель плюс данные, которыми она оперирует.
CSS — отображение.
Javascript — контроллер.

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

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

Цитата:

Сообщение от subzey (Сообщение 64594)
На сервере фронтенд — отображение, а данные, контроллер и модель — бекенд.
На клиенте фронтенд — данные и отображение, бекенд — модель и контроллер.

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

Цитата:

Сообщение от x-yuri
и почему обязательно MVC? Такое впечатление, что MVC выбирается потому что круто.

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

Цитата:

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

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

Цитата:

Сообщение от x-yuri
Зачем отделять вид от контроллера?

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

subzey 21.07.2010 15:49

Цитата:

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

Зато в моём видении брать посчитанные значения css для элемента не просто некрасиво, а неправильно. :)

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

x-yuri 22.07.2010 00:13

кстати, jQuery - не первый вариант, плагины не зависят друг от друга

Цитата:

Сообщение от x-yuri
и почему обязательно MVC?

Цитата:

Сообщение от B~Vladi
Мне нравится такая идея, почему бы и нет?

причин использовать MVC нету, хорошо

Цитата:

Сообщение от x-yuri
а зачем нужны отложенные события?

Цитата:

Сообщение от B~Vladi
Оптимизация, например. Если визуально элемент скрыт, а обновление данных поступило в модуль, совсем не обязательно их применять. Возможно, они и не понадобятся пользователю, по крайней мере в момент обновления.

это теоретически рассуждения или ты видишь какую-нибудь конкретную ситуацию?

Цитата:

Сообщение от x-yuri
если это какие-то общие/повторно-используемые - лучше события

Цитата:

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

я говорил о взаимодействии компонентов (компонент = M+V+C) между собой. И надо было зачеркнуть что ли эту фразу. Давайте говорить на каких-то конкретных примерах, а то все так абстрактно, что можно что угодно сказать. Например, "псевдоселект"... Он сам по себе ни с кем не связан. Но если на какой-то странице нам его надо связать, т.е. заставить конкретный экземпляр компонента делать что-то специфичное для данной страницы:
new Select({
    'change': function(){
        $('#my-form').submit();
    }
})


Цитата:

Сообщение от B~Vladi
Может на русском есть? А то я не осилю

поищи. Еще можно здесь почитать, тоже на англ. В конце концов есть google-переводчик. А вообще, английский - lingua franca как никак

Цитата:

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

и я о том же, просто привычка. А ведь MVC создавался в совсем другой среде и основная задача задача была отделить представление от данных, чтобы можно было иметь несколько представлений данных. А разделение на input/output непонятно зачем было сделано (может потому что я на Smalltalk не программировал, какие-то там особенности). Так почему мы не создаем две параллельных иерархии объектов (виды и контроллеры), как это было в Smalltalk? Где о событиях уведомляется самый верхний контроллер и передает это событие по дереву нужному элементу, над которым сейчас мышка, спрашивая у видов "Мышка над тобой?". Наверное, потому что эта часть уже реализована и реализована по-другому, надо просто повести обработчик события на нужный DOM-элемент. Но тем не менее мы продолжаем делить на модель, представление, контроллер. Несомненно, в каких-то случаях это удобно. Но не слишком ли часто он применяется? Тем более что с тех пор было много разных вариаций/трактовок/реализаций. Если контроллер будет практически пустой, а вид будет занимать несколько тысяч строк, мы так и будем считать, что такое разбиение правомерно? Или в этом случае все-таки подумаем, что разбивать на классы/распределять обязанности можно по-разному?

Цитата:

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

Цитата:

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

не зависит, ну и что? Но вид/контроллер может отображать какую-нибудь сводную таблицу на основе нескольких источников

Цитата:

Сообщение от Panzermaus
Зачем отделять вид от контроллера?

Цитата:

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

во-первых, у меня по-разному выходит. Может у тебя привычка сказывается? ;)
во-вторых, активная модель (в изначальной реализации MVC была и пассивная) как раз и должна уведомлять тех, кто на это подписался, об изменениях. Если же модель изменяется только одним контроллером, она может быть пассивной (контроллер сам знает, когда изменилась модель и сообщает об этом виду). И активная модель как раз таки не знает, сколько у нее представлений, как и пассивная впрочем.
Зачем может понадобиться так разделение? Например readonly-контроллер, но это какая-то такая экзотика, имхо

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

и еще, ведь редко нужно иметь несколько видов для одних и тех же данных? Мне пока в голову пришли только разные варианты отображения файлов в Проводнике. Так вот когда это надо, можно делить, я считаю. Т.е. причина для именно такого деления есть (M/VC)

Цитата:

Сообщение от subzey
Зато в моём видении брать посчитанные значения css для элемента не просто некрасиво, а неправильно.

а можешь подробнее?

da_ff 22.07.2010 09:41

Несколько приложений работают на своем объекте диспетчеризации. в общих чертах для этого требуется чтобы каждый модуль мог делегировать через сторонний диспетчер хотябы два метода bind и unbind. По опыту могу сказать то, что использует механизм диспетчеризации поддерживается удобнее. Так же большим плюсом становится возмонжость разделить модули по файлам, которые работают только со своими данными не обращаясь к сторонним объектам определенным в других модуля.

x-yuri 22.07.2010 10:00

da_ff, можешь подробнее рассказать? Модули могут подписываться на события от конкретного источника или любого? Можешь какой-нибудь конкретный пример взаимодействия модулей привести? Ты используешь MVC?

B~Vladi 22.07.2010 10:21

Цитата:

Сообщение от x-yuri
причин использовать MVC нету, хорошо

Сейчас это единственный вариант, подходящий по требованиям, который я вижу.
Цитата:

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

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

Сообщение от x-yuri
или ты видишь какую-нибудь конкретную ситуацию?

Классическая ситуация - таб. Если он не активен, его содержимое незачем обновлять. Да мало ли на странице может быть скрытых блоков.
Цитата:

Сообщение от x-yuri
А вообще, английский - lingua franca как никак

Да, я в курсе:)
Цитата:

Сообщение от x-yuri
и давайте если продолжать, то как-то конретнее, на каких-то примерах...

Ок, нада что-нить - набросать.

da_ff 22.07.2010 11:06

Цитата:

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

Ох если выдирать куски из листингов толку будет мало. попробую написать крохотную демку.
Еще кстати для котроллера необходимо предусмотреть механизм передачи данных из объекта которые создает некое событие в его подписчиков.
Вообще мое имхо, что такая событийная модель более естественна для js. Поскольку большАя часть тех операций для которых он используется имеют ассинхронную природу.

x-yuri 22.07.2010 15:14

Цитата:

Сообщение от B~Vladi
Сейчас это единственный вариант, подходящий по требованиям, который я вижу.

озвучь требования что ли

Цитата:

Сообщение от B~Vladi
API вынуждает писать логику, которая зависит от плагинов.

jQuery вынуждает писать логику, которая зависит от плагинов. Но это не проблема. Проблема в том, что jQuery не предоставляет возможности создавать компоненты. Если же ты про взаимодействие через API, то взаимодействующие компоненты не обязательно будут зависеть друг от друга, можно просто создать какой-нибудь координирующий уровень, который не будет работать через события (Service Locator). Например, в случае с псевдоселектом, он мог спросить у этого координатора форму и отправить ее
services().get('form')->submit();

причем так даже лучше в данном случае, чем отправлять событие, потому что события это уведомления и они хороши, когда имеется сложная логика взаимодействия, когда заранее неизвестно, кого уведомлять. Но в общем-то так слишком сложно, потому что это код, специфичный для формы. Это что-то типа "не допущу, чтобы форма зависела сама от себя". Можно просто в обработчике события отправить форму, как я писал выше

Цитата:

Сообщение от B~Vladi
Классическая ситуация - таб. Если он не активен, его содержимое незачем обновлять. Да мало ли на странице может быть скрытых блоков.

обновлять? Возникает подозрение, что ты хочешь сделать что-то extjs-подобное или приложение типа gmail, т.е. которое обновляется. Озвучь свои цели

по поводу MVC, я вижу причину отделять модель от вида/контроллера, если нету четкого соответствия одна модель - один вид/контроллер. А вид с контроллером обычно слишком тесно связаны. Еще бывает смысл вынести код, который напрямую работает с DOM в отдельный класс, чтобы, если надо будет менять внешний вид, оно по-крайней мере не было перемешано с логикой работы. И в этом случае один класс (основной) - модель+контроллер, второй (работа с DOM) - контроллер+вид. По поводу первого из этих двух случаев есть смысл общаться через события, а именно уведомлять об изменениях модели

если взять WPF, например, там стандартные компоненты изначально никак не связываны. Стандартный способ их связать - в коде окна, т.е. в коде окна ты ловишь события от компонентов и изменяешь/управляешь другими компонентами. Т.е. что-то типа
new Select({ 
    'change': function(){ 
        $('#my-form').submit(); 
    } 
})

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

а то, что ты хочешь сделать, называется Mediator. Но для каждого паттерна есть, условия, при которых его имеет смысл применять. Он может использоваться в одной части приложения и не использоваться - в другой

Цитата:

Сообщение от da_ff
Вообще мое имхо, что такая событийная модель более естественна для js. Поскольку большАя часть тех операций для которых он используется имеют ассинхронную природу.

я не говорю, что события - плохо. Я говорю, что кроме событий есть несобытия ;) И кстати, про асинхронность (обновление) B~Vladi только сейчас упомянул, по крайней мере явно. При обновлении информации на странице, конечно, без событий не обойдешься. А что будет происходить при получении ответа от сервера... случаи разные бывают :)

B~Vladi 22.07.2010 15:48

Цитата:

Сообщение от x-yuri
озвучь требования что ли

Уже:
Цитата:

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

Цитата:

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

Цитата:

Сообщение от x-yuri
Озвучь свои цели

В двух словах - пытаюсь реализовать клиентскую платформу, под которую затем будут писаться модули (плагины, виджеты - называйте как хотите). Именно не "удобное API", а интерфейс взаимодействия. Что посоветуешь?:)
Модули же эти должны реализовывать логику. Представление данных, отдаваемые ими, может быть совершенно разным (один модуль на 10 сайтах).
Сам модуль будет состоять из описания логики, представления и данных.

Т.е. получается и внутренне разделение (внутри модуля) и внешнее (то, что будет отражено в результате). Сложно так абстрактно говорить.

B~Vladi 22.07.2010 15:58

Пример структуры модуля:
<module prefix="pr" ns="urn:myModule">
  <template name="tpl">
    <!-- HTML -->
  </template>
  <status>
    tag {
      color:inherit;
    }
    tag.show:click {
      color:#f00;
    }
  </status>
  <code>/* JavaScript */</code>
</module>

Т.е. xml.

Здесь модуль имеет шаблоны данных. Сами данные он берёт из xHTML кода, например:
<pr:tag>data</pr:tag>


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

Panzermaus 22.07.2010 17:07

Цитата:

Сообщение от subzey
данные (модель) всегда в бэкенде

Цитата:

Сообщение от subzey
Зато в моём видении брать посчитанные значения css для элемента не просто некрасиво, а неправильно.

Не понял :( Сейчас расшифрую, что я имел в виду, а потом расшифруйте вы :)

Цитата:

Сообщение от x-yuri
не зависит, ну и что? Но вид/контроллер может отображать какую-нибудь сводную таблицу на основе нескольких источников

Да, ты прав, это тоже причина отделять модель от остального. Со словом "сводную" стало понятно. А то я подумал, что один и тот же вид/контроллер отображают, например, сперва товар, а в следующий момент юзера :)

Цитата:

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

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

Начну :) Мой текущий проект (моя часть проекта) это что-то навроде автокада :) (Увы, не могу показывать недоделанный, не решаю таких вопросов :( Так что могу только рассказывать словами.) Короче редактор. Объектная модель типичного документа - связанные древовидно и как попало 100-300 объектов 15-ти разновидностей. У документа несколько представлений:
  • интерактивный 2D чертеж;
  • интерактивный псевдо-3D чертеж;
  • труЪ 3D представление (пока еще конь не валялся :));
  • небольшой read-only эскиз вроде Navigator-а в фотошопе;
  • окно свойств выделенного объекта как боковая панель в 3dsmax;
  • текстовое таблично-древовидное представление.
Пользователь может их скрывать/показывать как ему заблагорассудится.

Делаю в духе MVC. Так как между объектами M (их свойствами) и элементами HTM/SVG/VML DOM (их атрибутами) нет прямого соответствия, то M - это просто набор JS-объектов, никакой связи с DOM не имеющих. M извещает C об изменениях. C знает, какие Vs видимы (управляет этим), и извещает их. C мог бы извещать Vs и без напоминаний от M, так как он знает, когда M изменилась. Однако из за низкой производительности полные перерисовки Vs недопустимы, и нужно точно знать список изменившихся объектов, и поэтому требуется извещение от M. В этом смысле M активна, но она пассивна в том смысле, что Vs сами берут из нее укзанные данные (тоже из-за производительности). Vs привязывают к событиям DOM (click, change) обработчики, которые преобразуют их в события приложения ("команды": Select, PropertyChange), попадающие в C. C, если того требует команда, вызывает методы M. Не все команды исполняются на клиенте, некоторые требуют запросов к серверу. Всем обменом ведает C, кроме этого он поддерживает undo/redo-стэк, и еще кое какой сервис для Vs вроде панелей инструментов и справки.

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

Такой вот пример. Короче, приложение смахивает не десктопное и делается как десктопное. Не увидел специфических для веба приемов и явлений (разве что низкая производительность), которые бы заставили отказаться от MVC или существенно его видоизменить. Но может, уважаемый All что-то посоветует?


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