Понимание MVC на конкретном примере

[Nelius]

Понимание MVC на конкретном примере

Я тут в Шаблон MVC втыкаю... читаю форум потихоньку, много полезной информации нашел, прочел...
Но процессе кодинга возникают довольно спорные ситуации, найти правильный выход из которых мне не хватает опыта.
Хотел бы посоветоваться по поводу такой ситуации на примере:

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

Возьмем конфиг CMS системы, он представляет собой модель и реализован у меня ввиде объекта, который имеет два метода set() и get() для работы с данными.
Есть пользователь, как набор данных, который тоже реализован ввиде объекта, также есть UserController, который отвечает а авторизацию, регистрацию и прочие действия.

Итак конфиг содержит все настройки, но когда пользователь залогинился какие-то части этого конфига должны быть заменены на конфиг пользователя.
Удобно при кодинге просто использовать $cfg->get('congig_chto-to'); и при этом не заботиться о том какие данные будут подставлены дефолтные или же то, что для себя настроил пользователь.

Правильно ли я понимаю что "совмещением" конфигов должен заниматься контроллер пользователя, то есть просто подгрузить в основной конфиг, конфиг юзера при успешной авторизации?
Не получаются ли при такой реаллизации ненужные связи между уровнями?

 

[atv]

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

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

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

 

[HraKK]

Не правильно, и еще раз не правильно!
Те данные относятся к модели ЮЗЕРА а не модели конфига, вот их и меняй.
Зачем в общию модель записывать моделль юзера?

 

[boombick]

Зачем в общию модель записывать моделль юзера?

а что такое общая модель? И при чем тут вообще модель?

 

[Nelius]

HraKK
Да, я понимаю и согласен что конфиг юзера отностится к модели юзера.
Но тогда возникает неясность с реаллизацией или в коде постоянно писать

(isset($user->getCfg('news_per_page')) ? $user->getCfg('news_per_page'); : $cfg->get('news_per_page');)

или создвать еще один класс а в нем метод который будет рулить этим впросом)

-~{}~ 16.11.07 00:33:

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

 

[HraKK]

думаю я бы сделал в уже при инициализации userCfg дефолтное значение из общей модели, а если есть свое, то подтавлял бы его.

boombick
Общая модель - это я в частности так сказал о общих настройках.
Как это при чем тут модель? А что это в парадигме МВЦ?

 

[boombick]

Ну я всегда думал, что модель - это функционал самого низкого уровня.. Поэтому не могу себе представить модель юзера. Модель поведения представить могу, но это из другой оперы

 

[Nelius]

HraKK

думаю я бы сделал в уже при инициализации userCfg дефолтное значение из общей модели, а если есть свое, то подтавлял бы его.

Блин... ну я ступил так ступил) Спасибо что ткнули носом! Я просто зациклился на том чтобы использовать $cfg, потому что привязал это к успешному логину, упустив из виду то, что даже если пользователь незалогинен он все равно пользователь, просто его настройки есть дефолтные настройки сервера.

-~{}~ 16.11.07 00:58:

Автор оригинала: boombick
Ну я всегда думал, что модель - это функционал самого низкого уровня.. Поэтому не могу себе представить модель юзера. Модель поведения представить могу, но это из другой оперы

В статье про MVC на IBM.com которую я недавно прочел, была модель юзера. Да и по моему мнению это логично, ведь юзер по сути это набор данных.

 

[HraKK]

Незачто

 

[Pigmeich]

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

классики говорят, что в таком случае надо срочно делать рефакторинг.

Кроме того была одна статистика по C++ проектам в одной компании:

0,7 дефекта на каждый copy-paste более чем 6 строк, возникающих именно в силу фактора "поправил в одном месте, забыл поправить в другом".

 

[boombick]

В статье про MVC на IBM.com которую я недавно прочел, была модель юзера. Да и по моему мнению это логично, ведь юзер по сути это набор данных.

Да все, по сути, набор данных
Паттерн MVC изначально не предназначался для веба, его туда просто адаптировали к веб-разработке Оттого такие непонятки, у каждого свое видение паттерна с некими схожими деталями =)

 

[HraKK]

Ну я всегда думал, что модель - это функционал самого низкого уровня

Модель это данные в понимании ВЕБ концепции.
У меня юзер имеет модель - класс содержащий данные и описывающий модель базы данных и контроллер который отвечает за логику работы с юзером, вместе эта пара есть сущьность юзер.

 

[whirlwind]

Ну я всегда думал, что модель - это функционал самого низкого уровня.. Поэтому не могу себе представить модель юзера. Модель поведения представить могу, но это из другой оперы

Модель вполне себе так автономна и независима от представления. Это не низкий уровень, это просто другой уровень. Модель юзера это и есть атрибуты юзера + поведение юзера. А вот как уж он там представлен в интерфейсе - дело абсолютно десятое.

 

[boombick]

Модель юзера это и есть атрибуты юзера + поведение юзера

в моем понимании модель - это транспорты получения данных, слой абстракции над БД etc. Модель поведения юзера - это контроллер юзера, который предоставляет набор доступных действий, объектное представление данных + темплейты, которые этот контроллер формирует. И, конечно же, обращение к модели, котрая предоставляет данные в удобном для контроллера виде.

 

[Alexandre]

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

Данная абстракция делится на более мелкие абстракции. Вообще парадигма MVC была предложена для модели Java2 в рамках дестоповских приложений. Очень хорошо она укладывается в понимании JSP, когда каждый компонент занимается своим делом.

Применительно к реализации РНР, она немного надуманна и если следовать данной абстракции - то модель слишком усложняется.

В архитектуре WEB приложения есть общая часть кода,а или класс который отвечает за разбор и анализ запроса и входных данных, есть часть кода, который отвечает за логику работы приложения и общая часть кода, которая подготавливает данные для вывода и отдачи контента. Это вполне вкладывается в концепцию Контроллер - Модель - Представление.
А есть еще много дополнительного кода - который трудно отнести к какой либо конкретной части MVC парадигмы.

Конкретная реализация - это личное дело каждого... и спор - куда отнести ту или иную часть, похоже на спор религиозных войн: кто же Истина Иисус или Магомед?

 

[atv]

Это вполне вкладывается в концепцию Контроллер - Модель - Представление.
А есть еще много дополнительного кода - который трудно отнести к какой либо конкретной части MVC парадигмы.

А я думаю, о чём это я написал в своём посте???...
Спасибо что открыл глаза

 

[Nelius]

Автор оригинала: Alexandre
Применительно к реализации РНР, она немного надуманна и если следовать данной абстракции - то модель слишком усложняется.

Я с вами очень даже согласен, все гениальное просто, философия KISS мне по душе.
Модель MVC мне очень нравится и я буду ей следовать, но не всегда.

Касаемо "Представления(View)" в модели MVC, получается что в моей реаллизации это ни что иное как сами html шаблоны, в которые потом шаблонизатор подставляет нужные данные. Получается что фактически в процессе написания кода про Представление можно условно забыть?

Вот сейчас например столкнулся с еще одним непростым вопросом...
В старой версии моей системы был всего один класс, шаблонизатор, остальное было реализовано функциями, ну и собственно говоря глобальные переменные я тоже использовал, правда всего 3, конфиг, языковые данные и переменную $page.
Я для себя тогда определил, что конечная цель всего, что делют мои скрипты это генерация страницы, готового html и переменная $page эту страницу и символизировала, то есть каждая страница имела свой id ($page['id']) и еще ряд параметров. Понимаю что это была не лучшая реаллизация, но это было давно, поэтому я сейчас и занимаюсь рефакторингом =)
Так вот проблема заключается в том что раньше я тупо подставлял языковые данные из глобальной переменной и все, а как теперь быть с локализацией я понятия не имею...
Эти данные как и раньше храняться у меня в отдельных файлах ввиде обычного массива.
Точнее сказать я решил что хранить и импортировать я их буду в XML, а потом админка генерит уже из них файлы с массивами, то есть и юзерам удобно с ними работать и мне в пхп не приходится XML парсить.
Была идея возложить обязанности по управлению языковыми данными на шаблонизатор, но понял что это неудачная идея, потому что они содержат не только то что отностится к шаблону(надписи кноочек, панелек итд), но и данные которые используются везде, в том числе и сообщениях об ощибках, которые выдаются на языке сайта который был выбран и многое другое.
Или стоит оставить глобальный массив и не заморачиваться? Хотелось бы услышать мнения профи по этому поводу.

P.S. Огромное спасибо всем, что помогаете мне разобраться с тонкостями ООП в пхп и с MVC, я конечно читать умею и понимаю прочитанное неплохо, так что способен сам рано или поздно все понять, но этот процесс(понимания) намного быстрее когда люди исходя из своего опыта дают тебе подсказки и задают направление и за это я всем очень благодарен!

 

[AmdY]

У меня есть функция переводчик, она зарегена в шаблонизаторе. в коде tr('sss sssss', 'ru') в шаблонизаторе {tr lang="ru"}sss sssss{/tr}
Хотя я думаю это плохая идея, лучше держать отдельные шаблоны для языков.

 

[Nelius]

AmdY

У меня есть функция переводчик, она зарегена в шаблонизаторе. в коде tr('sss sssss', 'ru') в шаблонизаторе {tr lang="ru"}sss sssss{/tr}
Хотя я думаю это плохая идея, лучше держать отдельные шаблоны для языков.

В моей CMS когда подключаются локализованные данные, проверяется версия, например текущая версия CMS 3.15 а языковых данных на русском 3.10, тогда будут подключены дефолтные английские, так как в русских может не хватать данных, наверное это не лучшее решение, но я просто не люблю сайты где что-то на русском, а что-то на английском языках. Поэтому у меня как таковой функции перевода и быть не может так как в данный момент подключены данные только одного языка...
Вот пытаюсь тоже уйти от реаллизации управления данными в шаблонизаторе...

 

[boombick]

а чем gettext-то не устраивает?