загрузчик в MVC || S

[Babylon]

Сообщение от Котейка

Да в обход модели. Это не ее дело что там вид грузит. Она про него вообще ничего не знает. Модель это чистая логика и база данных. Будь то консольное приложение или 3D в модели от этого не должно меняться ни строчки кода. В этом и есть смысл MVC-архитектуры.

Несогласен. Прислушайтесь к товарищу СлаваРа.

[Котейка]

А что СлаваРа сказал такого, что противоречит моим словам? Не важно будет вид просить менеджера загрузить что-то для него или справится своими силами. Он сделает это не трогая модель.
Если по вашему должно быть не так, то ответьте мне тогда на вопрос: В чем по вашему главное назначение проектирования MVC?

[Akopalipsis]

Тут я, как один из немногих, который прочёл все статьи о MVCна этом форуме целиком, хочу сказать вот что - есть два лагеря. Один логику выносит в контроллер ( это как я понимаю Котейка один из них ), второй - выносит в модель. я пока за второй лагерь. И так же я ещё придерживаюсь того, что вью сама не чего делать не должно, она лишь считывает данные с модели по её указанию. Но это слова... Вот когда я столкнусь с этим на деле, то я предвижу, что будет не все так просто.

[Котейка]

Akopalipsis, тут вы ошибаетесь, я как раз отношусь к тому лагеру, где логика в модели. О чем и свидетельствует мой пост:

Да в обход модели. Это не ее дело что там вид грузит. Она про него вообще ничего не знает. Модель это чистая логика и база данных. Будь то консольное приложение или 3D в модели от этого не должно меняться ни строчки кода. В этом и есть смысл MVC-архитектуры.

Это классическое MVC. И оно на мой взгляд самое правильное.

[СлаваRa]

Нет такого "классическое" или "неклассическое", есть просто MVC, каждый вправе реализовать как угодно, главное не нарушать принципов.

[Котейка]

СлаваRa, разница между классикой и неклассикой все же есть и Википедия в этом со мной согласна)))

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

Но это не столь важно. То что предлагает Babylon вообще идет в разрез основному принципу MVC - разделения вида и логики.

[Akopalipsis]

То что предлагает Babylon вообще идет в разрез основному принципу MVC - разделения вида и логики.

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

[СлаваRa]

@Котейка, где в вашей цитате разделение на "классическое" и "неклассическое"?

@Akopalipsis, вью тянет с модели линк на ассет, не?
а уж как она отобразит процесс загрузки, как оно отобразит ассет и т.д., это ее дело.

[Akopalipsis]

СлаваRa я не знаю что такое ассет))))

[Tails]

Akopalipsis,
Модель может содержать id отображающей вьюшки, не более.

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