![]() |
MVC: FileReference куда отнести?
Добрый день. Возник такой вопрос: fileRef позволяет работать с файлами. При разработке в MVC - куда отнести его вызовы? Он вроде как визуальный (а может и нет). Насколько помню, контроллер отвечает только за ввод данных, но в модели никаких событий типа Event не должно происходить - значит, в вид? Или все-таки в модель?
Код AS3:
Код AS3:
Код AS3:
|
Psijic - давай досвидания! Ну что ты пишешь вообще?
Цитата:
Цитата:
Цитата:
Где хранить данный fileRef - контроллер или вью. По желанию |
Да, контроллер имеет доступ к модели, ошибся - не имеет доступа к виду.
Но разве если использовать в контроллере - это не будет ТТУК? Цитата:
Цитата:
|
Цитата:
Ничего плохого ( сильно ужасного ) в толстом контроллере нет, вполне нормальная практика. Тем более говоря о FR - это по сути как мини-сервер, поэтому в контроллере он кстати и на FAT не сильно смахивает |
не знаю насчет вида, я пользовался системой описанной Rex van der Spuy - AdvancED Game Design with Flash 2010
Код AS3:
|
|
Цитата:
По вопросу – ну, точно не контроллер. Это "клей" между вью и моделью – почему клей должен служить точкой ввода данных?. Скорее всего, вопрос в том, кому нужны эти данные. Если эти данные подразумевается хранить в модели – значит, пусть модель их и грузит. Lazy-loading: при обращении к модели, если эти данные нужны, но их ещё нет – пусть определит модель, откуда им взяться. Модель – главный (даже вернее сказать "единственный") провайдер данных. Почему в модели это хранить удобно? Потому что другие вью, использующие эти же данные сразу получат их, минуя все преграды, что хорошо. |
Цитата:
Ты даже вчитайся в слова . ВИД - что то визуальное, FR - Не визуальный объект, ну это грубо говоря, дабы и какой нибудь isGUI - тоже не визуальный. Цитата:
Цитата:
|
Цитата:
По популярнейшим фреймворкам у языков: 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
Мой вам ответ одной ссылкой. Даже если все равно глубоко подумать, как бы то не было, модель в любом случае занимается логикой, но как ты сопоставляешь слово ЗАГРУЗКА ДАННЫХ С СЕРВЕРА и логика? Логика по сути это рассчеты, если сказать грубо. |
Пф.
С одной стороны я с поддержкой создателей и сообщества двух самых совершенных веб-фреймворков, с другой стороны ты с чуваком, который неуверенно говорит "ну не так уж и плохо...". Ценности в разговоре с тобой я не нахожу, поэтому можно не отвечать; я зашел чтобы помочь топик-стартеру. Так вот: я за модель, если данные будут храниться в ней. Или за вью, если к модели данные не дойдут. Категорически против контроллера. |
Скажу по секрету, все люди - люди, и те фреймворки пишут тоже люди, которые имеют свое мнение, как и любой другой человек - поэтому от твоего Пф - мокрое место. В данной ситуации я бы делал во вью, я тоже тут против контроллера - но товарищу ТС походу нужно совершенно не это узнать, а почитать основы
|
Я не хочу принимать ничью сторону, но хотел бы внести некоторые коррективы.
Цитата:
К чему это все я: ну к тому что весь функционал модели готов из коробки, и при адекватном подходе тяжело контроллер сделать толстым. В рельсах тоже самое (хотя у меня не было с ними опыта, так что, если я не прав - поправь). Большую часть на себя берет ActiveRecord, как ОРМ Джанги. ZendFramework - это плохой пример. Этот фреймворк печален и давно морально устарел. Цитата:
Исходя из всего вышеописанного, я пытаюсь подвести разговор к тому, что веб-фреймворк не может быть хорошим примером, почему толстый контроллер плохо или хорошо. Ибо раз человеку удалось в веб-фреймворке сделать толстый контроллер, значит он делает что-то не так, потому что они дают все инструменты, чтобы этого избежать |
А у меня мало опыта с Джангой :)
Как бы тут ни было: он не говорит, что это хорошо. Он говорит, что это не плохо. Вопрос был о моде и тенденциях. Это ведь подход, а не конкретная реализация. Вебфрейморки просто самые яркие "реализаторы" парадигмы :) Я к чему клоню-то: эвмэцэ не описан как прикладное к чему-то конкретному. Скорее это способ организации кода в целом: поэтому я считаю допустимым заимствовать подходы и приводить примеры других языков и фреймворков. |
Цитата:
|
По поводу вопроса топика.
Здесь скорее подойдет схема MVCS Model-View-Controller-Services Как раз загрузка файлов, отдаётся сервисам. В моих проектах сервисы сделаны коммандами as3commons.async, и по сути являются обособленными подконтроллерами. Т.е. контроллер инициирует их работу и даёт им ссылку на модель, которую они изменяют. Другими словами: сервисы - прослойка между контроллером и моделью. Существуют также прослойки между View и Controleer (Presenter, Mediator) И между View и Model (Presentation Model, View Model) Однозначно отнести эти прослойки к каким либо слоям MVC невозможно. Т.к. если смотреть со стороны вью - PM - это контроллер, если смотреть со стороны контроллера или модели - то PM - это вью. |
Котяра, расскажи пожалуйста о преимуществах as3commons.async.
|
Преимуществах перед чем?
Мне команды помогают выделить обособленную асинхронную операцию в обособленный модуль. Который легко модифицируется и реиспользуется. Код последовательных действий становится понятным. пример из реального проекта: Код AS3:
создаёт секвенцию паралленых комманд, которые грузят в 5 потоков по списку файлы и затем их сохраняют в сторадже. |
Cпасибо Котяра. Просто хотел узнать о причинах использования as3commons.async
|
| Часовой пояс GMT +4, время: 18:27. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.