Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Как правильно осуществить MVC архетиктуру?
Форумы портала PHP.SU » » Объектно-ориентированное программирование » Как правильно осуществить MVC архетиктуру?

Страниц (1): [1]
 

1. ВеликийПрограмист - 20 Сентября, 2017 - 08:40:16 - перейти к сообщению
Куча статей в интернете и каждая по своему описывает MVC.

Как это понял я
1. Модель это логическая база приложения.
2. Вид это просто темплата
3. Контроллер - не совсем понял зачем он нужен, некоторые говорят чтобы управлять моделью и видом, другие говорят что он только собирает команды пользователя и отправляет в модель.

Еще вопросец сколько моделей и контроллеров должно быть всего один или несколько в каких случаях нужно создавать дополнительный?
2. teleoperator27 - 20 Сентября, 2017 - 09:11:00 - перейти к сообщению
модель общается с БД
контроллер между моделей и вьюхой - обрабатывает данные
вьюха отображает
3. ВеликийПрограмист - 20 Сентября, 2017 - 09:57:55 - перейти к сообщению
Есть какието ссылки на источник, а то по картинки из википедии немного не так.
4. Мелкий - 20 Сентября, 2017 - 11:10:34 - перейти к сообщению
ВеликийПрограмист пишет:
Куча статей в интернете и каждая по своему описывает MVC.

А так оно и есть. Буквосочетание mvc модное, и до ужаса размытое.

ВеликийПрограмист пишет:
3. Контроллер - не совсем понял зачем он нужен, некоторые говорят чтобы управлять моделью и видом, другие говорят что он только собирает команды пользователя и отправляет в модель.

Великий холивар толстых и тонких моделей. Поэтому встречаются оба варианта.
Общий момент - контроллер - это входная точка для обработки запроса. Иногда (по моей практике в PHP чуть менее чем всегда) контроллер обрабатывает всю основную логику поведения приложения, иногда - служит лишь точкой входа, объясняет модели что надо сделать (а сами действия выполняет модель, что резко удобнее, когда надо повторить действие где-то в другом месте, например, из консоли или из другого контроллера)

ВеликийПрограмист пишет:
Еще вопросец сколько моделей и контроллеров должно быть всего один или несколько в каких случаях нужно создавать дополнительный?

И моделей и контроллеров определённо будет много.
Ну разве только ваше приложение - это какой-нибудь лендинг всего о двух действиях "показать лендинг" и "создать заказ". Да в таком случае и mvc приплетать избыточно.
Контроллер - набор обработчиков каких-то действий пользователя, связанных по смыслу. Ну там "показать список постов", "показать целиком пост". Регистрация пользователя как-то к постам не очень вяжется - поэтому логичнее выносить отдельным контроллером.
Модель - это какая-то сущность. Ну, например, автор поста и пост - две модели. В одну их объединять как-то странно получится.
5. ВеликийПрограмист - 20 Сентября, 2017 - 11:47:28 - перейти к сообщению
Если как ты говориш видел оба способа (контроллер управляет видом + моделью или контроллер просто подает данные в модель, а модель дает в вид) применяются какой ты считаеш лучше?

Читал тут в исходных текстах на Smalltalk-80 изобретатили MVC пишут что контроллер управляет моделью и видом. По моему это не сильно отличается от подхода в обычной процедурке когда есть страницы users.php, new_user_register.php и т.д. и в каждой странице есть своя тимплата Smarty к примеру. Ну и дальше все как всегда php страница там бизнес логика, а в темплате логика репрезентации инфы которую php страница достала из базы.

Я вот в подходе MVC не вижу особой разницы если делать по контроллеру на каждую страницу сайта это чем-то отличается от процедурного подхода кроме перестановки слогаемых и обзыванием крутым словом MVC?
6. Мелкий - 20 Сентября, 2017 - 12:50:51 - перейти к сообщению
ВеликийПрограмист пишет:
контроллер просто подает данные в модель, а модель дает в вид

Вид тоже контроллером вызывается.
В толстой модели вся логика приложения размещается в модели.
В тонкой модели вся логика приложения живёт в контроллере. А модель - тупая прослойка к данным.

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

Отдельный холивар: готовит ли контроллер все данные для представления или представление может самостоятельно дёргать модели для получения интересующих данных.
Ещё холивар современного веба - а где вообще находятся контроллер и представление, на сервере или на клиенте?
Много там холиваров, с этим mvc.

ВеликийПрограмист пишет:
как всегда php страница там бизнес логика, а в темплате логика репрезентации инфы которую php страница достала из базы.

Осталось отделить код работы непосредственно с данными в функции (если уже не сделано) - и вы получили MVC с тонкими моделями. Вынесли в функции высокоуровневую логику и вызываете именно эти функции из обработчика запроса пользователя - вот вам толстая модель.
А кто сказал, что mvc это про ООП? Это в первую очередь концепция разделения ответственности. До жути размытая концепция.

И ещё удивительная вещь - для использования ООП нет необходимости в использовании классов, а с использованием классов можно продолжать писать в функциональном стиле. Ладно, это не для джуниора фокусы Закатив глазки Хотя я серьёзно.

ВеликийПрограмист пишет:
Я вот в подходе MVC не вижу особой разницы если делать по контроллеру на каждую страницу сайта это чем-то отличается от процедурного подхода кроме перестановки слогаемых и обзыванием крутым словом MVC?

Не на каждую. Всё-таки контроллер обычно объединяет группу логически связанных страниц.
хинт: найдите отличие с подходом через соглашение об именование действий. например, user_show_profile.php , user_register.php - это же один контроллер user, в нём 2 action. Писать его 2 разными файлами или разными методами одного класса - по большому счёту никакой разницы. Можно придумать какие-нибудь плюшки, которые будут проще делаться в одном классе (например, проверка прав доступа пользователя сразу ко всем методам этого контроллера до вызова непосредственно действия, или рядом размещённые повторяющиеся методы без необходимости думать как обеспечить им уникальные по всему проекту имена) - но тот же самый эффект можно получить и без классов простым соглашением кодирования
7. ВеликийПрограмист - 20 Сентября, 2017 - 14:13:15 - перейти к сообщению
Спасибо за хинт.

Мелкий пишет:
Отдельный холивар: готовит ли контроллер все данные для представления или представление может самостоятельно дёргать модели для получения интересующих данных.
Ещё холивар современного веба - а где вообще находятся контроллер и представление, на сервере или на клиенте?
Много там холиваров, с этим mvc.

По мне представление это чисто для генерации страницы клиенту тимплат+данные из модели, ведь когда юзвер жмет на ссылку по теории должен контроллер принять не вид.

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

Мелкий пишет:
А кто сказал, что mvc это про ООП? Это в первую очередь концепция разделения ответственности. До жути размытая концепция.

И ещё удивительная вещь - для использования ООП нет необходимости в использовании классов, а с использованием классов можно продолжать писать в функциональном стиле. Ладно, это не для джуниора фокусы Закатив глазки Хотя я серьёзно.

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

Вот это я лично видел у индусов в коде классы, а смысла ноль просто зашили процедурный код в классы и обозвали ООП. Но как можно писать ООП без классов я не особо догоняю?
8. Мелкий - 20 Сентября, 2017 - 14:30:05 - перейти к сообщению
ВеликийПрограмист пишет:
Как контроллер и представление может быть у клиента или о каком клиенте идет речь?

Single page application например.
При этом с точки зрения PHP весь view - одна стартовая страничка. Да куча методов для общения с приложением. А весь слой представления содержимого пользователю реализован в js в браузере (т.е. на клиентской стороне приложения или "на клиенте" как распространённое сокращение)
Где же при этом контроллер - да ктулху его знает. В js получается код обработки действий пользователя, в PHP слой обработки api запросов. Допустимо ли второй называть контроллером?...
(Добавление)
ВеликийПрограмист пишет:
Но как можно писать ООП без классов я не особо догоняю?

Ну, например язык C: https://habrahabr[dot]ru/post/263547/
9. Bio man - 22 Сентября, 2017 - 01:11:42 - перейти к сообщению
Мелкий пишет:
В тонкой модели вся логика приложения живёт в контроллере.
Стоило предупредить, что это плохая практика, а то топикстартер может принять это за постулат.

Я предпочитаю тонкие модели и тонкие контроллеры - никакой бизнес-логики в контроллере быть не должно, только логика обработки запроса.
Для бизнес-логики более подходящее место это сервисный слой (он-же Application layer). В таком случае, БЛ можно повторно использовать в любом месте.

В кратце:
- модель содержит логику для поддержания своей целостности и валидности
- сервис содержит логику для обработки модели (например, сервис может сохранять модель осуществляя дополнительные проверки)
- контроллер принимает запрос, обрабатывает его и отдает ответ

Мелкий пишет:
Отдельный холивар: готовит ли контроллер все данные для представления или представление может самостоятельно дёргать модели для получения интересующих данных.
Исходя из вышесказанного, контроллер лишь передает данные во вью слой, а он уже готовит, как ему надо.

Мелкий пишет:
Ещё холивар современного веба - а где вообще находятся контроллер и представление, на сервере или на клиенте?
Не понимаю, почему холивар? И там и там может быть.

Мелкий пишет:
Не на каждую. Всё-таки контроллер обычно объединяет группу логически связанных страниц.
Просто хочу добавить. В Магенто 2, контроллер это строго 1 действие. Но не будем о плохом.

Мелкий пишет:
При этом с точки зрения PHP весь view - одна стартовая страничка.
Не соглашусь. Вью это не только HTML.
Вью это слой трансформирующий данные модели в другой вид, например, JSON, XML или HTML.
Следуя из этого, практически каждое обращение к API приложения (к ендпойнтам, а не API классов) влечет за собой трансформацию данных в другое представление, так, что по сути вью это не только стартовая страничка.

Это мое мнение, и оно не претендует на истину в последней инстанции.

 

Powered by ExBB FM 1.0 RC1