Форум Flasher.ru

Форум 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)

Psijic 02.09.2013 14:46

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();


in4core 02.09.2013 14:59

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

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

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

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

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

Psijic 02.09.2013 15:02

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

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

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

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

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

in4core 02.09.2013 15:10

Цитата:

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

Psijic 02.09.2013 15:24

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

Код AS3:

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


in4core 02.09.2013 16:32

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

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

Psycho Tiger 02.09.2013 21:52

Цитата:

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

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

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

in4core 02.09.2013 22:50

Цитата:

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

Цитата:

Дядя in4core уже отмечал, что он не-программист
Не помню такого, я программист на тех же правах , что и ты.
Цитата:

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

Psycho Tiger 02.09.2013 23:24

Цитата:

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

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

in4core 02.09.2013 23:54

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

Psycho Tiger 03.09.2013 00:06

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

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

in4core 03.09.2013 00:10

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

carrotoff 03.09.2013 14:01

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

Цитата:

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

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

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

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

Цитата:

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

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

Psycho Tiger 03.09.2013 16:34

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

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

Babylon 03.09.2013 17:41

Цитата:

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

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

Котяра 04.09.2013 12:29

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

Babylon 04.09.2013 13:08

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

Котяра 04.09.2013 13:22

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

                        _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 04.09.2013 14:24

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


Часовой пояс GMT +4, время: 18:27.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.