Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #21 (permalink)  
Старый 20.07.2010, 17:44
Аватар для B~Vladi
Модератор Всея Форума
Отправить личное сообщение для B~Vladi Посмотреть профиль Найти все сообщения от B~Vladi
 
Регистрация: 14.05.2009
Сообщений: 4,021

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

Все же хотел бы увидеть другие варианты. Ну или хотя бы ссылки на наиболее популярные патерны (или реализации), использующие архитектуру MVC.
Ответить с цитированием
  #22 (permalink)  
Старый 20.07.2010, 18:09
Аватар для Riim
Рассеянный профессор
Отправить личное сообщение для Riim Посмотреть профиль Найти все сообщения от Riim
 
Регистрация: 06.04.2009
Сообщений: 2,379

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

Последний раз редактировалось Riim, 20.07.2010 в 18:12.
Ответить с цитированием
  #23 (permalink)  
Старый 20.07.2010, 18:27
Аватар для B~Vladi
Модератор Всея Форума
Отправить личное сообщение для B~Vladi Посмотреть профиль Найти все сообщения от B~Vladi
 
Регистрация: 14.05.2009
Сообщений: 4,021

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

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

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

Последний раз редактировалось B~Vladi, 20.07.2010 в 18:31.
Ответить с цитированием
  #24 (permalink)  
Старый 20.07.2010, 19:43
Аватар для B~Vladi
Модератор Всея Форума
Отправить личное сообщение для B~Vladi Посмотреть профиль Найти все сообщения от B~Vladi
 
Регистрация: 14.05.2009
Сообщений: 4,021

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

Т.е. у нас складывается некая иерархия. В этом топике второй вариант - третий шаг.
Изображения:
Тип файла: jpg 1.jpg (9.4 Кб, 33 просмотров)

Последний раз редактировалось B~Vladi, 20.07.2010 в 20:30.
Ответить с цитированием
  #25 (permalink)  
Старый 21.07.2010, 01:27
Аспирант
Отправить личное сообщение для Panzermaus Посмотреть профиль Найти все сообщения от Panzermaus
 
Регистрация: 14.07.2010
Сообщений: 43

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

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

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

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

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

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

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

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

Т.е. у нас складывается некая иерархия. В этом топике второй вариант - третий шаг.
Почему HTML - это Model, а не View?
Ответить с цитированием
  #26 (permalink)  
Старый 21.07.2010, 02:36
Аватар для subzey
Пионэр
Отправить личное сообщение для subzey Посмотреть профиль Найти все сообщения от subzey
 
Регистрация: 16.11.2009
Сообщений: 1,322

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

Сообщение от Panzermaus
Почему HTML - это Model, а не View?
Опять-таки, имхо,
DOM — упорядоченные данные и методы для управления вообще-всем. Т.е., модель плюс данные, которыми она оперирует.

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

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

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

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

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

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

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

Последний раз редактировалось subzey, 21.07.2010 в 02:43. Причина: разночтение списка
Ответить с цитированием
  #27 (permalink)  
Старый 21.07.2010, 08:07
Аватар для x-yuri
Отправить личное сообщение для x-yuri Посмотреть профиль Найти все сообщения от x-yuri
 
Регистрация: 27.12.2008
Сообщений: 4,201

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

Последний раз редактировалось x-yuri, 21.07.2010 в 09:23.
Ответить с цитированием
  #28 (permalink)  
Старый 21.07.2010, 11:38
Аватар для B~Vladi
Модератор Всея Форума
Отправить личное сообщение для B~Vladi Посмотреть профиль Найти все сообщения от B~Vladi
 
Регистрация: 14.05.2009
Сообщений: 4,021

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

Сообщение от x-yuri
а зачем нужны отложенные события?
Оптимизация, например. Если визуально элемент скрыт, а обновление данных поступило в модуль, совсем не обязательно их применять. Возможно, они и не понадобятся пользователю, по крайней мере в момент обновления.
Сообщение от x-yuri
а исходя из чего выбирается архитектура?
Для меня важна отказоустойчивость, расширяемость, легкость в поддержке.
Сообщение от x-yuri
если это какие-то общие/повторно-используемые - лучше события
Конечно, компоненты будут использоваться многократно, на любой странице любого сайта и изменения может вызвать любой из них (компонентов). Поэтому необходимо отделить их от данных и представления (html, css) как можно дальше.
Ответить с цитированием
  #29 (permalink)  
Старый 21.07.2010, 11:41
Аватар для B~Vladi
Модератор Всея Форума
Отправить личное сообщение для B~Vladi Посмотреть профиль Найти все сообщения от B~Vladi
 
Регистрация: 14.05.2009
Сообщений: 4,021

Сообщение от x-yuri
http://www.aspiringcraftsman.com/200...-architecture/
Может на русском есть? А то я не осилю
Ответить с цитированием
  #30 (permalink)  
Старый 21.07.2010, 16:18
Аспирант
Отправить личное сообщение для Panzermaus Посмотреть профиль Найти все сообщения от Panzermaus
 
Регистрация: 14.07.2010
Сообщений: 43

Сообщение от subzey Посмотреть сообщение
А не надо за него отдуваться. Он сделал отличную библиотеку, но, имхо, это только библиотека, а вовсе не фреймворк.
О чем я и говорю. Поездка на такси Козлевича не подразумевает растрату казенных денег, использование jQuery не подразумевает продажу души диаволу

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

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

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

Сообщение от x-yuri
и почему обязательно MVC? Такое впечатление, что MVC выбирается потому что круто.
Или просто привычка (Я вот в JavaScript пришел из программирования под венду.)

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

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



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Google Chart API mycoding Оффтопик 0 14.07.2010 11:22