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 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
Зачем отделять вид от контроллера?

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


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