Комментарии 62
Написать про MVC меня сподвиг именно тот факт, что понимание этого паттерна является ключевым в становлении программиста.
Э, серьезно? А аргументировать?
Если коротко, то MVC (model view controller) это такой способ написания программы, когда код отвечающий за вывод данных, пишется в одном месте, а код который эти данные формирует, пишется в другом месте.
Это, на минуточку, называется Separated Presentation, и MVC — только один частный случай.
(и я даже не буду вдаваться в нюансы того, какие именно MVC бывают)
С бизнес-логикой определились, пишем в контроллерах.
Смешно вы определились, да. А на основании чего? А то, что бывает доменная модель и доменные сервисы, вы не слышали?
Конечный результат отправляется в виды. Виды cодержат HTML-разметку и небольшие вставки PHP-кода для обхода, форматирования и отображения данных.
Вообще, это называется "представление".
Ещё можно упомянуть, что есть два вида MVC Page Controller и Front Controller.
Откуда, стесняюсь спросить, вы взяли эту классификацию?
Ну и да, где полное описание паттерна-то? Что с чем взаимодействует, зачем, и все вот это вот?
Нее, понимания после вашего поста не будет, будет только еще одно "я тут написал что-то под названием MVC".
Ну не слышал человек ни разу ни про драйвера, ни про системные сервисы, где View не может быть в принципе (ибо _не_нужно_). Ну бывает, чо уж.Написать про MVC меня сподвиг именно тот факт, что понимание этого паттерна является ключевым в становлении программиста.Э, серьезно? А аргументировать?
А касаемо самой статьи — объяснения по сути никакого, код на первый взгляд неплохой, за исключением парочки сомнительных мест:
index.php
define('ROOTPATH', __DIR__);
require __DIR__.'/App/App.php';
В папке Views/Layout создаём Layout.php:Ах, ну да, ну да.
... <div class="copyrights"> 2017 Жуков Глеб(gotlib)<br> При копировании материалов на сторонние ресурсы, ссылка на http://www.gotlib.info обязательна! </div> ...
Какая такая причина пихать исходники в доступную из WWW директорию?Отвечу сам себе: «чтобы любопытные смогли пошариться в структуре вашего сайта»:
- http://www.gotlib.info/App/
- http://www.gotlib.info/App/Exceptions/
- http://www.gotlib.info/App/Recaptcha/
- http://www.gotlib.info/App/Kernel.php
- ...
Фу так делать.
В тех фреймворках, которые знаю я (yii, laravel) логику пишут в контроллерах, а модели являются просто экземплярами ORM (почитайте про паттерн Active Record). У yii кстати в мануале написано, что писать логику надо в моделях, а потом они сами в примерах пишут её в контроллерах, довольно забавно.
Очень был бы благодарен за указания на конкретные места в гайде Yii, которые:
- Рекомендуют писать логику в контроллерах.
- Показывают логику в контроллерах (скорее всего ради упрощения сделано).
- Рекомендуют писать логику в Active Record или намекают на это.
- Говорят, что AR === модель.
У меня, как автора довольно значительной части этих текстов, развилась слепота на ошибки :(
А вообще вот что я об этом думаю: https://github.com/samdark/yii2-cookbook/blob/master/book/mvc.md
Есть такая тема про толстые контроллеры/модели и этому в значительной части подвержен именно yii. Но в этом виновата не документация, а огромное число проектов с такими подходами. Я даже видео по фреймворку видел, где делают именно так: логику пишут в контроллере, а модели максимально загружают различными вызовами. Еще и минус php как шаблонизатора (1-й yii), вставить виджет на страницу, а перед ним код прямо в шаблоне.
Раз у вас есть опыт написания статей, м.б. написать статью с примерами хороших подходов: соблюдение PSR-ов, создание либ для помещения логики, и если рассматривать yii можно запихнуть, как хорошо организовывать конфиги и структуру папок проекта и т.д.?
Я это делаю время от времени. Недавно рассказывал в Иванове про это. Ссылки и видео тут: http://slides.rmcreative.ru/
Статьи тоже пишу, выше ссылка как раз.
что во всех подобных разговорах мне не нравится, код в первую очередь должен быть понятен. Не важно M это или нет, проблема толстых контроллеров и моделей именно в в уложении восприятия, а уж где и как, что будет располагаться это вообще мало важно, я могу в контроллере использовать приватные функции, лишь бы это было логично и понятно. А то устроили какую-то религию из этого ))
Да, всё так. К сожалению, код становится непонятным сразу по двум причинам:
- Когда его слишком много и он делает всё и сразу.
- Когда абстракции слишком много, каждая отдельная часть кода слишком проста, а взаимодействие частей слишком сложно.
Так и есть. Я где-то этому противоречил?
Типо, M — это наследник базового класса по работе с базой и этот M расширяют всяким мусором. :)
А что плохого, если простая логика будет в контроллере?
Если M ограничится ORM? :)
Так что если вы новичок и хотите начать писать программы правильно, читайте дальше.
— array_shift слишком затратная функция (извлечь + сдвинуть все элементы с числовыми индексами), вместо нее лучше обращаться напрямую через [], либо, если так уж хочется удалять элементы из массива, то array_reverse + array_pop, а конкретно в вашем примере $result=explode('/',$route,3);
— Судя по тому, как добавляются файлы через require, документация к нему прочитана не была.
— Функция launchAction накладывает ограничения на названия файлов и классов.
— Об использовании двойных кавычек вообще молчу.
ИМХО: И представленный код не для новичков с его namespace и классами. Если вы действительно хотели написать гайд, начали бы с процедурного стиля.
class Controller
{
public $layoutFile = 'Views/Layout.php';
Кол вам за тему «MVC», приходите пересдавать.
Так что если вы новичок и хотите начать писать программы правильно, читайте дальше.
С бизнес-логикой определились, пишем в контроллерах.
Одного только этого достаточно, чтобы сказать, что польза от данного текста скорее отрицательна.
Судя по коду у вас получился MVP, но без моделей.
Может люди живут в идеальном мире с только новыми и хорошо написанными проектами? Или где-то водятся в большом количестве компании, щедро бюджетирующие непродуктовые задачи типа рефакторинга?
Расслабьтесь и получайте удовольствие: в реальном мире нереальное количество говнокода. Процедурного из эпохи 5.2 и псевдо-ООП из 5.3. Чему и нужно учиться, так это как выживать среди всего этого бедлама, сводя к минимуму факапы и намазывая поверх код с новыми бизнес-фичами.
Это ваше личное мнение. Лично я уже лет 5 подобного не видел. На проде нынче только php 7+, максимум php 5.6. Совет — меняйте работу.
А что вы скажете, если разработчик придёт работать в компанию, где портал крутится на wordpress? Там и по сей день новый версии не блещут красивым кодом даже на фоне joomla.
Работу менять только из-за плохого кода считаю эскапизмом. Есть множество и других определяющих факторов.
А что вы скажете, если разработчик придёт работать в компанию, где портал крутится на wordpress? Там и по сей день новый версии не блещут красивым кодом даже на фоне joomla.
Это опять же конкретно ваши неудача, что попадались такие проекты и переходили на такие работы. За более чем 5 лет работы (может меньше, может больше, начинал во времена php 5.2) мне ни разу не встретилась та, где использовались бы какие-нибудь CMS или просто код в стиле php 4.
Да, может я излишне цинично рассматриваю этот вопрос, не учитывая каких-то факторов, но вы сами определяете где и кем будете работать. Если вам нравится работать с битриксоподобными продуктами — это ваше личное предпочтение.
Наличие подобной кодовой базы обусловлено, либо откровенно наплевательским отношением к проекту, либо технической безграмотностью специалистов. В любых случаях, работать в таких местах ради своего развития (т.к. именно это является наиболее критичным фактором для подбора любой работы) я бы не стал.
Ещё раз прошу прощения за цинизм. Но стоит развиваться, чтобы вас оценивали как специалиста, а не бежать в первое попавшееся место.
Если вам нравится работать с битриксоподобными продуктами
Хм, но какая разница, что внутри CMS или фреймворка? :)
С этим кодом разработчику работать не приходится.
А вот на якобы нормальных CMS или фреймворках программисты создают свой говнокод, с которым приходится работать другим. :)
С каждым годом ситуация с проектами становится лучше, но про вордпресс я не зря упомянул, поскольку это одна из самых популярных CMS в мире PHP на сегодня, а значит и шансы встретиться с ней велики.
На это конечно можно возразить, что подобные CMS используют только в маленьких компаниях. Ок, давайте тогда рассмотрим большие компании. В больших компаниях большие и долгоживущие проекты. Я трижды попадал в такие и во всех случаях был самописный велосипед. В одном вообще хаос и анархия, оттуда быстро убежал (2012 год). В другом (2015) вроде получше были ситуация, стали потихоньку переписывать с процедур на псевдоООП. И наконец в последней компании процедурный стиль, но хотя бы с каким-то намеком на архитектуру, но конечно же без единого теста.
Я соглашусь с тем, что на определенных этапах развития, особенно раннем, лучше сменить работу. Но когда уже есть опыт разработки и выработано чувство прекрасного, а всё остальное в работе, кроме кода, устраивает, в том числе и карьерная перспектива, то есть резон продолжать трудиться на этом месте. Впрочем это вопрос личных целей.
Начиная с года 2012го, когда я вернулся из фронт-энда обратно на бекенд — мне попадались проекты в которых не то что процедурного стиля, даже нарушений PSR не было. Покрытие тестами, согласен, все этим грешат, зачастую просто лень, работа сделана, всё работает, а дальше новые задачи. На последнем же месте работы коверейдж примерно 90%+, правда тесты функциональные, т.к. они более профитны для рефакторинга.
В любом случае наличие или отсутсвие тестов я могу принять, но подобную кодовую базу — нет, кажется что это какая-то фантастика из параллельных вселенных. Даже когда куда-то переходил и просто рассматривал какое-то место работы — всегда, если давали примеры кода, тем более примеры из реальных проектов — они были вполне вменяемыми и современными.
Единственное место на моей памяти, которое не соответсвовало этому критерию — это Кинопоиск. У них там древний php 5.3 и судя по вопросам на собеседовании — они мало стремятся это дело поправить, скорее искали разработчиков на поддержку. Так что рассматриваю это скорее как исключение, связанное с обширной неподдерживаемой кодовой базой.
В больших компаниях большие и долгоживущие проекты. Я трижды попадал в такие и во всех случаях был самописный велосипед.
Хм, я постоянно говорю, что большие компании используют самопись, а не фреймворки.
Но получаю минусов. :)
Только некоторые уже сейчас пытаются следовать моде, создавая новые проекты.
Только мне одному кажется сегодня чем-то диким заморачиваться на тему MVC и какой архитектуре/паттерну соответствует код?
Нет, не вам одному. Но людей, которым хорошая архитектура нужна, все еще достаточно.
Удачность же архитектуры определяется способностью предвидеть изменения в проекте.
Вот чтобы у код-ревью была целительная сила, рано или поздно придется заморочитсья вопросом "какому паттерну соответствует этот код".
Только мне одному кажется сегодня чем-то диким заморачиваться на тему MVC и какой архитектуре/паттерну соответствует код?
+1
Да и в повседневной разработке не нужно заново создавать MVC-каркас или использовать паттерны.
Пользуемся готовым функционалом, меняем в случае необходимости. Но не ради моды или галочки.
Расслабьтесь и получайте удовольствие: в реальном мире нереальное количество говнокода.
Да, в этом и проблема. Его слишком много. У Роберта Мартина есть неплохая теория на этот счет. Количество разработчиков каждый 5 лет удваивается. Это значит что сегодня, завтра и через год в мире половина всех разработчиков будет иметь менее 5-ти лет опыта. Что это значит? Это значит что процент людей которые понимают что откуда и куда постоянно уменьшается.
Вместо того чтобы "учить людей MVC" попути спутав все понятия в одну кучу и забыв зачем вообще все это придумывалось (а ведь придумали MVC ажно 38 лет назад) следует больше внимания уделять таким вещам как декомпозиция, функциональная абстракция, принципы проектирования и т.д. Учить писать тесты (заметьте, не TDD а хотя бы тесты).
Чему и нужно учиться, так это как выживать среди всего этого бедлама, сводя к минимуму факапы и намазывая поверх код с новыми бизнес-фичами.
Тут опять же интересный момент. Если вам досталась приложенька реализующая логику посложнее банальных CRUD операций, где все размазано по контроллерам и вьюхам, то все будет сводиться к банальной рутине и тупому алгоритму:
- посадили на пару недель QA/разработчиков написать e2e тесты на основной функционал ну и попутно разобраться как все работает
- составили приоритизацию новых фич
- делаем дела постепенно переписывая функционал
И прикол тут в том что чтобы не погрузиться еще больше в ведерко с гуано нужно хорошо знать как делать правильно. Работа с легаси это посложнее чем работа с чистого листа (свой код не так пахнет как чужой).
А вот достать дополнительно QA и тем более разработчиков — это далеко не всегда возможно. Ресурсов никто не даст просто так на рефакторинг, даже если обосновать математически выгоду в перспективе. В далекую перспективу неохотно верят, особенно в последние годы, нужны пруфы. Потратили столько денег — заработали на x% больше через год например.
А вот достать дополнительно QA и тем более разработчиков — это далеко не всегда возможно.
ну так это ж челендж для разработчика. Как с минимальными усилиями достич максимальной изоляции разработки и автоматизировать рутину на которую тратится время. Я не говорю о том что надо месяц или более чето там пилить, недельку достаточно для старта. Хотя конечно все сильно зависит от проекта, скоупа работ и команды.
Потратили столько денег — заработали на x% больше через год например.
тут тоже такой момент. Если ваш рефакторинг проекта окупится только через год — возможно вы взяли кусок непомерный. Возможно можно подумать еще, пойти на компромисы и почисть только ту часть кода которая принесет профит уже в течении месяца.
Например, у вас есть пул задач по проекту, и у вас есть регулярно пополняемый пул багов. Можно раз в недельку какую (в зависимости от того как часто обновляется пул и собирается статистика) тупо садиться и анализировать на что тратится время, в каких частях чаще вылазят баги, какого характера баги и т.д. Ну и от этого уже плясать, ибо фиксы таких проблем окупаются оооочень быстро.
то рефакторинг приносит деньги напрямую.
Есть нюанс. Для этого разработчик должен четко представлять в чем проблема и как ее исправить. Многие разработчики же просто хотят убрать то что им не нравится, и часто бывает так что с точки зрения бизнеса профита в этом нет.
В целом выделать время на рефакторинг так себе идея, а вот закладывать устранение тех долга в процесс разработки (скажем 20%) вполне себе норм.
ну как бы никто не мешает устранить критически важные проблемы для реализации фичи во время реализации фичи. В этом случае бизнес и фичу получит почти за то же время, и технический долг можно будет чуть снизить.
Разработчики любят рефакторить и улучшать свой код. Точно так же как оунеры любят генерить фичи которые не нужны. Ну то есть проблема одна и та же, плохая приоритизация, нет целей, нет таргет группы (или пула задач на ближайшее время или статистики по регрессиям чтобы оценить импакт технического долга в случае разработчиков)… Словом можно тратить намного меньше времени. Да, код не будет идеальным (как будто бы это возможно) но если поддерживать должный уровень изоляции то все будет относительно неплохо и дешево.
Сама по себе статья довольно слабая. Очень очень много информации не раскрывается. В любом случае, писать MVC самописку в 2017 году уже нету смысла. Если вас не устраивают full-stack большие фреймворки типа Symfony, Laravel, то скорее всего вам подойдут их микрофреймворки типа Silex
Интересный факт, фреймворки вроде Symfony или Silex не являются MVC фреймворками (по сути сам термин MVC фреймворк это маркетинговый булшит который начался в 2004-ом году с появлением всяких RoR).
Также стоит упомянуть тот факт, что существует два лагеря: один пишет логику в контроллерах, второй в моделях.
А я как всегда ни рыба, ни мяса… Бизнес-логику пишу в модели (сущности, объекты-значения и сервисы в основном), логику приложения в контроллерах и инфраструктурных сервисах, а логику представления вообще в шаблонах.
Простые MVC-приложения