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)

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, время: 12:17.