![]() |
Пф.
С одной стороны я с поддержкой создателей и сообщества двух самых совершенных веб-фреймворков, с другой стороны ты с чуваком, который неуверенно говорит "ну не так уж и плохо...". Ценности в разговоре с тобой я не нахожу, поэтому можно не отвечать; я зашел чтобы помочь топик-стартеру. Так вот: я за модель, если данные будут храниться в ней. Или за вью, если к модели данные не дойдут. Категорически против контроллера. |
Скажу по секрету, все люди - люди, и те фреймворки пишут тоже люди, которые имеют свое мнение, как и любой другой человек - поэтому от твоего Пф - мокрое место. В данной ситуации я бы делал во вью, я тоже тут против контроллера - но товарищу ТС походу нужно совершенно не это узнать, а почитать основы
|
Я не хочу принимать ничью сторону, но хотел бы внести некоторые коррективы.
Цитата:
К чему это все я: ну к тому что весь функционал модели готов из коробки, и при адекватном подходе тяжело контроллер сделать толстым. В рельсах тоже самое (хотя у меня не было с ними опыта, так что, если я не прав - поправь). Большую часть на себя берет 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, время: 17:03. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.