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

[Psijic]

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

private var fileRef:FileReference;


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


fileRef.removeEventListener(Event.SELECT, onFileSelected);
fileRef.addEventListener(Event.COMPLETE, onFileLoaded);
fileRef.load();

[in4core]

Psijic - давай досвидания! Ну что ты пишешь вообще?
Насколько помню, контроллер отвечает только за ввод данных Нет
да и объявление FileReference хранится в модели, а контроллер не имеет к ней доступа Контроллер как раз имеет доступ к модели
но в модели никаких событий типа Event не должно происходить В модели как раз события имееют место.

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

[Psijic]

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

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

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

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

[in4core]

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

[Psijic]

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

public function Controller(model:Object):void
{
_model = model;
}

[in4core]

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

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

[Psycho Tiger]

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

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

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

[in4core]

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

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

[Psycho Tiger]

Пруф в студию !!! Нефиг просто так болтать.
Без конкретной реализации, обобщенно: mvC, don't try at home! (http://www.slideshare.net/damiansromek/thin-controllers-fat-models-proper-code-structure-for-mvc)
По популярнейшим фреймворкам у языков:
PHP: ZendFramework: fat models are good (http://blueparabola.com/blog/fat-models-are-good)
Ruby: Rails best practices: fat model, skinny controller (http://www.devinterface.com/blog/2010/06/rails-best-practices-1-fat-model-skinny-controller/)
Python: Django: Code Organization (http://lincolnloop.com/django-best-practices/applications.html)

... и здесь я устал копировать ссылки у гугла. Попробуй сам! (http://www.google.com)

[in4core]

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

[Psycho Tiger]

Пф.
С одной стороны я с поддержкой создателей и сообщества двух самых совершенных веб-фреймворков, с другой стороны ты с чуваком, который неуверенно говорит "ну не так уж и плохо...".

Ценности в разговоре с тобой я не нахожу, поэтому можно не отвечать; я зашел чтобы помочь топик-стартеру.
Так вот: я за модель, если данные будут храниться в ней. Или за вью, если к модели данные не дойдут.
Категорически против контроллера.

[in4core]

Скажу по секрету, все люди - люди, и те фреймворки пишут тоже люди, которые имеют свое мнение, как и любой другой человек - поэтому от твоего Пф - мокрое место. В данной ситуации я бы делал во вью, я тоже тут против контроллера - но товарищу ТС походу нужно совершенно не это узнать, а почитать основы

[carrotoff]

Я не хочу принимать ничью сторону, но хотел бы внести некоторые коррективы.

С одной стороны я с поддержкой создателей и сообщества двух самых совершенных веб-фреймворков

У Джанги вообще нет такого понятия - контроллер. Там есть Вид, которые выполняет его роль. А вместо вида - шаблоны, но это не суть. Большую часть работу на себя берет модель, но из-за мощного ORM. По факту, кода в "джанго контроллере" получается больше ввиду скрытого функционала модели.

К чему это все я: ну к тому что весь функционал модели готов из коробки, и при адекватном подходе тяжело контроллер сделать толстым.

В рельсах тоже самое (хотя у меня не было с ними опыта, так что, если я не прав - поправь). Большую часть на себя берет ActiveRecord, как ОРМ Джанги.

ZendFramework - это плохой пример. Этот фреймворк печален и давно морально устарел.

ты с чуваком, который неуверенно говорит "ну не так уж и плохо...".
А вот тут я не согласен. Этот "чувак" один из создателей Yii фреймворка. Это очень хорошая штука (многое позаимствовано у рельсов). Еще php-фреймворк достойный внимания - Symfony 2.

Исходя из всего вышеописанного, я пытаюсь подвести разговор к тому, что веб-фреймворк не может быть хорошим примером, почему толстый контроллер плохо или хорошо. Ибо раз человеку удалось в веб-фреймворке сделать толстый контроллер, значит он делает что-то не так, потому что они дают все инструменты, чтобы этого избежать

[Psycho Tiger]

А у меня мало опыта с Джангой :)

Как бы тут ни было: он не говорит, что это хорошо. Он говорит, что это не плохо.
Вопрос был о моде и тенденциях. Это ведь подход, а не конкретная реализация. Вебфрейморки просто самые яркие "реализаторы" парадигмы :)
Я к чему клоню-то: эвмэцэ не описан как прикладное к чему-то конкретному. Скорее это способ организации кода в целом: поэтому я считаю допустимым заимствовать подходы и приводить примеры других языков и фреймворков.

[Babylon]

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

Модель в любом случае работает с данными, которые не отображаются. Дело не в этом. Зачем модели знать о конретной реализации класса загрузки? У нее есть интерфейс посредством, которого она общается с прокси сервисами и получает через него данные.

[Котяра]

По поводу вопроса топика.
Здесь скорее подойдет схема MVCS
Model-View-Controller-Services
Как раз загрузка файлов, отдаётся сервисам.
В моих проектах сервисы сделаны коммандами as3commons.async, и по сути являются обособленными подконтроллерами. Т.е. контроллер инициирует их работу и даёт им ссылку на модель, которую они изменяют.
Другими словами: сервисы - прослойка между контроллером и моделью.
Существуют также прослойки между View и Controleer (Presenter, Mediator)
И между View и Model (Presentation Model, View Model)
Однозначно отнести эти прослойки к каким либо слоям MVC невозможно. Т.к. если смотреть со стороны вью - PM - это контроллер, если смотреть со стороны контроллера или модели - то PM - это вью.

[Babylon]

Котяра, расскажи пожалуйста о преимуществах as3commons.async.

[Котяра]

Преимуществах перед чем?
Мне команды помогают выделить обособленную асинхронную операцию в обособленный модуль.
Который легко модифицируется и реиспользуется.
Код последовательных действий становится понятным.
пример из реального проекта:

_preloadContext = new PreloadContext();
_preloadCommand = new CompositeCommand(CompositeCommandKind.SEQUENCE);
_preloadCommand.addCompleteListener(preloadCommand_completeHandler);
_preloadCommand.addErrorListener(preloadCommand_errorHandler);

var updCommand:UpdateResourcesCommand = new UpdateResourcesCommand(_preloadContext);
createUpdatePreloader(updCommand);
updCommand.addCompleteListener(updateCompleteHandler);

var preloadGuiCommand:PreloadGuiCommand = new PreloadGuiCommand(_preloadContext);
preloadGuiCommand.addEventListener(Event.ACTIVATE, preloadGuiActivateHandler);

_preloadCommand
// грузим rewrite-список ресурсов, парсим его, создаём реврайтер для лоадеров
.addCommand(new LoadAndParseRewriterCommand(_preloadContext))
// грузим локаль
.addCommand(new LoadAndParseLocaleCommand(_preloadContext))
// загружаем дефолный фонт
.addCommand(new LoadSWFCommand('lib/fonts/opensans.swf', new LoaderContext(false, ApplicationDomain.currentDomain)))
// грузим апдейты
.addCommand(updCommand)
// предзагружаем гуи
.addCommand(preloadGuiCommand)
.execute();

Сами по себе команды тоже могут быть составные, например UpdateResourcesCommand
создаёт секвенцию паралленых комманд, которые грузят в 5 потоков по списку файлы и затем их сохраняют в сторадже.

[Babylon]

Cпасибо Котяра. Просто хотел узнать о причинах использования as3commons.async