загрузчик в MVC || S

[Babylon]

Сообщение от Котейка

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

Модель говорит контроллерам, а не виду.
Приказывает Контроллеру выполнить команду по условию.
Котейка Вы меня утомили немного. Я на ваши посты более не реагирую.

[Котейка]

Вы меня если честно тоже) Обижайтесь не обижайтесь, но архитектуру MVC вы не понимаете, как и то зачем она вообще нужна. Быть может в теме еще отпишется кто-то к чьему мнению вы прислушаетесь больше. Мне вас переубедить не удалось, что впрочем неудивительно я ж тут новичок)

[KumoKairo]

Модель говорит контроллерам, а не виду.

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

Начинающие программисты (особенно в веб-программировании, где аббревиатура MVC стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC. В этом случае модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику. В результате код моделей по факту является средством получения данных из СУБД, а контроллер представляет собой типичный модуль, наполненный бизнес-логикой, или скрипт в терминологии веб-программирования. В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)[6]:

Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в вид. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.

Стоит отметить, что ни пассивная модель, ни активная никоим образом не воздействуют на контроллер.
Контроллер пользует только вид, и в 90% случаев этому предшествует какое то действие пользователя.




Соглашусь с Котейкой, MVC архитектуру вы немного недопоняли.

[Dukobpa3]

представьте Вы хочете отобразить ассет, а они кончились.

Он его таки выкачал. Интернет кончился.

[Babylon]

KumoKairo модель как и вид разговаривают с контроллером посредством диспатча кастомных эвентов.

[KumoKairo]

Покажите мне готовый толковый пример из интернетов, где модель разговаривает с контроллером, передавая ему логику работы приложения

У меня есть несколько ссылок (в том числе и на Design Patterns in AS 3.0), где мое и Котейкино представление шаблона MVC подтверждается
===============

Пользователь зашёл на сайт не авторизованным и модельЮзер пуста. После нажатия на авторизацию чере соцсети ( клик по кнопке ), вью стреляет событие контроллеру, тот стреляет событие сервису. Сервис должен знать, что именно ему нужно загрузить ( потому, что там много лишнего из соцсетей ). Он начинает ворошить БД на сервере и искать там вошедшего пользователя. Там его не оказалось и сервис считывает дефолтные настройки профиля и все загружает. При загрузке он представления грузит в "базу представлений", а остальным набивает модельЮзер. По окончанию, он стреляет событие контроллеруЮзерМодели и юзерМодель сообщает вью о окончании. Вью соответственно лезет в юзерМодель и узнает id и прочее. Вью отыскивает в словареДляВью представление с полученным id. И все вроде удачно. я не где не ошибся?
И тут наверное мои слова о контроле загрузки моделью - поспешны, я исключал влияние самого сервера. А думал лишь о сервисе...

В целом все по логике, да. По крайней мере насколько я смог разобраться.

[Akopalipsis]

Сразу хочу сказать, что свои слова произношу с улыбкой. Вы сами читаете что пишите?)

Сообщение от Котейка

Модель даже не отдает команды виду. Она просто работает сама по себе оповещая контроллер об изменениях.

Тут ТС явно указывает на то, что модель диспатчит КОНТРОЛЛЕРУ

Сообщение от Котейка

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

Тут ТС утверждает что КОНТРОЛЛЕР диспатчит ВЬЮ

Сообщение от KumoKairo

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

Возможно утомился я, но мне кажется, что тут утверждение что - МОДЕЛЬ не диспатчит КОНТРОЛЛЕРУ а КОНТРОЛЛЕР не диспатчит ВЬЮ.
Следом вы приводите картинку с тем кто кому отдает приказания. И тут как гром среди ясного неба -

Сообщение от KumoKairo

Соглашусь с Котейкой, MVC архитектуру вы немного недопоняли.

я не понимаю Вас)))

[KumoKairo]

Модель даже не отдает команды виду. Она просто работает сама по себе оповещая контроллер об изменениях.

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

Отдавать команды и диспатчить события - в корне разные случаи. Смотрите.

В случае с "говорит что делать" у нас есть прямые ссылки на объекты, которые (ссылки) мы в лоб хардкодим:

function setController(someController:IControler):void
{
    var myLittleController:IControler = someControler;
    myLittleController.someMethod(someParam);
}

В этом случае мы прямо указываем какой метод нужно выполнять. В случае с диспетчиризацией событий (на примере библиотеки AS3 Signals):

public class SomeSignalDispatchingClass
{
    public var myLittleSignal:Signal;
 
    public SomeSignalDispatchingClass()
	{
	    myLittleSignal = new Signal();
	}
 
	public function somethingHappened():void
	{
	    myLittleSignal.dispatch();
	}
}
//Другой класс-слушатель событий объекта класса SomeSignalDispatchingClass
public class SomeSignalListener
{
    public SomeSignalListener(signalDispatcher:SomeSignalDispatchingClass)
	{
		signalDispatcher.add(someSignalListener);	
	}
 
	private function someSignalListener():void
	{
		trace("Signal was dispatched");
	}
}

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

Надеюсь так мы лучше поймем друг друга

[Wolsh]

Это обескураживающее всех недоразумение с двумя разными идеями MVC на самом деле очень простое.
Большинство флэш-девелоперов приходят во флэш из веб-разработки. Это вполне естественно, ибо флэш, как ни крути, дитя и слуга Веб. С какого перепугу они вдруг начнут менять свое представление о программировании? Лет десять человек учился на форумах РНР-шников, с молоком матери впитал что Модель это тупая безмолвная БазаДанных на MySQL, Вью это хтмл-страница (+ немного джаваскрипта для пущей интерактивности) в браузере клиента, а Контроллер — конечно же, великолепный РНР-код обсуждаемого разработчика, в котором, естественно (а где же еще?), и сосредоточена вся логика веб-приложения.
Это не ересь, не тупость. Это технически обоснованная вариация на тему MVC, известная так же как MVP. Сама технология продиктовала такой тип абстрагирования. А со временем воспитались миллионы РНР-программистов, свято верящих в то, что это и есть кошернейший классический MVC. А некоторые из них, попав во флэш-разработку, из чувства вселенской любви и сострадания одарили нас разными фреймворками (РНР-шники очень любят писать фреймворки).
Но мы то программируем на AS3. У нас нет физически валяющегося где-то на сервере мешка с данными, умеющего только хранить и отдавать эти данные. У нас нет даже деления на разные языки программирования для каждой части MVC. Мы конечно можем, если захотим, использовать такую концепцию (или взять известный фреймворк, и нас уже никто не спросит) с пассивной Моделью и Толстыми контроллерами. Но зачем? Там это — техническое ограничение. У нас его нет. У нас прекрасно реализуется стандартная классическая парадигма MVC с активной моделью и "пустыми" контроллерами. Именно такая система рассматривается в упомянутой книге "ActionScript 3.0 Шаблоны проектирования" — первой в мире книге по AS3. Потому что совершенно непонятно, зачем слепо тащить в AS3 все это РНР-наследие (со всем уважением к огромному опыту и наработкам, конечно).
Просто отсеивайте, что откуда. Не путайте MVC и MVP.

[Котейка]

Akopalipsis, суть не в том диспатчит модель или нет и кому Суть в том что она командует.

М->C: Дать виду спрайт дуба.
М->С: Отображаем дуб в виде.
М->С: Выдать в виде сообщение об ошибке.

Такого быть не должно.
Представьте себе что модель одна. Нет ни контроллера ни вида. Она создает мир, деревья в нем, животных, людей. Последние живут своей жизнью. Но графического представления этому нет, только логика. Все что делает модель это диспатчит изменения внутри себя, вникуда просто диспатчит. >Вырасло такое-то дерево. >Родился такой-то человек. >Тот пошел туда-то.
Модель у нас есть.
Внезапно трах тибидох появляется вид, начинает ловить события модели и их отображать. По своему как умеет. Люди кружочки. Деревья палочки. Если в модели кто-то родился. то появляется новый кружок и т.п.
Вот есть у нас и вид.
Потом приходит юзер. И он хочет как-то влиять на эти самые кружочки и палочки, ему нужно это щупать и изменять прямо в виде, неудобно же в модели, да и х.з. как. И чтобы все это связать, чтобы и вид и модель работали по отдельности, но могли оповещать друг друга появляется контроллер. Он слушает модель и передает в вид что там поменялось, а вид по свойски отображает. А так же он слушает чего там хочет наш юзер, что он щупает. И дергает модель за ниточки чтобы та обрабатывала запросы юзера.
Это и будет MVC.
То есть если вид заменить другим более навороченным, то от этого ничего не поменяется в модели. И наоборот, если вид станет хуже, то опять же модели по барабану. Будет он там людей показывать видом сверху или с головой марсиан=)