MVC: грамотная архитектура проекта

[in4core]

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

Так в MVP - вью не считает логику ни в коем случае, а контроллер не подписан на модель. Причем тут это? Разговор шел только про то, что при получении данных... ну вот даже пример. Контрол послал запрос на сервер о получении данных, получил - 5 данных нужны для модели ( по ним будет проход логики, рассчеты и т.п. в модели) а 1 переменная просто текстовая строка, которую надо отобразить в поле, в моделе ей делать НУ просто нечего! И вот тогда контроллер при получении даты дергает метод вью view.showHeader(e.vars) - в чем тут плоховизна кода и запутанность? Более насущный пример : чат в игре. Простой чат рассмотрим, просто текст, который надо обновить, опять же в моделе хранить его нечего, если не планируется с этим текстом ничего делать, а просто отобразить в поле. Опять же view.updateChat(e.vars) - пришедшие с сервера на on ( сообщение ) . Это не просто нормальная практика - она логична, чем записывать ненужную инфу в модель, подписываться видом на обновление этого свойства и делать 3йю связь( cotrl - model - view), вместо 1ой.

Добавлено через 3 минуты
То есть использование MVP на практике - это в некоторых случаях необходимость, данность. Уменьшает связи ( а мы за это болеем!) упрощает понимание. Понятное дело, что большая часть данных с сервера нужна в модели , но как я уже сказал меньшая часть там просто не нужна, но интерпретировать ее надо

[Dukobpa3]

Сервер - это УЖЕ модель.
Это какая такая строка пришла с сервера которой в модели делать нечего? Из модели пришла, но делать ей там нечего. Ок.

Насчет чата.
В модели архив последних сообщений. Например с буфером в 100 сообщений.
С сервера пришли новые строчки. Старые стерлись новые добавились, во вью прокричали, вью отобразила.

Плоховизна в том что одно действие из двух мест делается. А должно из одного.
Если вью рисуется по модели - пусть рисуется.

Добавлено через 8 минут
Я немного скривил душой.
У меня тоже есть динамические летающие модельки.
Это такая же модель как и все, но она заполняется в момент получения данных с сервера, на лету пристегивается к нужной вьюхе, и нигде не сохраняется.

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

[in4core]

Сервер - это УЖЕ модель.

Вот неправда. Нельзя однозначно назвать сервер моделью. Я бы скорее его вьюхой назвал, потому, что на своем уровне он ПРИЛОЖЕНИЕ, а приложение в глобальном смысле слова - это вью. Main - во флеше это вью ))) Ну не будем вдаваться . В данном случае можно и моделью обозвать, ничего не меняется.

В модели архив последних сообщений. Например с буфером в 100 сообщений.

Я сказал - простой чат, обновление постоянно на str += vars - никаких архивов и перерисовок. Нечего всему тексту в модели делать, тем более кол-во строк может перевалить за Х, а вот БД держать это может - вы путаете холодное с маслом.

Плоховизна в том что одно действие из двух мест делается.

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

Зашел в игру : должен получить текст правил игры ( большой текст, или маленький не важно ). Чего делать тексту правил ( статическая фигень) в модели ? Какие к черту рассчеты и логика, зачем им там быть? Я один раз вписал их в вид через контроллер и забыл про них навсегда! Я же знаю, и на будущее знаю, и на прошлое и работая в команде и все что угодно - что модификация ТЕКСТА делается на сервере и во флеше с ней точно ничего не будет происходить НИКОГДА! - да да сохраню в модели ... фигли , чем толще модель с 10000 данных тем лучше, поиск то никто не отменял?! Найду по контексту!
Не гулпите - MVP - необходимость.

[cleptoman]

что на своем уровне он ПРИЛОЖЕНИЕ, а приложение в глобальном смысле слова - это вью

приложение - это в глобальном смысле слова приложение..возможно на клиентской стороне это и справедливо.

[in4core]

cleptoman - тем не менее войди в дискуссию, ты тоже считаешь, что я не прав по поводу MVP ?

[Dukobpa3]

Все всегда правы в своей субъектинвой реальности
Так как я пишу по МВЦ, то для меня минимальный оверхед в общении с сервером это представить его в виде модели.
Это не еще одна модель.
Это МОЯ модель.
И когда я отправляю-получаю запрос - я просто синхронизирую свою модель с серверной.
Вот и вся загадка.

При чем роль коннектора и протокола в этой схеме настолько мала что на ней даже останавливаться не стоит.

А как там у вас в мвп я не знаю. То что я по картинкам и описаниям увидал - так это один глобальный минус.
Дисконнект сервера и всё упало, потому что ничего нет, нигде, только на сервере.

[in4core]

Dukobpa3 - ну может перестанем переворачивать слова? Я сказал что методика MVP - полезна, в НЕКОТОРЫХ ситуациях, в каких я привел примеры, а вот ДЕЛАТЬ все на MVP - Не стоит, это да, минусы есть. А насчет дисконнект сервера и все упало - вообще фразы не понял, что упало? куда упало? где пропало? Поконкретнее - а то может мы вообще о разных вещах говорим

[cleptoman]

cleptoman - тем не менее войди в дискуссию, ты тоже считаешь, что я не прав по поводу MVP ?

я на такие провокации не ведусь..я не то чтобы писать..я читать уже устал про MVC....делом лучше займись...100% простой по очередной рулетке )

[Dukobpa3]

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

Итак, господа. Ваши варианты реализации?

[in4core]

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