Модель - это нечто абстрактное, не имеющее само по себе никакого
внешнего вида (и соответственно может быть отражено по-разному).
Если Модель наследуется от DisplayObject - то это уже не совсем
правильная модель.
Например, здоровье и количество патронов у персонажа - это Модель. А
индикаторы на экране, которые отображают эти данные (в виде чисел, или
полосок жизней или ещё каким-то образом) - это Вид.
советую к прочтению книжку Гамма, Хелм - "Приемы
объектно-ориентированного проектирования: паттерны проектирования"
там отлично расписаны основные шаблоны проектирования
допустим у вас есть некая модель содержащая данные: A=10, B=20, C=500,
D=250 и т.д.
у этой модели есть интерфейсный метод: getData():Array и событие которое
всплывает при изменении модели - например Event.CHANGE
вы создавая отображение этой модели подписываетесь на указанное событие
когда оно всплывает получаете данные и отображаете их
преимущество такого метода в том что вы можете сделать сколько угодно
отображений: таблица, график, текст и т.д. и т.п. менять их
вы можете сколько угодно менять внутреннее устройство модели, главное
чтобы метод getData() возвращал то что от него ожидают
следовательно с таким подходом меньше шансов сломать систему и больше
возможностей к ее расширению
так же советую заглянуть в PureMVC фреймворк - одна из лучших реализаций
паттерна на данный момент
MVC
Модель это не просто что-то отдельное от вида.
В зависимости от задач вашего приложения это все-же должен быть набор
осмысленных классов.
так же советую заглянуть в PureMVC фреймворк
> МОДЕЛЬ должна быть набором классов? мне казалось что модель это
> ОДИНОЧА или нет?
Модель может повторять структуру View, точнее, View повторяет
структуру модели.
Т. е. модель вполне себе древовидна может быть.
>
> если просто создать свой класс реализующий МОДЕЛЬ от ЭвентДиспечера
> и не сделать его Document class возникает проблема передавать ссылку
> на этот объект всем ПРЕДСТАВЛЕНИЯМ.
> использовать глобал???
Собственно, в чем проблема вызвать сеттер модели у View?
Денис Коляко
______________________________________________________________________
e...@timezero.ru | http://etcs.ru/ | http://www.timezero.com/
--
ign
_____________________________________________________________________
http://www.isky.ru
А ссылка на root есть по умолчанию у всех. Что уже неправильно.
Так же
подразумевается, что состояние модели
может изменять только контроллер.
Модель ― содержит данные, грузит данные, конвертирует данные. Этакий черный ящик с интерфейсом.
и view о модели не знают ничего, где-то используются ссылки непосредственно на модель, хотя мне кажется это неправильно.
> Модель хранит данные только для вьюверов, никому больше эти данные не нужны.
А контроллерам?
Модель хранит данные только для вьюверов, никому больше эти данные не нужны.
> у нас же все DisplayObject связаны с root.
Связаны. И что? Не нужен представлениям рут, совершенно. Максимум,
что должно волновать View — так это то, что внутри этого View лежит.
и компактный flex framework в придачу
у нас же все DisplayObject связаны с root. или все представления связаны с моделью?
вообще говоря, это справедливо для дисплейобжектов в дисплей листе
> Контроллеру нужная прямая ссылка на модель, чтобы изменять ее состояние.
Так а чем ссылка для вьюверов отличается от ссылки для контроллеров?
Подразумевалось, что данные модели требуются только вьюверу.
А ссылка на саму модель естественно нужна и контроллеру и вьюверу.
Так а чем ссылка для вьюверов отличается от ссылки для контроллеров?
> Подразумевалось, что данные модели требуются только вьюверу.
Неужели? А смысл от контроллера, если он не пользуется данными из
модели?
Подразумевалось, что данные модели требуются только вьюверу.
> ничем. но вьюверам она прописывается моделью, а в контроллер попадает из вьювера.
Ну вообще говоря, отдельный вьювер к базе данных (модели) без контроллера
доступ не должен получать. Точнее, ссылка у него теоретически есть,
но он лишь посредник и хранилище ссылок (аргументов) до момента создания своего
собственного контроллера.
После того, как контроллер будет создан вьювером, контроллер по
полученным ссылкам сам раздаст подвьюверам ссылки на конкретные
элементы базы данных для их отображения. Сам же вьювер аргументы контроллера после
создания должен занулить, он вообще не знает, что в этих аргументах
лежит. Т. е. даже если там ссылка на базу данных, он о ней всё равно
не знает.
> Смысл контроллера в том, чтобы отслеживать взаимодействие с
> пользователем с помощью вьювера и оповещать модель об изменениях.
Контроллер модель не оповещает, он её изменяет. А для этого ему
могут потребоваться данные из модели и при определенных условиях он
не будет изменять модель.
Т. е. он не настолько примитивен, чтобы тупо полученные от View
данные засовывать сразу в модель.
Смысл контроллера в том, чтобы отслеживать взаимодействие спользователем с помощью вьювера и оповещать модель об изменениях.
> получил ответ, разобрал - положил в модель.
> крикнул: Эй представления!!! пользуйтесь!!!
Крикнул точно не контроллер.
Да и получать команды от сервака чаще всего не обязанность того
контроллера, который клик получил. Ну только если это не специфичная
для данного компонента команда.
>> запросить сервер и обработать результат?
> А не сама ли модель должна это сделать?
Модель не содержит логику.
> Модель диспатчит евент, что она изменилась, вьюверы их ловят и
> перерисовывают?
Да, этот процесс происходит без какого-либо дальнейшего вмешательства
со стороны контроллера.
Модель не содержит логику.
> содержит логику работы с данными
Ну это само собой, просто логику, необходимую для работы самой
модели и правильности хранения данных, я не считаю за логику :-D
вот допустим у нас модель карточной игры - объект приложения (Модель)
"колода" - где вы будете делать метод тасования?
допустим у нас модель поведения шарика который стремится упасть на
плоскость после того как его поднимают на некоторую высоту - где должны
высчитываться - скорость падения, положение в пространстве и момент
когда нужно остановиться, когда шарик достиг земли?
в принципе оба варианта имеют право на существование, и в зависимости от
ситуации оправдывается тот или иной способ.
з.ы. и по поводу аналогии - "ящик должен всего-лишь хранить данные" -
тоже не согласен. Смысл определения "черный ящик" говорит о том что у
нас есть интерфейс какой-нибудь системы, ну пусть это будет какой-нибудь
мп3-плейер. интерфейс нам позволяет тыкать на кнопочки Play, Stop, Next
и т.п. а как он работает внутри нам знать не обязательно
Модель это не просто данные - это система.
вид строится по модели,
MVC хороший паттерн, как и многие другие, но.
Не стоит стремиться всё загонять в шаблоны.
Их, конечно, надо знать и уметь применять.
Но просто программируй. Пиши так, как пишется.
Смотри, что получается. Избегай антипаттернов.
Не бойся рефакторить - хороший портной должен
очень любить пороть (не бдсм, хотя, может я
неправильно понимаю пословицу).
И, в итоге, сложится тот самый продукт,
который нужен.
Если твое письмо звучит именно в контексте
изучения MVC, то я для понимания вкратце
охарактеризовал бы его в первую очередь
как принцип разделения данных и представления
(M и V) и связку их контроллером (С).
если вы не можете найти решение, не можете спроектировать конкретную
задачу - спросите, на конкретном примере будет проще объяснить и понять
> в теории то все красиво и правильно, а вот одно только использование
> Proxy на мой взгляд замедлит простой проект в разы.
> опять таки примерно эта схема реализована (как я понял) во Flex. или нет?
если проект не претендует в дальнейшем развиваться то может и стоит
обойтись простой схемой - на деле же всегда охота добавить что-то еще и
добавлять и добавлять до бесконечности - в таком случае лучше потерять
немного на производительности (хотя спорно это - потеряете ли) но зато
ощутить кайф того как легко можно модифицировать систему с минимальными
потерями
Я только не согласен с автором, по поводу ссылок.
Кто на кого ссылки должен хранить.
Классический вариант:
Модель не имеет ссылок, ни на контроллер, ни на виды.
Модель ни о ком ничего не знает.
Вид имеет ссылку на модель.
Контроллер имеет ссылки на модель и вид.
Самый лучший вариант (придумал, к сожалению, не я, такая схема в
Swing, лучше лично я не встречал, даже на счет использования иньекций
можно бросить пару камешков, можно, можно, не сомневайтесь):
Модель не имеет ссылок (но диспатчит эвенты).
Вид не имеет ссылок (но диспатчит эвенты).
Контроллер имеет довольно глубокую иерархию наследования, от
более общих конструкций, до, например, абстрактного класса всех кнопок
вообще, и, "в конце" - конкретной кнопки (класс контроллера кнопки,
например JButton, объекты которого можно инстранцировать во многих
проектах).
Контроллер по умолчанию делает вот что:
1) Создал (через new) новый экземпляр View (причем берет класс для View - по
умолчанию тоже, например ViewDefault)
2) Создал (через new) новый экземпляр Model (тоже - ModelDefault)
3) Назначил подписку, себе, на события от Model и на событий от View.
ИТОГО:
1) Контроллер "просто" перенаправляет события между Model и View.
2) Model и View - не знают друг о друге.
3) Схема связывания, всего, реализованная в контроллере - ДИНАМИЧЕСКАЯ.
Это означает следующее - в процессе выполнения можно,
в контроллере, отписаться в нем от ТЕКУШЕЙ Model и от ТЕКУЩЕГО View,
УДАЛИТЬ экземпляры View и Model, создать (через new) НОВЫЕ
экземпляры Model и View, подписаться на события от Model и View.
4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но
при ИНСТАНЦИРОВАНИИ приложения, например, назначются такие объекты,
по умолчанию, т.е. у вас нет никаких null. И / или может быть и так -
в КОНКРЕТНОЙ реализации класса-контроллера, во всей иерархии
классов-контроллеров - метод инстанцирования View и Model - указан
более специализировано, в соотв. с тем, какие задачи выполняет
текущий контроллер.
P.S. Сюда бы еще пример кода, как поистине грамотно это все
реализовано в Swing , но лично у меня нет времени для этого, а
кто минимально знает Java - откройте в Eclipse класс JButton из
пакета Swing, и по кнопке F3 - доберитесь до первого абстрактного
класса, в иерархии наследования выше.
Так же обратите внимание на "систему именования" методов в модели
и др., которые диспатчат события - метод начинается со слова
"fire", далее указывается "слово" конкретного события. Кажется
так. Подобную систему видел и в других фреймворка, поэтому лучше
не лепить огород, а следовать "классике, в некотором понимании
этого вопроса.
> Модель не имеет ссылок (но диспатчит эвенты).
> Вид не имеет ссылок (но диспатчит эвенты).
- видимо, ты имел ввиду "не получает ссылок в конструктор".
Т.к. раз вещает, то ссылки имеет.
> 4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но
- если не ошибаюсь, это еще один шаблон проектирования.
Нулевой объект. Null Object или как там, не поомню.
Идея заключается в том, что если в классе может быть, а может и не быть
какой-то подчиненный объект, то лучше создать пустой статический объект
и подложить его, а не проверять каждый раз ифами наличие этого объекта.
3) Схема связывания, всего, реализованная в контроллере - ДИНАМИЧЕСКАЯ.
Это означает следующее - в процессе выполнения можно,
в контроллере, отписаться в нем от ТЕКУШЕЙ Model и от ТЕКУЩЕГО View,
УДАЛИТЬ экземпляры View и Model, создать (через new) НОВЫЕ
экземпляры Model и View, подписаться на события от Model и View.
> - видимо, ты имел ввиду "не получает ссылок в конструктор".
> Т.к. раз вещает, то ссылки имеет.
Да, высказался не совсем точно.
В общем контроллер имеет два privat поля, в одно из которых помещает
ссылку на View, в другое - ссылку на Model.
Сами View и Model - ничего не инстанцируют и ничем не пользуются.
>> 4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но
> - если не ошибаюсь, это еще один шаблон проектирования.
> Нулевой объект. Null Object или как там, не поомню.
> Идея заключается в том, что если в классе может быть, а может и не быть
> какой-то подчиненный объект, то лучше создать пустой статический объект
> и подложить его, а не проверять каждый раз ифами наличие этого объекта.
Да, такой есть. Честно говоря вот всю эту конструкцию я реализовывал
на AS2 года 2 назад, тогда же и вникал в Swing, сейчас уже в нюансах
так точно не помню. Паттерн Null Object в "прямом виде" там так не
использовался - вот что могу сказать. Сорри, если что.
> вроде весь смысл Model в том что он един.
- их может быть много. Разных.
Пример: биржевой график.
Смотришь одну компанию, переключился, смотришь другую.
Вполне возможно реализовать заменой модели.
Помните, как во многих вещах - мы можем динамически менять dataProvider - ?
Например мы инстанцируем новый объект JButton, а ПОТОМ - назначаем/придаем ему какие-то свойства.
Например - более продвинутую (или - не стандартную, а "кастомную") модель.
В случае с XML структурами, например XML-деревом это может пригодится - создаем новую модель,
наследуясь от стандартной, "расширяем" стандартную реализацию (разработанную для МНОГИХ проектов) -
под конкретную реализацию в текущем проекте или для конкретного инстанцирования в таком-то месте.
Или можем так же динамически изменять / назначать - класс РАСПОЛОЖЕНИЯ элементов на экране. - Есть
некоторый метод set в качестве параметра которому, этому методу - передаем новый объект (в качестве
параметра этому методу, прямо там пишем new).
Надеюсь объяснил, сорри если что.
> - их может быть много. Разных.
> Пример: биржевой график.
> Смотришь одну компанию, переключился, смотришь другую.
> Вполне возможно реализовать заменой модели.
Это линейная база данных, по сути. Каждый элемент является данными
по одной компании.
Гораздо интереснее древовидная база данных, по образу и подобию
очень похожая на структуру display object-ов. Можно даже с
бабблингом по базе данных.
Например, чтобы заранее подготовить свой внешний вид, а потом сразу
отобразиться.
Кроме того, если дисплей обжект не в дисплей листе, то это ещё не
означает, что пользователь его не видит.
Пример:
addChild(new Bitmap(bitmapData));
bitmapData.draw(sprite);
Кроме того, если дисплей обжект не в дисплей листе, то это ещё не
означает, что пользователь его не видит.
Пример:
addChild(new Bitmap(bitmapData));
bitmapData.draw(sprite);
Пример: онлайновая азартная игра. Рулетка, слот, крепс, блекджек или
покер - это не важно, но для определённости возьмём рулетку.
Пришли данные от сервера: на рулетке выпал такой-то номер, эти ставки
выиграли, эти ставки проиграли, итоговый баланс игрока такой-то.
Модель как бы уже изменилась (как минимум баланс поменялся).
Но Представление №1 - рулетка - сперва должна покрутиться и на ней
попрыгать шарик.
Затем Представление №2 - игровой стол со ставками - должен плавненько
переместить чипы, выигрывшие - в одну стороны, проигравшие - в другую.
И только после всего этого Представление №3 - индикатор баланса -
должен отобразить новый баланс.
Как это реализуется в MVC?
Другой пример: некая динамичная игра, в которой игрок может как
получать очки, так и терять их.
Но нужно сделать так, чтобы при любом изменении очков новое значение
отображалось не моментально, а чтобы циферки "крутились".
Т.е. получил игрок 200 очков - в течении 20 кадров добавляется по 10
очков. Проиграл 100 очков - в течении 10 кадров уменьшается на 10
очков.
А теперь ситуация: игрок выиграл 500 очков (индикатор побежал вверх,
но ещё не добежал до целевого значения), почти тут же проиграл 300
очков, и спустя долю секунды опять выиграл 100 очков.
Опять же, как нам тут поможет MVC?
> Гораздо интереснее древовидная база данных, по образу и подобию
> очень похожая на структуру display object-ов. [...]
- да, сразу вспоминаются мои эксперименты с XML
и попытки навесить классы на ноды :)
Т.е. по-сути из XML сделать иерархическую модель,
и затем навесить представление.
Глядя назад, думается, что идея интересная,
но сложная для реализации в AS1-2 и, к сожалению
(или к счастью), бессмысленная в AS3
Пардон :) Нет, конечно :)
> а потом я спрашивал зачем работать, а не зачем существовать. под работой
> представления я понимал его основную задачу в данном паттерне - реакция на
> действия пользователя или отображение данных.
Ну, он может реагировать на enterFrame, например. Или, опять же, на
изменение модели, но по каким-то причинам, мы не хотим сразу
показывать спрайт, а сперва желаем пропустить его через мельницу
битмаповых преобразований.
--
ign
_____________________________________________________________________
http://www.isky.ru
> Опять же, как нам тут поможет MVC?
- MVC не панацея и не обязательство.
Изучая шаблоны не стоит шаблонировать мозг.
Не стоит пытаться загнать проект в шаблон.
Проект должен сам прийти в него уже процессе
программирования.
В представленных тобою случаях классическим
MVC не обойтись.
Обязательно возникнут дополнительные прокладки
для управления потоком событий.
> А теперь ситуация: игрок выиграл 500 очков (индикатор побежал вверх,
> но ещё не добежал до целевого значения), почти тут же проиграл 300
> очков, и спустя долю секунды опять выиграл 100 очков.
А в чем проблема? x += (targetX - x) / 20 на ENTER_FRAME, например :-)
targetX = текущее значение из модели.
Т. е. MVC как-то на визуальные эффекты не влияет совершенно, то, что вьювер с
запаздыванием показывает данные модели — это лишь особенности
реализации вьювера, модель же всегда содержит актуальные данные.
MVC решает одни задачи, State решает другие задачи. В коопирировании,
получается, и будет сила ("В чем сила, брат?" (с))
Например. Вот у вас есть игровой объект (условимся в терминах, пускай
игровой объект обозначает некую абстракцию в игре, например танк,
когда вы инстанцируете танк, то дистанцируете именно ИГРОВОЙ ОБЪЕКТ,
который в себе уже - содержит разные модели, виды, и еще много всего).
Т.е. мы сделали сейчас так, что данный игровой объект - СОДЕРЖИТ ту
конструцию MVC, который мы сделали ранее.
По какому-то событию - вам нужно например сейчас - ИЗМЕНИТЬ состояние
вашего игрового объекта, на такое состояние, при котором он мигает и
не реагирует на клики по нему мышку (в танк попал снаряд). - Что может
быть проще? - Дайте ему, этому игровому объекту - ДРУГУЮ реализацию
того, что показывается в игре. Это не View, это - "полный комплект",
вы динамически сейчас меняется.
Но комплект... на каком-то... низком... уровне...
Потому что MVC позволяет представить как вообще всю игру, сделанную по
патттерну MVC, так и ОТДЕЛЬНУЮ КНОПКУ в игре, сделанную по паттерну MVC.
И таким образом сюда можно "всунуть" паттерн State, динамически
подменяя, в ответ на какие-то события - что-то на что-то.
P.S. Паттерн Strategy примерно в 5 раз проще понять, чем паттерн Singleton.
Доберитесь до примера кода в паттерне Strategy - в три секунды разберетесь по нему.
Вот именно с такой формулой у меня было больше всего багов :)
Например, значение 499 (вместо требуемых 500) может провесеть на
экране очень долго.
Поэтому после нескольких шагов нужно округлить в большую сторону.
Но если у нас очки наоборот уменьшались, то из-за этого округления у
нас может получиться 501.
> Поэтому после нескольких шагов нужно округлить в большую сторону.
Ничего не мешает плюсовать какой-нибудь dx, а результатом показывать
round от dx.
Если дельта меньше 1, то можно прекратить подводить значение и
вывести вполне конкретное. Все эти прыганья цифр и их прокрутка —
чисто визуальный эффект, не более того.
Опять же, это конкретная реализация вьювера, модель тут никакого
участия, кроме как выдачи текущего значения, не принимает.
Иногда отображение данных из модели требует некоторого времени,
нескольких кадров.
А мы хотим показать пользователю сразу готовый результат. Поэтому
готовим объект off-screen, а когда готов - показываем.
Другой случай - визуальный объект вообще никогда не попадёт на сцену.
Но тем не менее будет отображён :)
Например, операции с битмапами позволяют создавать очень интересные
спецэффекты. Но bitmapData не имеет:
- свойства graphics - мы не можем рисовать на нём примитивы (кроме
прямоугольничков и точек);
- детей - мы не можем просто так впихнуть в него, скажем, TextField,
можно только нарисовать с помощью draw;
- кадров - мы не можем сказать ему play(), чтобы он сам собой менялся.
Поэтому иногда приходится делать off-screen визуальные объекты (Shape,
TextField, MovieClip, Sprite), которые никогда не будут добавлены в
display list, но тем не могут зависить от модели, менять свой внешний
вид и, как ни странно, отображаться на экране.
Но если у нас очки наоборот уменьшались, то из-за этого округления у нас может получиться 501.
Можно. Но выглядеть это будет неравномерно.
Например, показания индикатора могут быть такими: 493, 494, 495, бух!,
500 (dx стало меньше 1).
Игроки может и не заметят, а вот QA обязательно придеруться.
> Опять же, это конкретная реализация вьювера, модель тут никакого
> участия, кроме как выдачи текущего значения, не принимает.
Это я привёл простейший пример, когда View отображает неактуальные
значения в Model.
Просто мне кажется, что использование MVC оправдано только в неигровых
приложениях, где View моментально отображает изменения модели.
Изменился список - обновили List. Пришли новые числа - показали сразу.
В игровых приложениях, где View частенько должен слегка отставать от
Model, MVC только всё усложняет.
Я просто говорю о том, что root - это не лучшее место для хранения
модели. В том числе опровергаю такой аргумент как "зато каждый
DisplayObject будет иметь ссылку".
Хотя это и не главное.
Посмотри например движок box2d (флешовый порт). Там все физические
объекты являются невизуальными. Они не связаны ни с DisplayObject, ни
уж тем более с root.
Ты сам решаешь, как их отобразить - сделать отдельный спрайт для
каждого объекта или просто рисовать их через moveTo, lineTo,
drawEllipse и т.д.
Вот именно так я себе и представляю модель. В данном случае - физическую модель.
> Например, показания индикатора могут быть такими: 493, 494, 495, бух!,
> 500 (dx стало меньше 1).
Не dx, а разница (дельта) между targetX и dx. Если будет 495, то дельта будет
равна 5 плюс-минус совсем уж мелочи. Но никак не меньше единицы.
> Игроки может и не заметят, а вот QA обязательно придеруться.
Ну а MVC-то каким тут боком? Один фиг, нужно добираться до
конкретного значения. Получено оно из модели или ещё откуда —
неважно. Вьювер должен показать то, что его просят, а не 500 и
плюс-минус пару десятков, сколько насчиталось.
> В игровых приложениях, где View частенько должен слегка отставать от
> Model, MVC только всё усложняет.
Не знаю, не вижу усложнения. В том же Flex framework слайдер при
клике по треку гоняет ползунок туда-сюда, но значение в конце-концов
вполне конкретное.
>> В игровых приложениях, где View частенько должен слегка отставать от
>> Model, MVC только всё усложняет.
- возможно, ты имеешь ввиду очередь.
Пришли данные - показали первую анимацию, по окончании следующую,
разветвились и т.д.
Вот в этом случае дополнительно нужен будет какой-то управляющий конвеер.
Но принципов MVC - разделения данных и представления никто не отменял.
Да именно.
Но вот для меня пока остаётся загадкой, где должна быть реализована
очередь: в M, в V или может в C?
С одной стороны логично сделать в представлении. Модель просто
сообщает об изменениях, представление складывает изменения в очередь и
обрабатывает по мере возможности.
Но лежать-то в этой очереди будут "срезы" модели. Получается, что
представление содержит в себе модель. Это же нарушение главного
принципа о разделении, или я не прав?
Если реализовать очередь в модели. Получается, что модель "прогнулась"
под представление. Т.е. структура модели (наличие очереди изменений)
обусловлена спецификой представления (его заторможенностью).
Нарушается принцип о независимости модели от представления.
И ещё, что меня частенько напрягает в MVC - это необходимость
дублирования данных, иногда вплоть до одинаковых свойств.
Например свойство balance у модели (актуальный баланс) и свойство
баланс у представления (отображаемый баланс).
> С одной стороны логично сделать в представлении.
- логично сделать отдельным классом, но всё равно,
в модели MVC, конвеер принадлежит представлению
и неразрывно с ним связан.
> Если реализовать очередь в модели.
- нельзя точно.
Затем Представление №2 - игровой стол со ставками - должен плавненько
переместить чипы, выигрывшие - в одну стороны, проигравшие - в другую.
И только после всего этого Представление №3 - индикатор баланса -
должен отобразить новый баланс.
Как это реализуется в MVC?
(контролер сменил текущий активный вид, поползли наши фишки)
Меня больше вот такой вопрос интересовал... если допустим мы имеем достаточно интенсивный процесс изменения вида... А надо ли каждый раз при этом дергать контроллер? Может быть имеет смысл делать некий буфер... и отдавать данные разово.. (ну не знаю таймер, заполнение массива и тд)Ну то есть научить вид немножко разбираться в ситуации..Как это с точки зрения производительности и "правильности"? Сколько автономии давать республикам, чтобы они не захотели отделиться? Не перестали слушаться столицы?