Форум Flasher.ru - MVC: FileReference куда отнести?

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - MVC: FileReference куда отнести? (http://www.flasher.ru/forum/showthread.php?t=203127)

MVC: FileReference куда отнести?

Добрый день. Возник такой вопрос: fileRef позволяет работать с файлами. При разработке в MVC - куда отнести его вызовы? Он вроде как визуальный (а может и нет). Насколько помню, контроллер отвечает только за ввод данных, но в модели никаких событий типа Event не должно происходить - значит, в вид? Или все-таки в модель?

Код AS3:

private var fileRef:FileReference;

Код AS3:

 

fileRef.browse([new FileFilter("Файлы XML", "*.xml")]);

fileRef.addEventListener(Event.SELECT, onFileSelected);

Код AS3:

fileRef.removeEventListener(Event.SELECT, onFileSelected);

fileRef.addEventListener(Event.COMPLETE, onFileLoaded);

fileRef.load();

Psijic - давай досвидания! Ну что ты пишешь вообще?

Цитата:

Насколько помню, контроллер отвечает только за ввод данных

Нет

Цитата:

да и объявление FileReference хранится в модели, а контроллер не имеет к ней доступа

Контроллер как раз имеет доступ к модели

Цитата:

но в модели никаких событий типа Event не должно происходить

В модели как раз события имееют место.

Где хранить данный fileRef - контроллер или вью. По желанию

Да, контроллер имеет доступ к модели, ошибся - не имеет доступа к виду.

Но разве если использовать в контроллере - это не будет ТТУК?

Цитата:

Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.

Цитата:

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

Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, а вся бизнес-логика. В свою очередь, контроллеры представляют собой лишь элементы системы, в чьи непосредственные обязанности входит приём данных из запроса и передача их другим элементам системы. Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами системы

Цитата:

Да, контроллер имеет доступ к модели, ошибся - не имеет доступа к виду.

И к виду он имеет доступ :) В стандартном определении в контролдлере создаются и вид и модель, вид подхватывает модель. Поэтому контроллер может менять модель и читать, вид может только получать get(читать) и события от модели. Модель не имеет доступа ни к контроллеру ни к виду. Это в стандартном определении. Но извратиться можно как угодно.
Ничего плохого ( сильно ужасного ) в толстом контроллере нет, вполне нормальная практика. Тем более говоря о FR - это по сути как мини-сервер, поэтому в контроллере он кстати и на FAT не сильно смахивает

не знаю насчет вида, я пользовался системой описанной Rex van der Spuy - AdvancED Game Design with Flash 2010

Код AS3:

                public function Controller(model:Object):void

                {

                        _model = model;

                }

http://www.flasher.ru/forum/blog.php?b=256

Читаем внимательно, и разбираемся :) Удачи

Цитата:

в толстом контроллере нет, вполне нормальная практика.

...на первых порах. Дядя in4core уже отмечал, что он не-программист, поэтому ему простительно; мода и тенденция уже закрепилась за тонким контроллером.

По вопросу – ну, точно не контроллер. Это "клей" между вью и моделью – почему клей должен служить точкой ввода данных?.
Скорее всего, вопрос в том, кому нужны эти данные. Если эти данные подразумевается хранить в модели – значит, пусть модель их и грузит. Lazy-loading: при обращении к модели, если эти данные нужны, но их ещё нет – пусть определит модель, откуда им взяться.

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

Цитата:

очему в модели это хранить удобно? Потому что другие вью, использующие эти же данные сразу получат их, минуя все преграды, что хорошо.

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

Цитата:

Дядя in4core уже отмечал, что он не-программист

Не помню такого, я программист на тех же правах , что и ты.

Цитата:

мода и тенденция уже закрепилась за тонким контроллером.

Пруф в студию !!! Нефиг просто так болтать. Да и к тому же - мода за Сергеем Зверевым, если чо, наверняка он именно и использует тонкий контроллер. Ну, а если кроме шуток, то нефиг учить людей тому, что придумал сам, у тебя в статье старой все написано нормально - там объяснен MVC как таковой, и как с ним работать.

Цитата:

Пруф в студию !!! Нефиг просто так болтать.

Без конкретной реализации, обобщенно: mvC, don't try at home!
По популярнейшим фреймворкам у языков:
PHP: ZendFramework: fat models are good
Ruby: Rails best practices: fat model, skinny controller
Python: Django: Code Organization

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

http://rmcreative.ru/blog/post/tolst...ak-uzh-uzhasny
Мой вам ответ одной ссылкой. Даже если все равно глубоко подумать, как бы то не было, модель в любом случае занимается логикой, но как ты сопоставляешь слово ЗАГРУЗКА ДАННЫХ С СЕРВЕРА и логика? Логика по сути это рассчеты, если сказать грубо.