я так понял, что модель - это наследник ЭвентДиспечера. ссылка на который передается в качестве параметра во все представления. то есть в случае с флэшом это root??? и патерн VMC практически встроен во флэш?
Модель - это нечто абстрактное, не имеющее само по себе никакого внешнего вида (и соответственно может быть отражено по-разному). Если Модель наследуется от DisplayObject - то это уже не совсем правильная модель. Например, здоровье и количество патронов у персонажа - это Модель. А индикаторы на экране, которые отображают эти данные (в виде чисел, или полосок жизней или ещё каким-то образом) - это Вид.
> то есть вся проблема в том что root является ВЬЮ? > чем это мешает?
> а если в качестве МОДЕЛИ использовать Global? хотя все против него )))
Модель это не просто что-то отдельное от вида. В зависимости от задач вашего приложения это все-же должен быть набор осмысленных классов.
советую к прочтению книжку Гамма, Хелм - "Приемы объектно-ориентированного проектирования: паттерны проектирования" там отлично расписаны основные шаблоны проектирования
допустим у вас есть некая модель содержащая данные: A=10, B=20, C=500, D=250 и т.д. у этой модели есть интерфейсный метод: getData():Array и событие которое всплывает при изменении модели - например Event.CHANGE вы создавая отображение этой модели подписываетесь на указанное событие когда оно всплывает получаете данные и отображаете их
преимущество такого метода в том что вы можете сделать сколько угодно отображений: таблица, график, текст и т.д. и т.п. менять их вы можете сколько угодно менять внутреннее устройство модели, главное чтобы метод getData() возвращал то что от него ожидают следовательно с таким подходом меньше шансов сломать систему и больше возможностей к ее расширению
так же советую заглянуть в PureMVC фреймворк - одна из лучших реализаций паттерна на данный момент
> В зависимости от задач вашего приложения это все-же должен быть набор > осмысленных классов.
МОДЕЛЬ должна быть набором классов? мне казалось что модель это ОДИНОЧА или нет? ну или один и тот же экземпляр передается в качестве параметра всем ПРЕДСТАВЛЕНИЯМ? а какая у него иерархия наследования не важно. а что мешает в AS3? Document class - Main. понятно что root должен реализовывать возможность хранения нужных данных. не понятно коректно ли это. есть ли какие подводные камни мешающие использованию root. сравнение с другими вариантами? глобал. МОДЕЛЬ должна 1. реализовывать возможность хранения/изменения данных 2. оповещая всех заинтересованных в случае изменения данных 3. быть переданной всем ПРЕДСТАВЛЕНИЯМ в качестве переменной дабы они могли забирать нужные им данные ничего не забыл? поэтому мне и кажется что root наиболее хорошо подходит для этих целей. 1. реализовать в root хранение/изменение данных можно 2. root наследник ЭвентДиспечера 3. передается во все потомки DisplayObject
если просто создать свой класс реализующий МОДЕЛЬ от ЭвентДиспечера и не сделать его Document class возникает проблема передавать ссылку на этот объект всем ПРЕДСТАВЛЕНИЯМ. использовать глобал???
так же советую заглянуть в PureMVC фреймворк
слышал что он тяжеловат и сложноват для простеньких проектов. однако сам патерн использовать хотелось бы. да и использовать что либо без понимания - ничего хорошего не получится. хочу разобраться.
> МОДЕЛЬ должна быть набором классов? мне казалось что модель это > ОДИНОЧА или нет?
Модель может повторять структуру View, точнее, View повторяет структуру модели. Т. е. модель вполне себе древовидна может быть.
> если просто создать свой класс реализующий МОДЕЛЬ от ЭвентДиспечера > и не сделать его Document class возникает проблема передавать ссылку > на этот объект всем ПРЕДСТАВЛЕНИЯМ. > использовать глобал???
Собственно, в чем проблема вызвать сеттер модели у View?
Уважаемый, подразумевается, что вы сами будете передавать модель нужному вьюверу. А ссылка на root есть по умолчанию у всех. Что уже неправильно. Так же подразумевается, что состояние модели может изменять только контроллер. А у вас любой объект может достучаться до методов рута. И т.д. Заведите отдельный класс для модели и будет вам счастье.
PureMVC на самом деле очень маленький. Что мне не нравится -- впихивать мелкие действия по командам и отсутствие возможности "слушать" у прокси, хотя это и правильно.
Вообще, друг, такое ощущение, что ты не понимаешь смысл MVC. У тебя есть 3 абстракции: модель, отображение и контроллер. Модель -- содержит данные, грузит данные, конвертирует данные. Этакий черный ящик с интерфейсом. Отображение -- показывает что-нибудь. Контроллер -- обрабатывает действия пользователя через отображения, отдает команды модели и управляет отображениями. Как-то так.
А непосредственно интерпретация может быть очень разная. Например, один объект на view, model и controller. Или много view, один controller, одна модель. Или много Proxy в одной модели.
Смысл в том, что мы отделяем управление от данных и отображения.
Непосредственно по твоему письму, оповещение views может быть сделано множеством способов. Во флекс фреймворках используется data binding, в puremvc notifications и view о модели не знают ничего, где-то используются ссылки непосредственно на модель, хотя мне кажется это неправильно.
> А ссылка на root есть по умолчанию у всех. Что уже неправильно.
чем? в моделе хранятся общие для всех данные. и все имеют к ним доступ. что тут неправильно? думаю с любой реализации MVC все представления завязаны с моделью. у нас же все DisplayObject связаны с root???
> Так же > подразумевается, что состояние модели > может изменять только контроллер.
а что такое контроллер? все что меняет модель и то что мы сами и написали. откуда возьмется "какой то" контроллер который будет менять модель, а мы про него не будем ничего знать?
> Модель ― содержит данные, грузит данные, конвертирует данные. Этакий черный > ящик с интерфейсом.
я полога что Модель только содержит данные и оповещает об их изменении. все остальное делает контроллер?
и view о модели не знают ничего, где-то используются ссылки непосредственно
> на модель, хотя мне кажется это неправильно.
а если view получает только событие, а нужные данные забирает из модели само (для группы данных)? я читал что наличие ссылки в представлении на модель чуть ли не обязательное условие MVC? можно конечно сделать что общение модели и представления происходит исключительно через события, но это не всегда удобно. а потом как тогда контроллер узнает про модель ?
> А ссылка на root есть по умолчанию у всех. Что уже неправильно.
> чем? в моделе хранятся общие для всех данные. и все имеют к ним > доступ. что тут неправильно? думаю с любой реализации MVC все > представления завязаны с моделью. у нас же все DisplayObject связаны с > root???
При таком подходе вы не соблюдаете один из основных принципов объектно-ориентированного программирования. Имя ему - инкапсуляция. Модель хранит данные только для вьюверов, никому больше эти данные не нужны.
|
