Пара философских вопросов о MVC
 

Честно говоря не работал с MVC в классическом смысле. Т.е. похожие парадигмы использовал, но интуитивно, не читая теории. Этот как с паттернами, когда вперые начинаешь про них читать, понимаешь, что активно их используешь, не подозревая о том, что это паттерны...

Не до конца для себя понял, зачем нужен controler... Как мне кажется, чаще всего управление программой – эпархия view(например классический GUI), и контроллер в данном случае является дополнительным звеном.

На сколько важно соблюдать стратегию MVC во всем проекте, не делая ни для чего исключений? Например некоторые MiniGames зачастую куда проще написать в виде одно View класса, не разбивая ее на дополнительные сущности.

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

Ну для простого GUI юзать мвц нет смысла. И вообще подстраиваться под существующие шабьлоны проектирования это зачастую усложнение програмного кода, и основных преимуществ тогда оно не принесет. Если у вас появится в этом необходимость, вы сами почувствуете что лучше использовать мвц
Для простого графического элемента - панельки регистрационной какой-то делать контроллер модель и вид это я считаю глупо. Человеку что будет смотреть ваш код проще прочитать 150 строк построения элементов , и несколько прослушивателей чем копаться в 3-4 классах и отслеживать механизмы комунникаций

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

В общем, используя шаблоны, ставте за цель сложные програмные структуры упростить, а не усложнить и запутать простые вещи

Это понятно, что заморачиваться на MVC нужно в тех случаях, где это действительно нужно, а совсем простых проектах по идее и не нужно вовсе. Но коль скоро мы уже решили отделять данные от представления, то тут уже вопрос...
Т.е. у меня есть свои представления о том, какая должна быть архитектура приложения, и оно не совсем соответствует MVC.

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

Хочу разобрать на примере. К примеру у нас есть игра, планарные графы – суть в том, что есть визуально нарисованный планарный граф- точки соединенные линиями. Задача – двигая точки сделать таким образом, что бы линии не пересекались.

В моем представлении приблизительная архитектура должна выглядить так:

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

View. Первое и основное – он читает информацию о графах и рисует ее. По идее в контексте представления так же происходят события мыши. Далее идет пара задач:
Пересечение с объектом. С одной стороны определить пересечение с точкой может контролер, если задача решается на основе радуса точки. Если же, вдруг, нам захотелось проверять пересечение попиксельно ну или hitTest-ом, то крайне не логично отдавать этот функционал за приделы View, потому как делается все на базе визуальных данных.
Второе – механизм таскания точки. Его, безусловно можно перенести в контролер.
Но глядя на все это, я совершенно не вижу в чем тут роль контролера, и он кажется явно лишним.

Скорее всего я чего то не понимаю...

Контроллер обрабатывает все поступающие от компонентов приложения события, переводит модель в новое состояние и визуализирует это изменение с помощью вью.

А вообще, тут есть прикрепленная тема про MVC, если ее прочитать, ответы на Ваши вопросы там есть.

Читал я эту тему, но все не осилил если честно...:rolleyes:

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


Почему еще надо, что бы управление игрой происходило в представлении...
Для чего нам может потребоваться изменение представления? Ну, например, для переноса игры на другую платформу, например телефон. Т.е. это некоторое изменение графики + управление. Логично что это платформо зависимый функционал, и должен находится в представлении. А все остальное должно остаться прежним, без изменений.

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

Так никто и не говорит что всем управляет контроллер. Делите логику как хотите, создавайте дополнительные контроллеры.

Осильте ту тему, там много всего интересного.

Переправил первый пост в своей теме.
Надеюсь, мои статьи помогут Вам разобраться.

Ок... Вот к примеру ваша первая статья с квадратиками. Как реализовать MVC там описано. Теперь вопросы:
Зачем в приведенном примере - контролер?(совсем общий)
Частности: Может я опять же чего то не понимаю. Но как мне кажется, задача модели что-то моделировать, а не просто хранить данные. Иначе это было бы не модель, а База Данных. К примеру в вашем контролере по таймеру мы меняем цвет кадратиков. Если цвет квадратиков - часть некоторого виртуального мира, который мы моделируем, то почему эти цвета меняет не сама модель, а кто-то извне?
Тоже самое касается и свойства pointer. Да, инициатором изменения свойства в данном случае явяется представление, т.е. пользователь. А логику работы должна моделировать модель. С моей точки зрения обработчик события OnChange в контроле должен делать только вызов соответствующего метода модели...
Но при таком раскладе задача контроллера сводится к 2 вещам:
Создание модели и представления.
Форвард сообщений от представления к модели с минимальной логикой.

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

По поводу контроллера. Известны вариации типа "Document-View", это почти то же MVC, только без контроллера. Зачем вообще контроллер? В пору когда был придуман и описан MVC языки программирования еще не владели такими "умными" средствами отображения, какими мы пользуемся сейчас, и контроллер нужен был для интерпретации поступающей информации, как бы делая из полуфабриката готовую пищу для модели. В современных приложениях, тем не менее, можно применять контроллер в качестве диспетчера информационных потоков внутри приложения, ну и отдать ему какие то контрольные функции в плане, например, допустимости получаемой информации. Таким образом избавляя и Model и View от исполнения несвойственных им задач.

Здесь на форуме, есть мнения несколько иного плана. Например, контроллеру отдается и коммуникационная роль и роль выполнения бизнес-логики делая из модели, таким образом, тупое хранилище текущих данных. Конечно, каждый волен реализовать архитектурное решение так как он их понимает. Но, мне, возможно из за недостатка опыта, такой подход не кажется правильным.

В любом случае, MVC - не серебрянная пуля, это лишь один из целого набора архитектурных решений. Мне кажется, что он просто сейчас моден. MVC - это круто!!! .... в таком духе :). Есть, например, правило пяти принципов - SOLID, но, кажется, это сейчас не модно... :)