×

Как вникнуть в MVC, ООП и начать работать с framework?

Столкнулся с проблемой в обучении, точнее с обучением в относительно короткие сроки.

Я давно занимаюсь разработкой на WordPress, отлично знаю кодекс, пишу небольшие плагины, но функциональным программированием соответственно на PHP. С ООП полный косяк. Сейчас появилась задача сделать значительно упрощенный аналог игры как у сайта «Бизнес Молодость». По сути регистрация юзеров и отписывание успехов в общей ленте комментариев, но задача состоит в автоматизации мониторинга активности юзеров и формирования таблицы с результатами в админке (отписал пользователь — в таблицу заносим +, не отписал — выдаем желтую карточку, не отписал еще день — выдаем красную, еще день — удаляем из игры).

Я решил, что такую задачу хоть и реально реализовать на WP, но логичнее писать на framwork. В силу того, что сроки не сжаты я посчитал это отличным поводом начать изучения yii. И тут я столкнулся с проблемой, что я не понимаю ничего из документации yii. Почти ничего. Сделал выводу, что в yii я лезу рано и решил посмотреть в сторону принципа MVC как такового. После гугления на предмет «Пишем свой MVC framwork» я столкнулся с тем, что совершенно не понимаю ООП. Начал искать про ООП и так кусками то там, то тут выходит какая-то каша и занимает это слишком много времени.

Собственно вопрос: Есть ли курс/уроки/чтиво, которое поможет более осознанно работать с yii, codeigniter ...etc. Хотелось бы, чтобы провели за руку от ООП и MVC до понимания основ фреймворков. Чтобы не вгоняли в ступор строки «Объект приложения (application) инкапсулирует контекст выполнения запроса. Основная задача приложения — собрать информацию о запросе и передать её соответствующему контроллеру для дальнейшей обработки. »

Спасибо, что прочитали.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В гугле не забанили?
Паттерны проектирования в PHP

Для начала — не стоит писать «фрамворк» — сильно опускаете планку у отвечающих, даже подсознательно. просто означает, что вы _ничего_ не читали, а тут же вякаете «хелп, хелп»

Дякуйте б-гові, що не «фреймовік», адже подібне знущання над мовою хоч і не часто, проте також можна побачити/почути ))

Во-первых, я никому не хамил и не желаю, чтобы словечки типа вашего употреблялись в мою сторону. Во-вторых, как можно заметить в тайтле поста и на русском слово я пишу верно, а значит упускаю буквы, когда печатаю. 130 комментариев это никому не мешало, а тут внезапно появились вы с «дельными советами», вы — избранный, поздравляю. В-третьих, я не нуждаюсь в советах человека, единственный топик которого содержит следующую фразу: «Реально ли вернуться на фриланс с ЗП около 600 долл?». Для вас — не реально. Будьте вежливее и умнее и не стоит показывать свой обалденный скилл и отправлять в гугл. Судя по всему вам учиться стоит поболее, чем мне. Успехов, фрилансер.

Вы правы целиком и полностью. приношу свои извинения, был неадекватен

Про основы MVC мне кажется очень удачной документация из симфони2
symfony-gu.ru/...o_symfony2.html

Мені з MVC і ООП допомогло ось це proglive.ru/courses/php2 Стисло, структуровано, професійно, швидко і якісно. А потім вже й документації по фремворкам не будуть такими страшними.

1 вибрати ком’юніті, бажано локальне, щоб вживу можна було з людьми познайомитись.
2 почати використовувати в старому процесі розробки компоненти обраного фв, тим самим вдасться відчути практичну різницю
3 спробувати переписати свій власний код під фв, з використанням його інструментів.

Це дозволить безболісно вивчити нове і, як не дивно, покращити фукнціональне програмування

В свій час починав вивчати ООП з наступних книг:
* Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес — Приемы объектно-ориентированного проектирования. Паттерны проектирования
* Зандстра Мэтт — PHP. Объекты, шаблоны и методики программирования. — 2010

Вы думаете что человек который не понял эту строку:

«Объект приложения (application) инкапсулирует контекст выполнения запроса. Основная задача приложения — собрать информацию о запросе и передать её соответствующему контроллеру для дальнейшей обработки. »
Постигнет ООП читая «Паттерны от GoF»?)))
Если уж сразу во все тяжкие без понимания ООП изучать паттерны и подходы, то ИМХО лучше будет:
Тоже не так давно столкнулся с такой-же проблемой. Рекомендую www.ex.ua/16950335
Эрик Фримен, Элизабет Фримен. Паттерны проектирования. Только после ознакомления, начал понимать возможности ООП, ну и соответственно стало легче разбираться с фреймворками.

Тоже не так давно столкнулся с такой-же проблемой. Рекомендую www.ex.ua/16950335
Эрик Фримен, Элизабет Фримен. Паттерны проектирования. Только после ознакомления, начал понимать возможности ООП, ну и соответственно стало легче разбираться с фреймворками.

в свое время мне очень помог сайт dbhelp.ru где человек расписывал азы по работе с yii. Единственным минусом этого ресурса было то что примеры там были для версии 1.0.х, а не 1.1.х в связи с чем были некоторые моменты несовместимости. но в комментариях там можно было найти решение возникающих проблем
хочу заметить что yii мне принес глубокое понимание ооп и мвц. конечно первых пару проектов были далеки от хороших приложений, но тем не менее они работали. сейчас написание кода на фреймворке приносит просто удовольствие, особенно когда много велосипедов уже придуманы и встроены в ядро.
теперь от написания собственных класов реализации полиморфизма и прочих оопшных фишек просто получаешь оргазм
отмечу что порог вхождения был труден без знающей поддержки, так что я бы вам порекомендовал найти наставника. с другой стороны у меня есть много знакомых, которые в упор отвергают написание кода с помощью фв и свято верят в свои велосипеды. но недостаток гибкости этих велосипедов со времени приводит их к коду похожему на код фв. так что я поддержу ваше стремление начать этот путь. так же могу предложить посильною помощь, так как временем особо не располагаю, но просветить в некоторых моментах могу.
Удачного девелопмента
ПС: ни в коем случае не хочу обидеть приверженцев других фв, но после yii, мне не хочется пробовать что-то другое. хотя ради спортивного интереса посмотрел бы на симфони(2), ларавел и фалкон.

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

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

Люди делятся на две категории: те, кто понимает шутки на религиозную тему и те кто попадет в рай. :D
Laravel — круто?

Я не РНРшник, но мне этот фреймворк понравился. До этого работал с Zend и CodeIgniter.

Laravel это как Yii, но более свежий что ли.

там частично на Symfony2, судя по зависимостям.

Laravel это вообще сборная солянка :) Есть ядро + что-то свое + что-то чужое и хорошее

На Symfony Components, если быть точным.

Laravel относится к тем немноголичисленным фреймворкам, которая не ограничивает жестко структуру проекта. Что не очень хорошо в отсутствие ментора(можно нахвататься плохих привычек), но отлично для быстрого старта:
можно даже забить на MVC и запихнуть весь-весь код в routes.php с использованием queryBuilder’a для запросов из БД, а затем постепенно выносить все в отдельные уровни: контроллеры, модели ORM, шаблоны, фильтры и пр.

Kohana, вот тут всё по шагам расписано: kohanaframework.su. Обратите внимание, по ссылке информация для версии 3.2, последняя версия 3.3 несколько отличается. Но я не вижу трагедии в том, чтобы использовать 3.2. Но чтобы понять, как работать с фреймворком (понимание того, как работает фреймворк — отдельная тема, оно может прийти только по истечению большого периода времени) — нужно сразу с ним работать. Хотя бы поднять простой сайт, просто пошагово делая то, что написано в разделе «для начинающих».
По ООП — соответствующий раздел какого-нибудь учебника по программированию прочесть.

OOP & MVC не сложные понятия, забудь все про wp и прочти www.amazon.com/...ted programming
должно помочь

забудь все про wp
Выкинь 5 лет жизни из головы.
Скорее не забыть, а понять MVC и соответственно понять, что так удобнее.

За более, чем 25 лет в IT я пришел к выводу, что новомодные тенденции, хотя и призваны облегчить задачу построения сложных систем, не на каждый образ мышления органично ложатся. Сам въезжал в ООП довольно долго. Главный вопрос был тогда — ну ладно, идея понятна, но — ЗАЧЕМ? Лет за 10 пришел к выводу: А ИНАЧЕ — КАК? А теперь уже 10 лет пытаюсь уложить в голове MVC. Получается не очень. К сожалению, современные программисты часто связаны по рукам и ногам в выборе технологий, парадигм, фреймворков, зачастую противоречащих устройству их мозга.

А что не получается-то? Разделение логики обычное: модель — бизнес-логика, вьюха — интерфейс, контроллер — связывает всё это (плюс хранение, безопасность и т. д. ) в единое целое.

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

Скорее просто что-то в голове ещё не щёлкнуло. У меня такой щелчок произошёл, когда начал изучать Symfony 2 c Doctrine 2 (ещё в альфе) — позже понял, что раньше мешал щелкнуть паттерн ActiveRecord, широко используемый в других фреймворках. С ним грязность обращения к БД в шаблоне или модели в глаза не бросается.

Я давно занимаюсь разработкой на WordPress, отлично знаю кодекс, пишу небольшие плагины, но функциональным программированием соответственно на PHP.
Рекомендую все же загуглить — «функциональное программирование»

*структурное конечно-же. Прошу прощение.

Да, процедурный подход и ФП — разные вещи. Но для начинающего такая оговорка — не смертный грех, все нормально :)

на мой взгляд нужно разбираться в таком порядке:
1. основы OOP — что такое класс / объект / наследование / инкапсуляция / полиморфизм и тп. Наверное можно просто почитать соответствующий раздел доки к пхп — php.net/...nguage.oop5.php
Если какие-то вещи кажутся пока слишком абстрактными — не переживай, со временем поймёшь

2. Далее читаем книгу по паттернам GoF-а: «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» — «Банда четырёх»: Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидс. Это простенькие шаблоны написания классов, которые так или иначе применимы ко всем языка. Если какой-то паттерн непонятен — можно гуглить по словам php + имя паттерна — наверняка найдёшь статью c более понятными примерами

3. Более высокоуровневые паттерны, часто используемые в web-фреймворках, найдёшь в книге Мартина Фаулера «Архитектура корпоративных программных приложений». По-моему многие web-фреймворки просто написаны по паттернам из этой книги.

честно говоря гофа нужно читать хорошо понимая ооп, и очень аккуратно. потому как без него жить можно. просто иногда получается что использование паттернов просиходит подсознательно. именно этот подход работает у меня. а когда человек просто начитается всяких гофов и начнет их пихать куда надо и не надо — будет беда
я бы порекомендовал для начала почитать Мэт Зандстра «ПХП. Объекты. Шаблоны». Там очень доходчиво объясняется зачем нужно ООП и как этим пользоваться

Посмотри видео-курс от «Специалиста» раздел php по моему 3 и 4 части как раз ООП + в конце они пишут+рассказывают+ты_за_ними_повторяешь свой мини mvc фреймворк. После этого ты поймешь как оно работает — зайди на сайт зенда1, скачай и сделай по ихнему тутору сайт. MVC как и любой паттерн — банальщина простая(из которой каждый второй пытается раздуть о*уительно сложную систему которую не всякому дано понять), главное найти инфу без мусора,

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

там вообще мини-версия, просто наглядно разделяют логику от представления и показывают как в зависимости от урл(controller/action) подгружаются нужные части. Это «побольше времени» там занимает часа 3 со всеми объяснениями, зато появляется понимание хоть как оно в общем работает + помогает разобраться в ооп.

После этого ему всё равно нужен будет полноценный фреймворк для работы. И сразу возникнут вопросы:
1) А где тут хранить модели/контроллеры/виды?
2) А как правильно называть классы?
3) А как обратиться к БД
Снова ситуация «не понимаю ничего», только подкреплённая знанием структуры простейшего фреймворка, который для работы никто не применяет.

Для этого я и писал «потом зайти на сайт зенда(или любого фв) и сделать по тутору...». Там будет все ваши 3 пункта и ещё 150 сверху. Видео просто что бы быстрее въехать. Меня когда взяли на работу — ответом на вопрос
-"какой ваш опыт работы"
был
-"позавчера делал тестовое задание для другой конторы, вчера его сдал и завалил собеседование, это был мой самый большой опыт :D".
Первый же проект был на зенде1, вообще с нуля, и мне это видео(я его смотрел, повторял и как вы говорите "

потерял побольше времени
" во время обучения php примерно за месяц до того как начал собеседоваться) реально помогло за пару дней освоить зенд и начать хоть что-то делать.
Вы до конца читайте, или вам лишь бы покритиковать?

Та до конца я читаю. Вы предлагаете попробовать написать на чистом пхп мини-фреймворк, чтобы понять, как оно вообще работает. Я предлагаю отложить понимание «как оно вообще работает» на неопределенный срок и просто использовать инструмент, руководствуясь инструкцией к нему. Это как с дрелью. Чтобы сверлить — нужно знать какой режим применить для конкретного материала и где кнопка включения. А как она внутри сделана — абсолютно неважно, пока не стоит вопрос «отремонтировать дрель».
Понять например, как работает Database_Query_Builder_Insert в Kohana — это разобрать работу минимум трёх классов, от которых он наследуется. И результат исследования будет полезен только в двух случаях:
1) Если копающий хочет расширить возможности фреймворка (например, реализовать поддержку replace)
2) Если копающий хочет написать свой фреймворк
А просто разобраться как данный класс работает — так всё равно мозг забудет эту информацию за ненадобностью.
С таким же успехом можно перед изучением php изучать как написан сам интерпретатор. В работе не сильно поможет, время отберёт, мысли спутает.

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

Сначала полгода изучать как работает фреймворк, потом писать? Тогда фреймворк не нужен, пишите на чистом php.

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

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

В трёх-пяти предложениях — это именно магический черный ящик.

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

Имеется в виду ограниченный круг технологий с общим «знаменателем» типа MVC-фреймворк на PHP. Один раз изучив как работает PHP и как работают MVC-фреймворки, эти знания будут использоваться снова и снова.

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

Аналогия с дрелью не совсем уместна, потому что у дрели очень простая функция («делать отверстия»), которую достаточно тяжело выполнять без неё (пальцем или гвоздём). Yii (symfony2, kohana, подставь своё) — это штука, профиты от которой совсем не очевидны и которая абсолютно НЕ незаменима (всё что можно сделать на yii, можно сделать на чистом php).

Если плюсы фреймворка для программиста не очевидны (но при этом он слышал о таких штуках) — значит пока что он программисту не нужен. Задолбается с кучей повторяющихся mysqli_ функций — додумается до обёртки к БД. Надоест выискивать баги в HTML+PHP — узнает про шаблоны. А там и до MVC недалеко.

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

Аналогия с дрелью не совсем уместна
чого ж, якраз навпаки:
щоб зробити одну дірку для себе, як вийде — достатньо знати що дрелькою можна робити дірки, і де вона лежить.
щоб професійно робити дрелькою дірки — треба досвід з нею, розуміння як вона працює, і власні напрацювання підходів, щоб не тільки швидко і надйно сверлити дірки, а ще і знати що робити, як впрешся в якусь проблему чи поламається :))

Всё он (Виталий Мартыненко) правильно пишет.

Написать свой микро-фреймворк — это идеальный способ понять «нахрена этот yii (symfony2, kohana, подставь своё) нужен и в чём именно он может упростить мне жизнь».

И сразу возникнут вопросы:
1) А где тут хранить модели/контроллеры/виды?
2) А как правильно называть классы?
3) А как обратиться к БД
Вот! Именно этого мы и добиваемся, чтобы и ТС возникли такие вопросы. Ведь если у человека возникают такие вопросы, то он может просто зайти на сайт yii (symfony2, kohana, подставь своё) и прочитать ответы. Гораздо хуже (offtopic: на самом деле лучше, но для программиста-практика всё таки хуже), когда у человека возникают вопросы: «а зачем вообще эти модели, контроллеры, виды? нахрена всё так сложно? не лучше ли как раньше лепить всё в index.php?»

ТС уже, вроде бы, понял что не нужно всё лепить в index.php

Я понял, что в мире WP лепить все в index.php это правильно, но есть более удобный и продуманный MVC, чтобы ощутить удобство нужно его (MVC) понять. А в данном, конкретном случае я решил смотреть в сторону фреймворков поскольку текущий проект будет использовать от возможностей WP очень малую часть. Львиная доля функционала проекта подразумевает достаточно масштабную кастомизацию WPшки именно по этому я решил, что логичнее писать конкретно под проект, а не городить костыли на движке.

У меня был небольшой проект на ВП, мы всю логику разбили по клаcам, сделали что-то типа partials(ob_start ob_end с своим класом) для повторяющихся кусков, в общем сделали более менее красиво. В functions осталось только лоадер класов и чуть хлама для админки,acl. Было бы желание — можно и wp сделать таким — что бы при просмотре кода не дёргался нервно левый глаз :D

Не модифицировал ни разу WP, не знаю как там принято. Но для нестандартных проектов CMS не подходят (видел и дорабатывал ModX с кучей доработок — больше не хочу). Фреймворк — правильный выбор.
Насчёт MVC. Это не супер-технология, которая спасёт мир. И не какой-то волшебный код. Это паттерн проектирования. Сводится всё к тому, что для каждой веб-страницы существует три файла: контроллер, модель и вид. Самое простое — это вид. Это шаблон, который получает от контроллера какой-то набор переменных. Может использоваться шаблонизатор, а может и просто . В нём не должно быть логики. Максимум — это условия, если какой-то части контента может не быть, и циклы, если нужно вывести таблицу. Модель — это класс, работающий с данными. Получить данные из БД, сохранить данные в БД. А контроллер — связующее звено между видом и моделью. В контролере нужно вытянуть данные из POST, проверить их, при необходимости отдать модели для сохранения, спросить у модели данные для отображения, передать их в вид и этот вид отправить в виде ответа пользователю. Ещё в MVC-фреймворке есть роутер, который по URL и правилам (прописаным в конфигурации) определяет какой контроллер вызвать. Вот и весь MVC. Понимать каждую строчку фреймворка не нужно. В мануалах будет написано, в каких директориях что хранить, как называть и как задавать настройки роутера. Что ещё есть приятного в фреймворках, кроме MVC — это различные обёртки для работы с БД, которые делают последнюю безопасней и удобней, а также классы-помощники, которые делают разные полезные вещи. То есть фреймворк — это php + некоторое количество вспомогательных классов. Поэтому фреймворк удобен для нестандартных проектов.

В заблуждение вводите:

>>Самое простое — это вид. Это шаблон, который получает от контроллера какой-то набор переменных.

Самое неопасное заблуждение — шаблон это не вид, а его часть. Причём не обязательная :)

>>Модель — это класс, работающий с данными. Получить данные из БД, сохранить данные в БД.

Самое опасное (наверняка используете фреймворк с AR ORM). Персистентность данных ответственность не модели, а контроллера и (его) сервисов. Модель реализует чистую бизнес-логику и ничего не знает о том, где и как данные хранятся. Схема работы типичного update-контроллера (наиболее сложного):
— создать в памяти фрагмент данных модели, достаточный для обработки запроса, получив данные из хранилища и внешних сервисов;
— вызвать нужный метод модели — этот метод должен только изменять состояние модели, но не данных в хранилищах, и получать из них дополнительно ничего не должен
— сохранить результаты
— передать результаты в представление.

Самое неопасное заблуждение — шаблон это не вид, а его часть. Причём не обязательная :)
Приведите пример вида, которму не нужен шаблон. Речь о вебе.
Самое опасное (наверняка используете фреймворк с AR ORM). Персистентность данных ответственность не модели, а контроллера и (его) сервисов. Модель реализует чистую бизнес-логику и ничего не знает о том, где и как данные хранятся.
Нет, я использую Kohana 3.2, без ORM (фреймворк ORM поддерживает, но я не вижу в ORM преимуществ). И модель как раз очень даже знает что и где хранить. А если перекладывать в вебе хранение на контроллер — то ничего путного не получится, основной код будет в контроллере. Тогда можно и не разделять ничего.

Вам же Владимир черным по белому написал —

Персистентность данных ответственность не модели, а контроллера и (его) сервисов
Контроллер делигирует функции удаления / создания / обновления сервису, делая тем самым модель независимой от источника данных.

Извините, я не теоретик. Перебрасывание книжными определениями — не моя сильная сторона. И я за то, чтобы программировать ради результата, а не ради красоты, накручивая 10 уровней абстракции. И то, что Вы называете «сервис» — это как раз лишний уровень.

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

Тем не менее, если в шкафу будет коробка «нешлифованый рис», в которой будут пачки «рис от поставщика 1», «рис от поставщика 2» — это будет излишним. Делить на классы нужно всегда до разумного предела.

Отчего же? Рис от поставщика-2 может готовиться например 45 минут, но стоить дешевле № 1, который готовиться в два раза быстрее. И повара могут балансировать, какой им использовать, в зависимости от тайм-слота, выделенного на подачу блюда.

Представьте, что он не отличается :)

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

>>Приведите пример вида, которму не нужен шаблон. Речь о вебе.

Возврат объекта или ассоциативного массива в виде JSON или XML.

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

Если приложение уровня простейшего CRUD, просто веб-морда к таблицам БД, то, да, модели будут пустыми, просто структуры данных. А основной код будет в контроллере или сервисах, который он вызывает. Но если что-то сложнее, то вы начинаете в модели смешивать бизнес-логику и логику хранения, что ни к чему хорошему не приводит в перспективе. Даже если вам не придётся менять систему хранения.

Обычно в контроллере прямо никто не пишет код доступа к бд, а используют абстракции. Лучше читать Мартина фаулера чем википедию о том какие есть способы работы к бд.

Именно. Типичная ошибка: «В результате код моделей по факту является средством получения данных из СУБД, а контроллер представляет собой типичный модуль, наполненный бизнес-логикой, или скрипт в терминологии веб-программирования.»

Должно быть ровно наоборот — средство доступа к БД/файлам/внешним сервисам в контроллере (возможно вынесено в сервисы хотя бы в силу DRY), а бизнес-логика — в модели. Обычно бизнес-логика не оперирует понятиями типа «таблица» или «файл», и операциями типа записи в них, а оперирует понятиями типа «документ», «изображение», «деньги», «счёт» и т. п. и операциями типа создание, проведение и т. д., абстрагируясь от способа хранения.

Зачем писать свой фреймворк? Чтобы потерять побольше времени?
Чтобы попробовать...

Попробовать в жизни всё?

Написание велосипедов в данном случае, а именно какая-никакая практика — лучшее усвоение материала. Через это почти все проходят и это не трата времени впустую, а трата времени на самообучение.

Говорят, любой опыт важен. Но всё-таки мне кажется, что можно расходовать время и силы более рационально. Тем более, ТС вроде бы не первый день PHP видит и ему нужно заказ выполнять.

Согласен. Но попробовать на досуге написать простой ФВ, хотя бы по тутору — это приятно и полезно :)

нада ждать пока кто то из недавно обучившихся прийдет. Я недавно гдето то встречал хорошее описание счас попытаюсь найти. Вначале нада в ООП вникнуть, потом можна в МВЦ углубляться. У меня самого с наскока не вышло осилить ни кодеигинитер ни yii ги кохану. Вернее почитал немного, и стало понятно что для изучения нада пилить какойто проект, иначе все забывается через неделю. Вот эта статья мне понравилась, в ней доступно все описанно для симфони
symfony.com/...o_symfony2.html

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

Получается опять выдирание информации по кускам с разных источников. Просто я думаю, что эта тема очень популярна и должен быть ресурс, где описан путь от и до. От объяснения ООП до разработки простого приложения с паттерном MVC.
Вот сейчас играюсь с разделением логики и вьюшки в своем плагине wordpress, в качестве шаблонизатора использую сам php, но все равно упорно пытаюсь свалить логику и вьюшку в одну кучу, как это принято в самом WordPress. А если к этому добавить еще и ООП с созданием объектов представления и т.д., то вообще теряюсь.

свалить логику и вьюшку в одну кучу, как это принято в самом WordPress
/facepalm

Эээх... в родной ВПшке нет ни контроллеров, ни вьюх, а есть index.php, header.php, page.php ...etc. После 5 лет работы с WP это настолько привычно, настолько въедается, что кажется самым верным =) Ну будем исправляться. Когда-то надо начинать.

echo во вьюхе бить себя по рукам
Фреймворки, вместе с упомянутым Yii, смотрят на Вас с недоумением.

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

echo also has a shortcut syntax, where you can immediately follow the opening tag with an equals sign.
php.net/...nction.echo.php

Такое вообще говорить нельзя)

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

следует отличать бизнес-логику , которой во вьюшке действительно не место и логику страницы место которой именно во вьюшке.
www.earlyorke.com/...tivators2-3.jpg

Нормально в вебе MVC, только нужно понимать, что вьюха это не тупо шаблон, а в том числе клиент (браузер).

если бы «нормально» не было бы по форумам столько топиков с проблемами понимания и вопросами что должно быть в контроллере что во представлении что в модели.. На десктопных приложениях, для которых собственно MVC был придуман много лет назад, проблемы понимания нет. Потому как там оно понятно и логично.
Дмитрий Котеров, кстати , в своей известной книге по этому поводу целую главу выделил — и вполне понятным языком показал что компонентный подход для веба более естественнен чем MVC. Имеется ввиду конечно не сама общая идея отделения представления от бизнес-логики а реализация MVC паттерна которую придумал Zend Framework а остальные тупо собезянничали.

Думаю, как раз проблемы у тех, кто относится к веб-приложению как к серверу, выдающему html-код, а не к распределенному приложению.

Реализация Zend образцовой или начальной, имхо, не является. Многие разработчики фреймворков смотрели прежде всего на рельсы.

вообще то браузер не понимает ничего кроме HTML кода
посему да — это приложение которое выдает HTML код
конечно если яваскрипт что то нарисовал на canvas то формально как бы сервер и Html тут ни при чем. Но сложно представить себе такого рода прикладные приложения а не игрушку

Понимает — например, нажатие пользователем кнопок и ссылок. И его реакция (управляемая разработчиком) на эти нажатия — часть логики представления.

веб-приложению как к серверу, выдающему html-код
Веб-приложение скушало Request и сплюнуло Response. Так работает веб, а точнее клиент-серверные приложения.
Symfony и Фабьен настойчиво (и уместно) напоминают об этом.

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

В Симфони MVC как-раз и нет.

Фабьен настойчиво (и уместно) напоминает об этом.

Это не веб-приложение, а только его бэкенд, серверная часть. Да, можно разрабатывать бэкенд, не зная html и js, но это не будет разработкой приложения. О какой разработке приложения может идти речь, если разработчик не знает какие действия доступны пользователю? А он не знает, если не понимает, грубо говоря, что в html отдаёт гиперссылки и формы, не говоря о сложных js-конструкциях. И это даже в идеальном приложении, где применим REST в чистом виде. Максимум в таком случае можно говорить о разработке бэкенд-части приложения по спецификациям фронтендеров.

Да что Вы, разве не может вернуться Response с хтмл-тегами и 200-ым статус кодом?

Интересно, а как по компонентному подходу происходит авторизация, валидация, дессереализация данных отправляемых с клиента, тоже во вьюшке?

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

А почему нет? На WPшке походу как раз так и получается. Ведь доступа к php файлам никто сторонний не имеет. Что может быть плохого, если я проверю валидность того же пароля в index.php, а потом в этом же индексе сгенерирую html? Если я что-то не так понял, простите мое дилетантство.

это критически плохо для больших приложений, потому что нет разделения ответственности, код нетестируемый неочевидный, трудно читаемый и несопровождаемый. В попытках исправить ситуацию вы начнете придумывать свою систему модулей, в попытках переиспользовать, начнете эти модули дробить и структурировать. В конечном счете прийдете к тому, что использование единого pipeline для обработки всех http запросов к сайту без гибкой системы роутинга не то. Сайт хоть и будет разбит на модули будет тем не менее попрежнему сложным и несопровождаемым. Прямопропорциональну росту сложности начнет проседать производительность и расти сложность добавления новых фич. Это и будет тот этап, когда начнете понимать почему MVC. И что все ваши попытки решить проблемы были направлены на изобретение того самого «колеса», которое предлагает MVC.

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

что именно из списка относится к Бизнесс операциям? Парсинг даты на основании локали полученной от браузера, преобразование параметров пейджинга из урл, выбор режима валидации:частичная валидация модели для patch и полная для put? Список можно продолжать бесконечно долго. С таким подходом модели станут еще более уродскими и менее тестируемые чем вью.

Бизнес операции — те которые работают с бизнес-данными. очевидно что URL и номер страницы - не бизнес данные.
и как вопрос тестированя относится с обсуждаемой теме?

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

в этом и проблемма — МВЦ используют не там где нужно.
И кстати обработчик кнопки как раз контроллер — или что по вашему контроллер должен делать? и кто должен обрабатывать кнопку? Представление? а на фига тогдпа контроллер.
вот видите какая фигня получается. А ведь суть патернов как раз предоставить четкую типовую модель поведения в типовых задачах (как например нажатие кнопки и реакция на это системы).

.

Задача контроллера подготовить модель из текстового хттп запроса выполнить над ней Бизнесс операцию и передать ее в нужное представление. А не выносить в контроллер логику взаимодействия пользователя с ui. Просто и понятно, это не проблема паттерна, что кто-то не умеет мыслить абстрактно, а все понимание веба ложиться на хтмл файлик, для которого надо написать все возможные обработчики в одном месте, чтоб не получить разрыв шаблона и не запутаться

в текстовом запросе нет никаких моделей. А взаимодействие пользователя с UI — это и есть задача контроллера. тем более что UI в вэбе взаимодействует именно HTTP запросами.

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

----
Смотрите как выходит, есть инструмент мы его используем по разному, для меня он полезен, вам нет. И вы уперто продолжаете спорить, что понимаете его лучше. Вы действительно считаете что знаете что такое мвц?)

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

Там точно моделей нет. Модель — это код. Вы же запросах php-код не передаете? В запросах могут быть данные, с которыми работает код модели, а может и не быть, скажем запрос GET /user/1 не содержит данных модели в общем случае — контроллер решает данные какой сущности передать.

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

Передача состояния модели в http-запросе скорее исключение чем правило (кажется MS очень любила гонять туда-сюда чуть ли не всю базу данных в ASP .NET, но потом отказалась от этого подхода, перейдя к ASP .NET MVC). Обычно передаются запросы, состояние одной сущности изменяющие (без учёта логов безопасности, статистики и т. п.), и получающие ответы, представляющие какой-то срез состояния множества сущностей.

МС передавала состояние каждого элемента управления на странице в веб формах, это не состояние модели.

Обычно передаются запросы, состояние одной сущности изменяющие (без учёта логов безопасности, статистики и т. п.), и получающие ответы, представляющие какой-то срез состояния множества сущностей.

Логи и статистика никак не относиться к текущему состоянии модели, для которого выполняется http действие, если она это не подразумевает первоначально.

И теперь еще более интересный вопрос, откуда в нормальной реализации веб-приложения берется состояние модели, если http протокол лишенный состояния, а:

Передача состояния модели в http-запросе скорее исключение чем правило
?

----
или если же

состояние одной сущности

отличается от того, что представляет из себя состояние модели в MVC. Я бы послушал чем именно.

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

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

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

Но если, например, он видит только агрегированную статистику, то это не значит что внутри приложения модель не работает с отдельными сущностями.
Значит скорее всего агрегированная и видимая пользователю статистика и есть моделью, пусть и read only. Я не думаю, что при запросе в контроллер GET report/1 целесообразно передавать во вью несколько массивов табличных нормализированных сущностей, которые потом трансформировать в агрегаты или вызывать во вью методы модели, которые обратяться в бд и выберут оттуда агрегаты. Называть это моделью тоже врядли кто-то будет.

Ну отчего же нецелесообразно? Внутри приложения имеем некую типизированную коллекцию сущностей с полями Value1 и Value2. У коллекции имеем методы типа getAverageValue1, getMaxValue2 и т. п. Как эти методы будут реализованы, это уже вопрос оптимизации.

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

Вот именно, что на определение форма представления не влияет и в общем случае пользователь не взаимодействует с моделью напрямую, не задаёт её состояние явно в сериализованном или ещё каком виде, а через кучу слоев дергает методы модели его изменяющие. Явное задание свойств модели в, например, форме — лишь частный случай. И даже если в модели User есть метод setName(), а в форме есть поле name, но этот вовсе на даёт основания думать, что в модели есть поле name, а в базе есть таблица user с колонкой name.

Как бы задает. Может сейчас в пхп взаимодействуют с сервисами как то иначе чем посредством json или form data отправленных с клиента, которые ложатся на аналогичную структуру класса конкретного языка. Если так, расскажите как иначе. Что за абстракции и путающие дто используют и для чего. И почему вы в веб моделях оперирует моделями отражающую структуру бд.

Ложится на аналогичную структуру, но к модели она не имеет прямого отношения. Эта структура знает как отмапить себя на модель. Так же как ORM знает как отмапить себя на модель. Часто маппинг осуществляется 1:1 путем выбора структуры запросов и схемы БД максимально близко к модели, но это частный случай и, опять же, все остальные подсистемы подстраиваются под модель, она в их явных (пускай и не очень в виде магии фреймворка) зависимостях.

Модель же ни знает ничего ни о веб- или иных запросах, ни о базе данных или иной системе хранения, ни о контроллере, вообще ни о чём кроме предметной области. Внешние зависимости у неё могут быть только на уровне библиотек, реализующих какую-то функциональность предметной области. Это, конечно, в идеале, на практике это сплошь и рядом нарушается по разным соображениям, но эти нарушения должны быть обоснованы, а не «скопипастили из предыдущего проекта, зачем нарушалось никто не помнит, но точно работает».

Обработчик кнопки как раз вьюха. Просто вьюха это не html, и даже не шаблон, а весь комплекс от какого-нибудь класса AbstractView до браузера и даже ОС.

тогда что делает контроллер если даже команды о пользователя обрабатывает представление? И с какого перепугу оно их обрабатывает?
Удивительная каша у вас в голове.
В паттерне неважно как закодировано представление — важно что оно делает.

Представление преобразует действия пользователя в команды контроллерам (выбирая необходимый в данном контексте). Если брать обычный веб, то представление преобразует, например, клик пользователя по ссылке в вызов метода контроллера, обернутый в http-запрос и API сервера. Если брать, например, десктопное приложение, то представление преобразует тот же клик в непосредственный вызов метод контроллера. Если брать классическое клиент-серверное приложение, то представление преобразует тот же клик во что-нить типа RPC, dCOM или CORBA. В целом, одна из задач представления — приведение действий пользователя к API контроллера. Контроллеру должно быть всё равно, дернули его кликом по ссылке, выбрали в меню, нажали хоткей или набрали адрес в адресной строке. И задача представления обеспечить это.

Підписатись на коментарі