Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
Года три назад я познакомился с отличным инструментом под названием Yii2 и стал тесно с ним работать.
Yii2 релизнулся чуть более года назад.
Ну и слишком абстрактная да и спорная статья. Ни одного примера.
Кстати, новичку я как раз советую Yii2. Просто поверьте на слово (с)
Это в стабильном релизе. Альфу и Бету никто не отменял.
Я был тем самым новичком и сейчас не очень доволен.
Я был тем самым новичком и сейчас не очень доволен.
Вы плотно начали работать на альфе версии фреймворка который каждый день изменялся без обратной совместимости?
Так, я ж указал, что начинал для обучения. Учиться на альфе как раз было интересно. Я не писал боевых проектов, а писал свой тестовый проект, и каждый раз когда что-то ломалось, я понимал все больше как устроен инструмент. Вы походу вообще статью не поняли. Смысл даже не сколько в коде, а в архитектуре приложения, которую предлагает Yii2.
Когда проект разрастается, многие моменты выходят боком. Вы либо очень хороший программист, либо не писали на Yii2 ничего сложнее блога.
Когда проект разрастается, многие моменты выходят боком. Вы либо очень хороший программист, либо не писали на Yii2 ничего сложнее блога.
Yii не предлагает архитектуры. Вообще. Никакой. Слои вы там захотите или гексагональную архитектуру или микросервисы — это ваше дело. Фреймворк и не должен навязывать архитектуру. CMS — да, но не фреймворк.
Вот тут большой вопрос. Что значит «Yii не предлагает архитектуры.»? Есть 2 часто используемых шаблона, по которым 99% сообщества работают. Может быть вы хотели сказать: что в Yii можно реализовать любую архитектуру?
эти два шаблона предлагают пример организации кода. в них например не оговорено о наследовании моделей из common в остальных частях. Т.е. там вообще не про архитектуру.
Шаблоны приложений не дают никакой архитектуры. Они не говорят вам, как именно реализовывать логику, как будут общаться разные части приложения, на сколько серверов оно будет разбито, будут ли очереди и всё такое. Положить модели в папку models — это ещё не архитектура. Это базовая организация кода.
архитектура никакого отношения к фреймворку не имеет. И это ваша ошибка как новичка. Полагать что фреймворк все сделает клево за вас. Возьми вы symfony + doctrine вышла бы та же ситуация.
Не совсем так на самом деле. В случае с symfony сообщество более квалифицированное, примеры кода и подходы более правильные, + symfony открывает глаза сразу на слоистую архитектуру вводя понятие сущностей, сервисов, репозиториев и тп.
Посетите форум Yii2 сообщества и посмотрите на примеры публикации кода. Я согласен, что можно писать хороший код на любом инструменте, но мы сейчас говорим о так сказать о большинстве.
Посетите форум Yii2 сообщества и посмотрите на примеры публикации кода. Я согласен, что можно писать хороший код на любом инструменте, но мы сейчас говорим о так сказать о большинстве.
примеры кода и подходы более правильные
Вот честно, я в опенсурс проектах видал всякого и только парочка проектов могла похвастаться чем-то хотя бы отдаленно похожим на красивую архитектуру. Есть решения на базе компонентов Symfony которые неплохи но не более.
Да, разработчики фреймворка даже вводят искуственные ограничения. Например отказ от автосвязывания зависимостей в контейнере (ну или автоконфигурации), который должен был появиться в версии 2.0. Разработчики фреймворка переживали что дав такую возможность люди перестанут делать интерфейсы и забьют на принцип инверсии зависимостей. Что по итогу и так произошло.
Посетите форум Yii2 сообщества и посмотрите на примеры публикации кода
Мне хватает примеров того что выкладывают PHP-ники в Symfony или Laravel комьюнити. Это проблема любого хоть сколько нибудь популярного решения.
это не совсем так. с декабря 2013 года (альфа) обратная совместимость нарушилась только один раз. В остальном кодовая база была достаточно стабильна (для написания проектов «для себя»).
Так ваша проблема была не в Yii, а в отсутствии опыта как такового. Дай новичку симфонию — он нагородит такого же говна, так еще и разбираться будет в несколько раз дольше.
Человек, который понимает, что такое ООП, MVC и паттерны (именно понимает, а не тупо следует их реализации в конкретном фреймворке) будет везде писать хороший код. А тот, кто этого не понимает по определению не может написать что-либо нормальное.
Человек, который понимает, что такое ООП, MVC и паттерны (именно понимает, а не тупо следует их реализации в конкретном фреймворке) будет везде писать хороший код. А тот, кто этого не понимает по определению не может написать что-либо нормальное.
Раньше я всегда двумя руками защищал Yii2 и грешил, что Symfony2 медленная, жирная, в ней много чего не нужного и тп.
Так со всеми «академическими» решениями. Так было с ZF1, так было/есть с Doctrine. В середине 00-ых сам был в этом лагере :) Оглядываясь назад, могу предположить, что в основе навешивания монструозных ярлыков лежит боязнь не осилить «слишком умный и академически правильный» фреймворк.
Я всегда называю Sf/ZF следующим этапом в развитии php-разработчика, на что многие yii/laravel-разработчики обижаются. Но это пишется не для того, чтобы вас потроллить или потешить свое ЧСВ. Это пишут люди, сделавшие этот шаг, и делящиеся опытом. Но очень важно, чтобы у этих людей был большой опыт на этом новом этапе, поэтому не слушайте людей, которые неделю покодили на Symfony и называют себя гуру разработки.
Я бы еще посоветовал не зацикливаться на php, не закрываться в этом php-мирке и веровать, что он решит все ваши проблемы. PHP сегодня не сможет соревноваться в фронтенде с js/node, с тем же go в быстродействии и т.д. Но это не значит, что надо бросать php и переписывать все свои проекты на Scala или Haskell. Важно просто смотреть в сторону совмещения/сосуществования различных инструментов. Возможно стоит почитать про микросервисы. Можно конечно считать всё это хипстотой, но если вы будете полагаться лишь на php, скорее всего вы проиграете.
Полностью согласен, щас рулит стэк из технологий. Ни один большой проект не обойдется одном php.
Что касается «Я всегда называю Sf/ZF следующим этапом в развитии php-разработчика», походу хабро-сообщество не сильно оценило мой шаг вперед =).
П.С. Zend что-то не серьезные. Обещали релизнуть zf3 еще в прошлом году и так и не релизнули походу =(.
Что касается «Я всегда называю Sf/ZF следующим этапом в развитии php-разработчика», походу хабро-сообщество не сильно оценило мой шаг вперед =).
П.С. Zend что-то не серьезные. Обещали релизнуть zf3 еще в прошлом году и так и не релизнули походу =(.
Собственно а что вам не нравится в laravel?
Есть ощущение какого-то огорода из за его модульности. Четкой позиции партии нет — для начала работы нужно обвешаться плагинами как следует, которые поддерживают стороние разработчики. Как это поведет все себя в будущем, никто не знает. yii2 как то в этом плане более серьезен.
Дело даже не в том, что поддерживается сторонним разработчиком.
Для всех этих базовых вещей приходится делать выбор.
В одной компании имеется десяток проектов на ларавел.
Для скорости их заказали на аутсорсе у разных команд.
А в штат взяли одного ларавельщика для дальнейшей поддержки этого всего.
Как вы понимаете бедный, бедный мальчик.
Там не было ни одного проекта с одинаковым набором базовых компонент.
Разные шаблонизаторы, разные RBAC…
ШЕСТЬ РАЗНЫХ RBAC! Шесть Карл!
Для всех этих базовых вещей приходится делать выбор.
В одной компании имеется десяток проектов на ларавел.
Для скорости их заказали на аутсорсе у разных команд.
А в штат взяли одного ларавельщика для дальнейшей поддержки этого всего.
Как вы понимаете бедный, бедный мальчик.
Там не было ни одного проекта с одинаковым набором базовых компонент.
Разные шаблонизаторы, разные RBAC…
ШЕСТЬ РАЗНЫХ RBAC! Шесть Карл!
Собственно а что вам не нравится в laravel?
Я тут написал целую гору текста в духе «для людей которые имеют достаточно опыта с Symfony Laravel не предлагает ничего нового» но все же пожалуй проблема не во фреймворке. Причина по которой мне не нравится Laravel я могу описать одним простым вопросом, который мне задал человек, работающий с этим фреймворком 2 года:
— А что такое dependency injection?
Ну вот как-то так. Сам фреймворк ок, но на нем легко сделать не ок, а до 5-ой версии воспринимать его серьезно я вообще не могу.
Разве не легко сделать не OK используя Symfony? Интересно, многие ли симфонисты на вопрос про DI понесутся рассказывать сходу про аннотации, контейнер и «что-то там внутри само»… я припоминаю, что когда работал на J2EE проектах со Spring, туча народа просто не понимала, что вообще происходит с этим DI и что это на самом деле такое, хотя работали со всем этим практически каждый день.
PHP сегодня не сможет соревноваться в фронтенде сс js/node, с тем же go в быстродействии и т.д.
Это нужно раскрыть. Вот смотрите
www.hostingadvice.com/blog/comparing-node-js-vs-php-performance
По ссылке выше есть таблица
Посмотрите где там hhvm, а ведь php7 (на графике php 5.5 ) совсем рядом по производительности.
Посмотрите где там hhvm, а ведь php7 (на графике php 5.5 ) совсем рядом по производительности.
У меня есть некоторые сомнения по этим графикам, но так или иначе, говоря про соревнование, я все же имел в виду не производительность, а предлагаемые инструменты для разработки клиентской части приложения.
как раз, смотря на график hhvm, можно его понимать и как php7. Поэтому с производительностью неплохо. Тем не менее эти графики в совокупности у меня тоже вызывают сомнения — непонятно что с чем там меряли и корректно ли это.
У меня большие вопросы как к этому бенчмарку (как можно сравнивать водпресс приложение с кодом на ноде который просто отвечает хелло ворлд), так и компетентности автора статьи по ссылке (в коментах он вообще чушь несет, про хендшейки и установление сессий на стороне ноды). Если бы я сравнивал php с нодой, то сравнивал бы с reactphp.
статья некорректна в том, что приписываются минусы фреймворку в том, что на самом деле является минусом разработчика, т.к. он следует неким практикам, принятым в yii-сообществе, но не требуемым устройством фреймворка. То есть дело в том, что разработчик пишет «как все», а не как правильно.
advanced — пример организации кода, и в нем как раз не предлагается все то, что ты пишешь. Просто «так повелось», а многие разработчики плывут по течению, не пытаясь сгенерить лучшую практику. (ты ведь видел например мой способ организации кода — он лишен всех этих минусов, и написан в рамках advanced).
опять же нет такого требования — есть практики, где принято всю бизнес-логику запихивать в модели, хотя очевидно ее надо выносить в сервисный слой.
ты превратно понимаешь mvc — он не о тонких контроллерах и жирным моделях.
вот тут полная правда: виджеты yii2 — полный ад. Перефразируя Тему, «так программируют только чудаки».
У Yii2 есть своя ниша. Это RAD-фреймворк и поэтому на нем можно замечательно набросать несложный сайтик, нетребующий дальнейшей сложной поддержки (и развития).
Но начинающие разработчики этого не понимают, и считают, что yii2 — это самый лучший фреймворк с низким порогом входа, который можно применить для любых задач. С ростом опыта это понимание приходит, разработчик начинает замечать минусы, в том числе сильной связанности всего фреймворка, и покидает сообщество. И уже этим обуславливается низкое качество и отсутствие функциональных расширений — профессионально слабое сообщество. См. первую часть моего коммента — неспособность разработать самому продуктивную структуру приложения и следование устоявшимся якобы «лучшим» практикам.
С настроением статьи согласен, с аргументами частично.
Как-бы решает дискомфорт с приложениями в basic, но появляется новый дискомфорт. У нас в проекте появляется тонна конфигов для каждого приложения + общие и все модели начинают делиться между приложениями и наследовать друг друга. Еще в некоторых случаях приходилось перекрывать реляции, чтобы дергать классы моделей текущего приложения, а не общего.
advanced — пример организации кода, и в нем как раз не предлагается все то, что ты пишешь. Просто «так повелось», а многие разработчики плывут по течению, не пытаясь сгенерить лучшую практику. (ты ведь видел например мой способ организации кода — он лишен всех этих минусов, и написан в рамках advanced).
Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все. Модель обычно в лучших традициях унаследована от ActiveRecord, работает с формами, валидацией, содержит логику, реляции, еще одну логику, еще сценарии, и еще 10 логик на каждый сценарий и еще одну логику для логики логик.
опять же нет такого требования — есть практики, где принято всю бизнес-логику запихивать в модели, хотя очевидно ее надо выносить в сервисный слой.
В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели.
ты превратно понимаешь mvc — он не о тонких контроллерах и жирным моделях.
ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).
вот тут полная правда: виджеты yii2 — полный ад. Перефразируя Тему, «так программируют только чудаки».
У Yii2 есть своя ниша. Это RAD-фреймворк и поэтому на нем можно замечательно набросать несложный сайтик, нетребующий дальнейшей сложной поддержки (и развития).
Но начинающие разработчики этого не понимают, и считают, что yii2 — это самый лучший фреймворк с низким порогом входа, который можно применить для любых задач. С ростом опыта это понимание приходит, разработчик начинает замечать минусы, в том числе сильной связанности всего фреймворка, и покидает сообщество. И уже этим обуславливается низкое качество и отсутствие функциональных расширений — профессионально слабое сообщество. См. первую часть моего коммента — неспособность разработать самому продуктивную структуру приложения и следование устоявшимся якобы «лучшим» практикам.
С настроением статьи согласен, с аргументами частично.
добавлю, что можно и на yii2 напрограммировать красиво, было бы желание, но yii будет всячески «мешать» этому своей сильной связанностью.
поэтому, как и автор поста, «втоплю» за симфони :-)
поэтому, как и автор поста, «втоплю» за симфони :-)
Да все верно. Я даже уточнил в статье, что Yii2 это не плохой инструмент. И все приходится именно на опыт разработчиков. Но тем не менее, сколько человек из многочисленного сообщества пишут хороший и грамотный код на Yii2?
Даже Qiang Xue аккуратненько свернул на GO, подальше от Yii2 =).
Даже Qiang Xue аккуратненько свернул на GO, подальше от Yii2 =).
в паблике я не видел хорошего кода на yii2.
Не стоит передёргивать насчёт «срулил» и, тем более, насчёт «подальше».
Про отсутствие функциональных расширений распишите подробнее?
автор высказал тезис про отсуствие инетерсных расширений, дескать, есть только базового уровня. Я согласен. Практически 100% расширений — это джуниорские поделки (у самого на гитхабе за 2014 год есть таких несколько).
такс) интересные, базовые, функциональные это мягкое, колкое и зеленое))) Интересные расширения это интересно)))
А вот, к примеру, как к этому расширению относитесь? Довольно нехилый набор параметров для постройки таблиц из бд.
demos.krajee.com/grid
А вот, к примеру, как к этому расширению относитесь? Довольно нехилый набор параметров для постройки таблиц из бд.
demos.krajee.com/grid
к Картику у меня следующее отношение — мне кажется он предвестник армагеддона, настолько у него индусский код. Это раз.
А два: виджеты это новичкам от новичков. Очень важная причина популярности yii среди новичков — наличие виджетов для базовых вещей.
Три: все-таки под функциональными расширениями имелось что-то более крупное, чем клиентские улучшения для админки.
А два: виджеты это новичкам от новичков. Очень важная причина популярности yii среди новичков — наличие виджетов для базовых вещей.
Три: все-таки под функциональными расширениями имелось что-то более крупное, чем клиентские улучшения для админки.
Переделывать виджеты пд себя самоубийство. Проще свой сделать. За код и их развитие отвечает только он. Волновать может только их безглючная работа и скорость. (то что виджеты тормозят это да, ну извиняйте, плата за универсальность) Но то что они прекрасно работают и сверхуниверсальные — отрицать ну никак нельзя.
Смотрите как интересно получается — вы связываете популярность у новичков с готовыми решениями из коробки. Вот у визуал студии есть дизайнер форм из коробки, базовая вещь, это тоже причина популярности среди новичков? Конечно! Это абсолютно нормальтная закономерность — чем больше позволяет инсрумент тем больше людей найдут в нем решение своих задач.
Мы смотрели и крутили Го, интересно весело и круто, ну и куда он впился без готовых для работы виджетов? Переходить на ext-js? Спасибо — не надо. Почему стало плохо наличие виджетов для базовых вещей?
Одно замечание — я не хочу наш опыт объявлять святым. Мы всегда отстаиваем свой опыт в кругу своих задач. Отсюда какие то бесконечные разногласия.
Ну по последнему пункту возразить мне нечем, поскольку тут получается что коли что хотели более крупное, но вот что, да и имеет ли тогда это отношение к виджетам.
Смотрите как интересно получается — вы связываете популярность у новичков с готовыми решениями из коробки. Вот у визуал студии есть дизайнер форм из коробки, базовая вещь, это тоже причина популярности среди новичков? Конечно! Это абсолютно нормальтная закономерность — чем больше позволяет инсрумент тем больше людей найдут в нем решение своих задач.
Мы смотрели и крутили Го, интересно весело и круто, ну и куда он впился без готовых для работы виджетов? Переходить на ext-js? Спасибо — не надо. Почему стало плохо наличие виджетов для базовых вещей?
Одно замечание — я не хочу наш опыт объявлять святым. Мы всегда отстаиваем свой опыт в кругу своих задач. Отсюда какие то бесконечные разногласия.
Ну по последнему пункту возразить мне нечем, поскольку тут получается что коли что хотели более крупное, но вот что, да и имеет ли тогда это отношение к виджетам.
Не согласен. Просто надо знать, на что смотреть:
— github.com/yii2tech
— github.com/codemix
— github.com/creocoder
Тут всё очень даже. И это, естественно, не полный список.
— github.com/yii2tech
— github.com/codemix
— github.com/creocoder
Тут всё очень даже. И это, естественно, не полный список.
да конечно все я это видел. Это то, что называется «исключение, подтверждающее правило». Есть расширения с хорошим уровнем абстракции, хорошим конфигурированием, продуманностью удобства для конечного разработчика, а не сделанное под конкретный проект. Но их мало. Таких разработчиков 5-10 на все сообщество.
есть практики, где принято всю бизнес-логику запихивать в модели, хотя очевидно ее надо выносить в сервисный слой.
Модель и предназначена для бизнес-логики, её основная функция — моделирование и реализации бизнес-логики. Сервисы — это уровень контроллера в MVC по умолчанию. Если очевидно и бизнес-логику поместить в сервисы, то что останется в модели? Просто DTO?
Эх, опять эти три волшебных буквы MVC.
Модель в MVC это что угодно, что хранит состояние данных и занимается обработкой. Что там внутри, сервисы и дата мэппер, актив стэйт/актив рекорд, просто PHP возвращающий наружу имутабельные DTO — это все деталь реализации и скрыто инкапсуляцией. Контроллер вообще об этом ничего знать не знает и не хочет.
Идеальный вариант — в контексте выполнения каких-то действий моделью является сервисный слой. При составлении ответа — имутабельные DTO. Представлению нужно всего-лишь текущее состояние и только. Даже Model2 не противоречит тому о чем я толкую.
Итого, сервисный слой тикакого отношения к MVC не имеет, это деталь реализации модели. Вместо того что бы обсуждать что там есть в MVC и какое место занимает, лучше обсуждать о том как эти штуки взаимодействуют друг с дружкой, почему именно так и чем так плох smartui что пришлось выдумывать эту чушь.
Модель в MVC это что угодно, что хранит состояние данных и занимается обработкой. Что там внутри, сервисы и дата мэппер, актив стэйт/актив рекорд, просто PHP возвращающий наружу имутабельные DTO — это все деталь реализации и скрыто инкапсуляцией. Контроллер вообще об этом ничего знать не знает и не хочет.
Идеальный вариант — в контексте выполнения каких-то действий моделью является сервисный слой. При составлении ответа — имутабельные DTO. Представлению нужно всего-лишь текущее состояние и только. Даже Model2 не противоречит тому о чем я толкую.
Итого, сервисный слой тикакого отношения к MVC не имеет, это деталь реализации модели. Вместо того что бы обсуждать что там есть в MVC и какое место занимает, лучше обсуждать о том как эти штуки взаимодействуют друг с дружкой, почему именно так и чем так плох smartui что пришлось выдумывать эту чушь.
Сервисный слой — деталь реализации контроллера, если, например, хочется инкапсулировать от объекта контроллера детали реализации хранения данных моделей или просто делегировать хранение чтобы не захламлять код. Но это деталь реализации именно контроллера, контроллер должен знать какой сервис дернуть, чтобы получить нужную ему модель
А вот как раз модель ничего не знает и не хочет знать о том, как она хранится и хранится ли вообще ) Она знает и хочет знать только о предметной области, в которой, как правило, нет понятия даже «сохранить документ», не говоря об «обновить записи в базе данных».
А вот как раз модель ничего не знает и не хочет знать о том, как она хранится и хранится ли вообще ) Она знает и хочет знать только о предметной области, в которой, как правило, нет понятия даже «сохранить документ», не говоря об «обновить записи в базе данных».
Сервисный слой — деталь реализации контроллера
Контроллер — адаптер между приложением и HTTP. Не более. Его задача — выдрать данные из HTTP запроса и попросить модель отреагировать на действия. Как — вызвав метод конкретного сервиса, пробросив команду в шину команд или еще как — это уже деталь реализации именно модели. Приложение не зависит от UI, UI зависит от приложения. Вы же не будете говорить что «приложение является деталью реализации контроллеров или UI».
А вот как раз модель ничего не знает и не хочет знать о том, как она хранится и хранится ли вообще
Вы путаете понятие «модель» и «сущность». Ну или просто смешиваете эти понятия. Как говаривал Эрик Эванс — выражайте модель через сервисы и сущности.
И да, скажите, вам правда так «удобнее» воспринимать все это? Со всеми этими дополнительными вещами, деталями, усложнениями и т.д.? То есть простая до ужаса идея отделения UI от приложения превращается в дико сложную хрень которую каждый трактует как хочет и по итогу получает толстые контроллеры и отсутствие этого самого разделения.
Контроллер — адаптер между приложением и HTTP.
Адаптер между HTTP и приложением в нашем случае — php-fpm или mod_php, плюс фронт-контроллер, передающие в конкретный контроллер уже данные приложения, пускай не объекты модели, но хотя бы объектную обертку над HTTP-запросом, понятную приложению.
Приложение не зависит от UI, UI зависит от приложения.
Приложение состоит из UI, модели и «клея», обеспечивающего их взаимодействие. Клей принято называть контроллером в Model2 :)
Вы путаете понятие «модель» и «сущность».
Не путаю. Но смешиваю, да. как и Эванс :)
Как говаривал Эрик Эванс — выражайте модель через сервисы и сущности.
Ветка началась с утверждения, что бизнес-логику нужно помещать не в модели, а в сервисах, что естественно навело на мысли о сервисах в смысле Фаулера, а не в смысле Эванса.
И да, скажите, вам правда так «удобнее» воспринимать все это?
Да, удобнее. Чётко разделив обязанности каждого слоя, не возникает (ну, редко) вопросов куда поместить ту или иную функциональность.
То есть простая до ужаса идея отделения UI от приложения
Отделения в приложении UI от логики домена и их обоих от остальной инфраструктуры. Да, может получиться толстый контроллер, если инфраструктуры много, или толстая модель, если бизнес-логика сложная, но стратегически разделение произведено и дальше повышать уровни абстракции можно чуть ли не автоматически по алгоритмам типа «в методе не должно быть больше 7 строк».
Адаптер между HTTP и приложением в нашем случае — php-fpm или mod_php, плюс фронт-контроллер, передающие в конкретный контроллер уже данные приложения
public function anyControllerAction(Http\Request $request) {
$resultDTO = $this->get('some.app.service')->doSomeStuff($request->get('foo', $request->get('bar'));
return new Http\JsonResponse($resultDTO, 201);
}
нэймспейсы как-бы намекают что контроллеры являются именно адаптерами между интерфейсом (в нашем случае HTTP) и приложением. В этом суть GRASP-контроллеров и в этом суть Model-View-Adapter (MVC на бэкэнде никогда небыло. Если не верите, сравните диаграмки канонического MVC и MVA).
Приложение состоит из UI, модели и «клея», обеспечивающего их взаимодействие. Клей принято называть контроллером в Model2 :)
Или адаптером в MVA, Model2 это развитие MVA с уточнением о том что есть еще логика сохранения этого добра.
Не путаю. Но смешиваю, да. как и Эванс :)
Нууу… у Эванса сущности это часть модели но не вся модель.
Ветка началась с утверждения, что бизнес-логику нужно помещать не в модели, а в сервисах
Я это понимаю. А я лишь написал что говорить в контексте MVC про сервисный слой не имеет смысла так как сервисный слой — элемент модели в контексте MVC.
Да, может получиться толстый контроллер, если инфраструктуры много
Инфраструктура так же выносится в сервисы уровня инфраструктуры. Раз уж мы про слои заговорили. Это все же логика приложения. Что мы будем делать с толстыми контроллерами и сложной инфраструктурой через год, когда понадобится делать микросервисы или для целей тестирования добавлять CLI интерфейс к приложению, или Pub/Sub для websockets и т.д.
нынче WEB это далеко не только тупо формочки. И это надо учитывать.
Похоже у нас разные понимания термина «приложение». Давайте договоримся об одном?
Если вас смутила вот эта фраза:
То это похоже я упоролся к вечеру. Я хотел сказать что без инфраструктуры никак конечно, но это НЕ основная часть приложения. Она лишь поддерживает его работу. Контроллеры — это часть инфраструктуры и не более.
Но все же поясню. Толстые контроллеры — это не грех. Иногда это оправдано. Мы просто увеличиваем уровень технического долга в угоду скорости разработки и потом это может вылиться нам в довольно длительный рефакторинг, что может навредить бизнесу.
Проблема в том, что бы вовремя уловить необходимость снижения уровня технического долга, что весьма сложно, когда у людей просто нет представления о том, к чему это может привести и как можно исправить ситуацию.
Интересный факт. Разработчики как правило не заморачиваются по поводу этих вещей пока не зафэйлят парочку проектов, или, что чаще, пока не сталкнуться с поддержкой уже зафэйленного проекта (свой код не так сильно пахнет). Но возможно у меня выборка не репрезентативна. Просто так же люди не будут пытаться делать свою работу лучше.
Инфраструктура так же выносится в сервисы уровня инфраструктуры. Раз уж мы про слои заговорили. Это все же логика приложения.
То это похоже я упоролся к вечеру. Я хотел сказать что без инфраструктуры никак конечно, но это НЕ основная часть приложения. Она лишь поддерживает его работу. Контроллеры — это часть инфраструктуры и не более.
Но все же поясню. Толстые контроллеры — это не грех. Иногда это оправдано. Мы просто увеличиваем уровень технического долга в угоду скорости разработки и потом это может вылиться нам в довольно длительный рефакторинг, что может навредить бизнесу.
Проблема в том, что бы вовремя уловить необходимость снижения уровня технического долга, что весьма сложно, когда у людей просто нет представления о том, к чему это может привести и как можно исправить ситуацию.
Интересный факт. Разработчики как правило не заморачиваются по поводу этих вещей пока не зафэйлят парочку проектов, или, что чаще, пока не сталкнуться с поддержкой уже зафэйленного проекта (свой код не так сильно пахнет). Но возможно у меня выборка не репрезентативна. Просто так же люди не будут пытаться делать свою работу лучше.
Именно, что контроллеры часть инфраструктуры. Но в инфраструктуре у них особая роль — дирижирование моделями, представлениями и остальной инфраструктурой (часто выносимой на сервисный уровень). Нельзя сводить их роль просто к адаптеру между моделью и представлением.
И не всегда даже толстый контроллер является техническим долгом. Если дублирования кода в разных контроллерах и их методах нет, логика каждого метода прозрачна, не имеет неявных побочных эффектов и т. п., то не факт, что долг есть. Можно, конечно, считать долгом любой метод больше трёх строк и любой класс с больше чем 7 методами, но это, по-моему, очень примитивный подход, годящийся разве что когда в команде много низкоквалифицированных разработчиков, а времени проводить детальное ревьюирование больших кусков кода нет.
Согласен с фактом :) Но, по-моему, сильно зависит от мотивации разработчика, что он считает «просто так».
И не всегда даже толстый контроллер является техническим долгом. Если дублирования кода в разных контроллерах и их методах нет, логика каждого метода прозрачна, не имеет неявных побочных эффектов и т. п., то не факт, что долг есть. Можно, конечно, считать долгом любой метод больше трёх строк и любой класс с больше чем 7 методами, но это, по-моему, очень примитивный подход, годящийся разве что когда в команде много низкоквалифицированных разработчиков, а времени проводить детальное ревьюирование больших кусков кода нет.
Согласен с фактом :) Но, по-моему, сильно зависит от мотивации разработчика, что он считает «просто так».
Кличко весит больше меня, но толстый среди нас двоих я.
Обычно толстый это именно толстый.
Количество строк в методе обычно стантарты ограничивают около 20, что помещается на один экран.
Больше это уже долг, который да, может быть оправдан. А может и не быть.
Обычно толстый это именно толстый.
Количество строк в методе обычно стантарты ограничивают около 20, что помещается на один экран.
Больше это уже долг, который да, может быть оправдан. А может и не быть.
3 действия на экшен контроллера.
— Подготовить данные запроса к прокидываю в сервисы. Ну то есть какая-то валидация минимальная самого запроса без привязки к бизнес логике
— Пробросить данные запроса в метод модели и получить результат. В случае CQRS это два отдельных действия.
— Сформировать ответ.
Толстый контроллер — это все где действий становится больше. Пример — batch обработка. Например нам прислали 10 айдишек которые надо удалить. Это будет 10 вызовов сервиса в цикле, но это будет именно одно действие а не 10. Потому контроллер остается тонким и наша логика не догадывается о том что там есть вообще batch обработка.
— Подготовить данные запроса к прокидываю в сервисы. Ну то есть какая-то валидация минимальная самого запроса без привязки к бизнес логике
— Пробросить данные запроса в метод модели и получить результат. В случае CQRS это два отдельных действия.
— Сформировать ответ.
Толстый контроллер — это все где действий становится больше. Пример — batch обработка. Например нам прислали 10 айдишек которые надо удалить. Это будет 10 вызовов сервиса в цикле, но это будет именно одно действие а не 10. Потому контроллер остается тонким и наша логика не догадывается о том что там есть вообще batch обработка.
экшн это и есть контроллер. Всё остальное это сахар. Часто полезный, иногда вредный, но сахар.
Это удобно для гибкости архитектуры (например фильтры по get/post/delete это ответственность архитектуры, роутов, но не контроллера. Это удобно для переиспользования кода, хотя сферический код контроллера должен быть совсем не переиспользуемым. Но это сахар.
Собственно толщину контроллера стоит измерять не столько толщиной (количеством строк), сколько остальной частью идиомы — тупостью и уродливостью :)
Примерно как у текстов есть понятие «водность» и отражает процент малозначащих слов, так и здесь тупость контроллера я бы оценивал процентом кода который МОЖНО (не нужно, а МОЖНО переиспользовать).
Понятно что оценка сферическая как и водность. Но водность изначально я придумывал как эвристику для человека, а цифровую оценку сделал лишь как ориентир, чтобы было понятнее. Но как-то прижилась только цифра)
Это удобно для гибкости архитектуры (например фильтры по get/post/delete это ответственность архитектуры, роутов, но не контроллера. Это удобно для переиспользования кода, хотя сферический код контроллера должен быть совсем не переиспользуемым. Но это сахар.
Собственно толщину контроллера стоит измерять не столько толщиной (количеством строк), сколько остальной частью идиомы — тупостью и уродливостью :)
Примерно как у текстов есть понятие «водность» и отражает процент малозначащих слов, так и здесь тупость контроллера я бы оценивал процентом кода который МОЖНО (не нужно, а МОЖНО переиспользовать).
Понятно что оценка сферическая как и водность. Но водность изначально я придумывал как эвристику для человека, а цифровую оценку сделал лишь как ориентир, чтобы было понятнее. Но как-то прижилась только цифра)
модель включает бизнес-логику, связанную только с самой моделью. сервисный слой включает в себя бизнес нескольких несвязанных моделей + инфраструктурные операции.
Я же говорил скорее о чем-то, что отдаленно связанно с моделью, например различные файндеры, которые принято в yii пихать в модели.
Я же говорил скорее о чем-то, что отдаленно связанно с моделью, например различные файндеры, которые принято в yii пихать в модели.
Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все.
Я вообще считаю, что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно). Многие товарищи вообще говорят, что MVC для веба (не бизнес приложений) плохая идея (разработчики Pyramid).
Тоже так раньше считал, но когда один файл содержит кучу различных логик, кучу разных инструментов и тем более имеют доступы публичные — тоже еще тот АД. Вам ВСЕГДА надо работать с тонной кода, если только каждый экшн не выносить в отдельные файлы, что тоже гемор. Мне кажется, самое больное место тут – как правильно передать, а тем более добавить в существующий код, нужные параметры для моделей, чтоб она правильно завелась или чтоб ее запуск не был завтра адом, но со времени получается все лучше.
Когда модель становится той еще толстушкой, мне нравится ее делать в своем роде модель-контроллер, которая подключает другие классы модели сгруппированных по каким-то свойствам, либо разбивать на трейты опять же по общим свойствам. Так всегда работаешь с минимальным количеством кода, пусть и файлов плодиться куча. Чем меньше кода трогаем, тем лучше. Приятно ведь когда написана либа раз и все, и ты ее годами не трогаешь, она как танк работает и все тут.
А так кучу раз копи-пастить код и разбирать его из проекта в проект О_О
Когда модель становится той еще толстушкой, мне нравится ее делать в своем роде модель-контроллер, которая подключает другие классы модели сгруппированных по каким-то свойствам, либо разбивать на трейты опять же по общим свойствам. Так всегда работаешь с минимальным количеством кода, пусть и файлов плодиться куча. Чем меньше кода трогаем, тем лучше. Приятно ведь когда написана либа раз и все, и ты ее годами не трогаешь, она как танк работает и все тут.
А так кучу раз копи-пастить код и разбирать его из проекта в проект О_О
если только каждый экшн не выносить в отдельные файлы, что тоже гемор
Так всегда работаешь с минимальным количеством кода, пусть и файлов плодиться куча.
А не те самые это яйца только в профиль?
Мне в целом нравится как это сделано в Pylons когда контроллер это некий класс который содержит экшены т.е. их можно группировать функционально и создавать внутреннюю логику для избежания копипаста (такие контролеры можно наследовать друг от друга). Ну и конечно если постоянно много однотипных работ с данными то тут надо модель мучить.
В чём для этих товарищей отличие веба от бизнес-приложений с веб-интерфейсом?
что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно)
Это называется SmartUI так как бизнес логика из модели в этом случае вытекает в контроллеры, цель которых — выступить в качестве медиатора между UI (HTTP) и приложением (модель в контексте MVC на бэкэнде это граница приложения). То есть у нас уже нет разделения логики представления данных от логики обработки данных (мы же завязываем логику приложения на HTTP).
У SmartUI есть свои преимущества, в частности — простота. Любой дурак сможет разобраться в этом, согласитесь. Для какого-нибудь CRUD-а с независимой логикой для каждого ресурса — это более чем нормальных подход которые позволяет поднять скорость разработки до неимоверных высот. А если еще и с кодогенерацией… ух. И справедливости ради — таких приложений большинство.
Но давайте пройдемся по недостаткам.
1) дублирование кода. Как только у нас возникает ситуация, когда нам нужно организовать схожую логику и т.д. довольно часто возникает дублирование кода в контроллерах. Конечно дублирование можно потом вынести в сервисы и использовать их в контроллерах, например в рамках рефакторинга. И это покрывает еще определенный процент кейсов. Так что вроде как не смертельно.
2) зависимость приложения от интерфейса и инфраструктуры. Это означает что мы уже не можем так быстро заменить инфреструктуру в случае ошибок проектирования (которые не всегда можно предугадать, например пол года назад все было ок а сегодня требования поменялись).
Так же у нас начинаются проблемы с UI. В случае обычного WEB в этом нет ничего страшного ибо все находится в нашем контроле, но если мы делаем API для мобильных приложений — начинается веселье. Есть такая штука как обратная совместимость, и ее надо учитывать минимум 3 месяца после релиза новой версии (по исследованиям фэйсбука именно столько надо что бы подавляющее большинство обновило апу). В итоге в контроллере появляются отвратительные вещи и контролировать все это становится тяжело.
Ну и слабый аргумент конечно (для многих, большинство не пишут тестов увы), но мы можем кокрыть приложение только E2E или интеграционными тестами на уровне HTTP. Что медленно, и в силу довольно продолжительного исполнения не дает нормального фидбэк лупа.
Ну и не стоит забывать о таких вещах как микросервисы, без которых реально большие проекты больше ничто не пишет. С толстыми контроллерами это все весьма проблематично (хоть и возможно).
И я не могу сказать что все это сильно плохо там и т.д. и уж тем более не призываю всех делать все исключительно с использованием слоеных архитектур, полной изоляцией инфраструктуры и т.д. Не зря существует понятие "Технический Долг". Есть все-таки здравый смысл. Но это сложно ибо приходится мало того что думать что и почему делаешь, так еще и прогнозировать в каких действиях и решениях сколько профита. Нам же надо задачи бизнеса эффективнее решать. Где-то это эффективнее с толстыми контроллерами, где-то с CQRS + EventSourcing, архитектурами портов и адаптеров и т.д.
И проблемы возникают когда разработчики, которые даже не знают что такое MVC и зачем оно надо, начинают делать реально большие проекты и потом фэйлят все а люди теряют деньги.
что MVC для веба (не бизнес приложений) плохая идея
MVC — чисто GUI архитектура, которую изначально придумали как решение проблем десктопных приложений. В контексте WEB все интереснее так как тут мы ограничены request/response моделью. Например по схеме smaltalk-MVC (79-ого года) между моделью и представлением были прямые обзервабл отношения. То есть представление подписывалось на события обновления модели и обновляли свое состояние под текущее. На бэкэнде же используется MVA (Model-View-Adapter), а контроллер (читать про контроллер в контексте GRASP) становится лишь адаптером между представлением и моделью полностью изолируя одно от другого.
Так что да, MVC на бэкэнде не имеет смысла, но никто не использует на бэкэнде MVC — все используют MVA и дальнейшие развития этой идеи (Model2 в частности).
1) дублирование кода.
Почему все забывают старые добрые Сишные функции?
MVC — чисто GUI архитектура, которую изначально придумали как решение проблем десктопных приложений.
Я вам даже больше скажу, это всё было сделано для StateFull систем, а современный веб как правило StateLess. От сюда и неприменимость многих архитектурных плюсов MVC.
делаем API для мобильных приложений — начинается веселье
Веселье в любом случае начинается, так как вам приходится старое и новое API разводить либо в модели либо в контроллере (как правило это затрагивает все слои).
А вообще есть мысль, что под словом MVC сейчас все понимают разные вещи и его применяют часто не к месту. (Pyramid вообще себя RV фреймворком называет)
Короче надо смотреть конкретные реализации и их минусы, всё крайне сложно. :(
Почему все забывают старые добрые Сишные функции?
Мы же в PHP хабе, тут функции исторически недооценивают с появлением автозагрузки классов… что печально конечно.
это всё было сделано для StateFull систем, а современный веб как правило StateLess
Именно. Удешевление памяти сделало свое дело.
А вообще есть мысль, что под словом MVC сейчас все понимают разные вещи и его применяют часто не к месту.
MVC — это модно. Если у тебя не MVC — ты не модный. Потому даже если у тебя НЕ MVC — говори всем что это не так. Тот же Flux намного ближе к концепциям MVC нежели все остальное. Просто оперирует оно имутабельными штуками и добавился event sourcing, что несомненно плюс.
Почему все забывают старые добрые Сишные функции?
Когда не было классов и нэймспэйсов, старые добрые функции использовались в качестве их суррогатов, а зависимости разруливались вручную. Когда появились классы, то разделение на классы и функции было практически идеальным (у тех, кто пришёл к ООП из ПП без фанатизма), а зависимости разруливались вручную. Но потом пришёл __autoload только для классов, это оказалось очень удобно, вручную разруливать только функции никто не захотел и стали использовать классы со статическими методами как функции.
Ужос! Сколько всего я пропустил… непонятно как в Python все живут с import и без autoload
import в Python перекрывает функциональность и use, и __autoload. Для возможности использовать функцию из другого файла нужно явно указать имя этого файла в include почти как в старом добром Си, только дополнительная линковка никогда не нужна, поскольку объявление функции и её определение неразделимы.
непонятно как в Python все живут с import и без autoload
autoload в PHP был нужен потому что нет модулей и все использовали эти ужасные require хаки и кастыли.
Могу вам сказать что модули — это более правильная концепция, которая позволяет убрать кастыли в виде модификаторов доступа и добиться более логичной инкапсуляции.
Если вам кажется что это не так — то вы просто привыкли к определенным подходам.
А сейчас круг замкнулся — у нас появились неймспейсы, и то от чего мы бежали, к тому и вернулись.
Только раньше были пачки инклюдов в начале файла, сейчас неймспейсы, что с учетом автозагрузки во многом суть абстракция над теми же инклюдами. Не холивара ради, просто аналогия напрашивается.
Только раньше были пачки инклюдов в начале файла, сейчас неймспейсы, что с учетом автозагрузки во многом суть абстракция над теми же инклюдами. Не холивара ради, просто аналогия напрашивается.
Какое именно отношение пространства имен имеют к автозагрузке? psr-4 же решает все проблемы. Нэймспейсы в PHP решают ту же проблемы что и в C++ — разграничение области видимости.
Вообще модули решили бы все проблемы.
Вообще модули решили бы все проблемы.
Не совсем. Во-первых, пачки use в начале или где ещё файла необязательны, а механизм автозагрузки работает ортогонально им. А он, в свою очередь, полностью необходимость использовать инклуды не убрал даже вне себя, не говоря о том, что сам на них построен.
Я немного не о том.
Понятно что автозагрузка скрывает, что юзы не обязательны, что реализованы на тех же инклюдах и т.п.
Я о другом.
Были инклюды, которые решали определенную задачу.
Но управление инклюдами стало сложным. Либо грузили лишнее, либо полотна в каждом файле и т.п.
Логичным развитием оказался автозагрузчик.
Сложность росла, естественно образовались псевдонеймспейсы,
которые эволюционировали в полноценные неймспейсы, обросли psr-0 а потом и psr-4.
Деревья неймспейсов стали как раньше инклюдов.
Дошло до того, что уже в языке юзы упрощают (что мне не нравится — лишние пару символов, не стоят лишних конструкций).
Круг замкнулся. Да, на совершенно другом уровне абстракции, да, без автозагрузки до такой сложности мы бы и не доросли, но тем не менее.
Чтобы было понятнее приведу аналогию с сетевым стеком:
придумали ДНС, чтобы не запоминать кучу айпи, но всё равно приходится запоминать, только теперь уже не айпи а домены, и похожая эволюция тут тоже имеется в виде разных закладок (как в браузере так и сервисы), использования строки поиска для избежания запоминания, ИДН даже выдумали.
Но это не значит, что ДНС плох, что он не справился с задачей и т.п., на числовых адресах мы бы до такой сложности бы не доросли…
Понятно что автозагрузка скрывает, что юзы не обязательны, что реализованы на тех же инклюдах и т.п.
Я о другом.
Были инклюды, которые решали определенную задачу.
Но управление инклюдами стало сложным. Либо грузили лишнее, либо полотна в каждом файле и т.п.
Логичным развитием оказался автозагрузчик.
Сложность росла, естественно образовались псевдонеймспейсы,
которые эволюционировали в полноценные неймспейсы, обросли psr-0 а потом и psr-4.
Деревья неймспейсов стали как раньше инклюдов.
Дошло до того, что уже в языке юзы упрощают (что мне не нравится — лишние пару символов, не стоят лишних конструкций).
Круг замкнулся. Да, на совершенно другом уровне абстракции, да, без автозагрузки до такой сложности мы бы и не доросли, но тем не менее.
Чтобы было понятнее приведу аналогию с сетевым стеком:
придумали ДНС, чтобы не запоминать кучу айпи, но всё равно приходится запоминать, только теперь уже не айпи а домены, и похожая эволюция тут тоже имеется в виде разных закладок (как в браузере так и сервисы), использования строки поиска для избежания запоминания, ИДН даже выдумали.
Но это не значит, что ДНС плох, что он не справился с задачей и т.п., на числовых адресах мы бы до такой сложности бы не доросли…
Вы забываете о важной роли DNS — балансировка. Благодаря DNS мы можем заменять сервера, не беспокоясь что пользователю надо запоминать новый IP, уменьшается связанность и т.д. CDN, балансировка нагрузок и т.д. Ух. Так что ваша аналогия не корректна.
Реализовать же модули в PHP — сложно (просто потому что много переделывать внутри).
Реализовать же модули в PHP — сложно (просто потому что много переделывать внутри).
А вроде как раз корректно получается. Автозагрузка (с тулзами типа композера) тоже своего рода DNS, пользователю (разработчику) уже не нужно беспокоится о физических путях к файлам, они могут быть где угодно на диске, лишь бы автозагрузчик о них знал.
Тут много аналогий можно строить. Даже обновление через композер меняет файл довольно прозрачно на новую версию. А паттерн внедрения зависимостей еще более гибок в этом плане. Но к чему это? Аналогия была в эволюции а не в функции. Это как если бы я сравнил дирижабли с подводными лодками, а мне бы сказали что подлодки тяжелее воздуха и вообще бывают атомными, а дирижаблей атомных не бывает, так что сходства совсем нет и аналогия глупа :)
на самом деле сейчас не нужна автозагрузка функций. В composer есть чудная опция автозагрузки — include. Мол подключать файлики на каждый запрос. И это решает вопрос с реквайром файликов для доступак функциям.
Нэймспейсы же позволяют разграничивать функции по разным контекстам. Что бы не превращать все в мусор.
Однако без модулей в случае функций мы все так же занимаемся неявным сокрытием зависимостей от функций. С управлением зависимостями у объектов в PHP все хорошо, а вот с функциями… посмотрим на PHP8, может там эту проблему будут решать уже.
Нэймспейсы же позволяют разграничивать функции по разным контекстам. Что бы не превращать все в мусор.
Однако без модулей в случае функций мы все так же занимаемся неявным сокрытием зависимостей от функций. С управлением зависимостями у объектов в PHP все хорошо, а вот с функциями… посмотрим на PHP8, может там эту проблему будут решать уже.
А зачем функции в языке который имеет довольно развитый ООП и стремится максимально развивать ООП?
Я не против функций, я не фанатик, когда уместно использую функции, в мелких проектах даже контроллеры файликами без классов инклюжу (помните я утверждал что сферические контроллеры непереиспользуемы).
Но вот реально зачем функции? Это или что-то локальное может даже безымянный колбек, или сахар.
Ну и совместимость конечно же. На это всё текущего синтаксиса даже много.
Я не против функций, я не фанатик, когда уместно использую функции, в мелких проектах даже контроллеры файликами без классов инклюжу (помните я утверждал что сферические контроллеры непереиспользуемы).
Но вот реально зачем функции? Это или что-то локальное может даже безымянный колбек, или сахар.
Ну и совместимость конечно же. На это всё текущего синтаксиса даже много.
Хотя бы чтобы не делать статические методы без состояния в классах.
А зачем?
Некая функция реализованная менее чем за 20 строк (большинство стандартов рекомендуют большие дробить) полностью выполняющая отдельную ответственность и соответственно не подразумевающая что будет частью некоего класса, при этом наследоваться соответственно не будет, подменяться через внедрение зависимостей, не будет мокаться и т.п., при этом достаточно важна, чтобы доступ к ней был из разных файлов.
Нет, такие функции есть, но их относительно не много. И для них хватит текущего функционала за глаза. Лепить сахар для небольшого количества задач стимулируя этим многих на ухудшение стиля это неразумно. (а полноправные функции не могут а БУДУТ приводить к большим монолитным кускам кода, или куче вспомогательных функций без ограничений видимости и прочими прелестями, с плохим покрытием тестами, потому что мокать их сложно и т.п.)…
Я не против функционального подхода, не против предметно ориентированных языков, событийных и т.п., но если уж выбран курс на ООП, то к чему нам функции?
Некая функция реализованная менее чем за 20 строк (большинство стандартов рекомендуют большие дробить) полностью выполняющая отдельную ответственность и соответственно не подразумевающая что будет частью некоего класса, при этом наследоваться соответственно не будет, подменяться через внедрение зависимостей, не будет мокаться и т.п., при этом достаточно важна, чтобы доступ к ней был из разных файлов.
Нет, такие функции есть, но их относительно не много. И для них хватит текущего функционала за глаза. Лепить сахар для небольшого количества задач стимулируя этим многих на ухудшение стиля это неразумно. (а полноправные функции не могут а БУДУТ приводить к большим монолитным кускам кода, или куче вспомогательных функций без ограничений видимости и прочими прелестями, с плохим покрытием тестами, потому что мокать их сложно и т.п.)…
Я не против функционального подхода, не против предметно ориентированных языков, событийных и т.п., но если уж выбран курс на ООП, то к чему нам функции?
но если уж выбран курс на ООП, то к чему нам функции?
Кто сказал что выбран курс на ООП? Давайте попробуем подумать почему оно так:
— изначально в PHP были только функции (привет наследию Си)
— со временем функций становилось все больше и больше и больше, а приложения на PHP становились все меньше похожи на кучку шаблонов.
— В определенный момент понадобилось как-то группировать функции. Ввели классы (php4). Они же помогли хоть как-то улучшить ситуацию дел с хранением состояния.
— требования к инструменту росли, приложения увеличивались в объеме, потребовалась возможность писать реально большие приложения. Так как ОО подходы на момент выхода PHP5 были намного более популярнее функциональщины (2004-ый год, тогда функциональщина была уделом компаний которым это было реально нужно). Тогда же дабы устранить require hell придумали концепцию автозагрузки классов.
— время шло, понадобились пространства имен что бы позволить разработчикам как-то управлять всем этим мессивом. Ну и функции теперь можно по ним прятать.
Потом еще трейты были и прочая чушь… вот в PHP7 пояивлась сокращенная запись для импорта пространст имен. Но подытожим что на данный момент предоставляет PHP.
PHP предоставляет худо-бедно полноценную реализацию объектной модели слизанную по большей степени из Java или С#. Все типы — глобальные, а значит у нас возникают дополнительные проблемы с версионизацией пакетов, ну да не суть. В целом же управлять зависимостями с объектами в явном виде стало весьма удобно.
Что до функций — их использование сопровождается сокрытием зависимостей. Только в PHP 5.6 появилась возможность явно импортировать функции и тем самым декларировать на высоком уровне зависимости от оных. Люди просто привыкли что с функциями в PHP есть проблемы и как-то это все осталось без внимания. Возможно поменяется в ближайшее время.
Что до проблемы автозагрузки — ее нет. С версии PHP 5.5 из коробки у нас идет opcache, а с composer и его опцией автоматического подключения файлов, оверхэда на это дело просто нет. Висят себе функции в памяти и в ус не дуют.
Ок, история ООП в пхп это хорошо. Но это уже устоявшаяся экосистема.
Вы не привели аргументов против того что у пхп всё развивается в ООП.
Вы не привели аргументов зачем развивать функции.
Они есть, их хватает.
Развивать функциональщину вместо ООП?
Зачем? Любите функциональнсть — используйте языки заточенные под функциональность.
Вы не привели аргументов против того что у пхп всё развивается в ООП.
Вы не привели аргументов зачем развивать функции.
Они есть, их хватает.
Развивать функциональщину вместо ООП?
Зачем? Любите функциональнсть — используйте языки заточенные под функциональность.
Развивать функциональщину вместо ООП?
Меня всегда поражает как люди любят бросаться в крайности. Вы же понимаете что можно развивать и то и то направление? ООП никак не противоречет функциональщине. Наоборот, совмещение идей ОО и функционального программирование — путь к миру, гормонии, уменьшению рисков и счастью.
ОО — это оболочка. Основной профит ОО — управление зависимостями, по сути есть мнение что все ОО затевалось только ради удобной инверсии зависимостей, а функциональщина — это идея отказал от мутаций состояний. А лямбда исчисления и т.д. — это можно использовать вполне себе внутри методов объектов.
Да и модули для ООП будут полезны. В данный момент существует вполне себе конкретная проблема — все типы глобальны. Это означает что мы никогда не сможем в PHP использовать две версии различных пакетов. Уже сейчас это вызывает периодически серьезные проблемы как для обычных разработчиков так и для разработчиков этих самых пакетов.
Использовать функции же можно спокойно начиная с PHP 5.6. А в PHP 7.1 возможно еще и замыкания с автоимпортом скоупов появятся.
Напомню вам что в ближайшем времени ожидается появление модулей в C++. Появятся ли они в PHP — хз.
Для некоторых задач применение ФП выглядит куда более естественным, чем ООП. А PHP никогда себя не ограничивал одной парадигмой (по крайней мере с версии 3) — поддержка (пускай и несколько ограниченная) ФП появилась раньше чем ООП и постоянно делаются шаги в сторону упрощения использования ФП в PHP.
Собственно, это тренд, характерный для многих мэйнстрим языков, где использование ФП изначально было если не невозможным, то не очень комфортным.
Собственно, это тренд, характерный для многих мэйнстрим языков, где использование ФП изначально было если не невозможным, то не очень комфортным.
Тогда еще у меня были очень большие проблемы с архитектурой, хотя должен признать, что сейчас они тоже есть, но не в таких масштабах. Поэтому, когда я натыкался на множество ошибок, я не придавал им значений, а когда проект вырос, было уже поздно.
Жёлтенько. В заголовке можно смело менять заголовок на любое название любого фреймворка или языка. Очень просто винить инструмент в своих ошибках и очень трудно признать, что это ваши ошибки.
Поэтому старайтесь не повторять таких ошибок и не начинать свое обучение на Yii2.
С чего бы вы не начали, первые N проектов как архитектор вы так и так превратите в неперевариваемое месиво. И фреймворк тут не поможет. Ни один.
Если взять ваш абзац «Какой framework выбрать новичку?», его можно переписать и неправдой это не будет:
Профессиональный разработчик может выбрать абсолютно любой инструмент для разработки проекта. Что касается новичка, я бы рекомендовал брать Yii 2. Просто поверьте на слово. Да будет тяжело, да будет желание уйти, да будут жалобы. Нужно перетерпеть и просто сидеть на Yii 2. И так до тех пор пока вы не разберетесь с архитектурой и не получите хорошие знания «как это работает». После этого вы сможете избежать многих ошибок в Symfony 3.
Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.
можно поподробнее? что за фронтенд модель, которая наследуется от activeRecord?
пардон, неправильно сначала понял мысль.
можно сгенерить «тонкую» модель в common, от нее наследовать 2 модели для кажого приложения. все изменения структуры дб и общая логика остаются в common, индивидуальные методы и прочее — в каждоый отдельной модели. такое разделение логики в других фреймворках сделано как-то более элегантно?
на самом деле лучше сделать недо-cqrs — отдельная модель для записи (бэк), отдельная для чтения (без валидаторов, поведений и прочего барахла для фронта). Я бы пошел дальше и для фронта вообще реализовал отдельный механизм получения данных на квери-билдере с наполнением голого объекта (см. ниже).
А в других фреймворках нету AR (кроме ларавела) — поэтому модель представляет из себя POPO (plain old php object) — поэтому там такой вопрос не стоит.
А в других фреймворках нету AR (кроме ларавела) — поэтому модель представляет из себя POPO (plain old php object) — поэтому там такой вопрос не стоит.
Я конечно могу ошибаться, но если новички, то я бы совсем не советовал использовать фреймворки, тем более такие как Yii, Zend, Symfony, Laravel и т.д. Может все желание перебить быть программистом понимая что все работают с этими фреймворками. Конечно может и хорошо, дойдут до конца только сильнейшие. Даже имея годы опыта программирования, не каждый фреймворк дается легко, через задачу хочется кричать, реветь, бросить все и т.д. До PHP мне вообще не нравилось программировать, я как раз через «не хочу» все делал, все что пробовал навязывали какие-то свои проблемы, свои соглашения и т.д. Столько всего просили держать в голове, столько всего просили сделать чтоб сделать элементарные вещи, мало оставалось места в голове для фантазий и финтов ушами, не давали учиться быть гибче, что-то придумывать самому, делать хоть неверные, но свои решения, а потом самому понимать что ты тот еще говнокодер. Тут я думаю свалило кучу народу, которые планировали/имели желание стать программистами, но из-за такого потока «делай так и не спрашивай почему это так делается» приходили к выводу что это тупо не их и шли работать дворниками.
PHP (без фреймворков, паттернов), если забыть об относительной сложности установки и настройки рабочей среды, сразу все просто было и легко. Да, для серьезных проектов такой подход очень плох, но это новички им бы в азарт тут войти, и думаю в целом лучше изучать не фреймворки, а паттерны что они несут, а потом уже плюшки что каждый фреймворк дает. Так простому новичку, и не только, очень сложно лезть в этот космический корабль со всем готовым — ты только делай как мы просим и все будет хорошо. Хорошо вроде звучит, но ооочень много всего и сразу. Ну и фреймворки как бы просят ждать свои мажорные версии, чтоб более менее использовать новые фишки PHP, и наверно из-за своей «полноты» обновляться так быстро не могут. Может если бы разбить весь фрейморк на части, то было бы легче? Взять тот минимум который нужен для самого простого сайта и плясать от него, а все остальное в расширения, которые можно подключить через тот же композер по мере необходимости, когда ты реально устал сам делать что-то. Очень долго выходил Zend2, такая же история с Yii2, когда 3 ждать никто наверно и не знает. Ларавел вроде как раз и начал выкидывать лишнее, теперь вроде нет генератора форм, надо что-то подключать отдельно. Но это ведь не значит, что нельзя сделать сайт без генератора форм? Или без интернационализации, консольных вещей, почт и т.д.? Эти вещи больше отвлекают в начале, чем помогают по-моему. Без этого фона «у нас много чего готового» и старт был бы для всех легче. Документацию за час всю можно прочитать. За день сайт сделать и понимать что ты попробовал основную часть. За неделю/месяц посмотреть и попробовать топовые расширения и тем более все официальные(?), которые можно будет менять по необходимости. Но основа уже будет крепкая и за короткий срок.
PHP (без фреймворков, паттернов), если забыть об относительной сложности установки и настройки рабочей среды, сразу все просто было и легко. Да, для серьезных проектов такой подход очень плох, но это новички им бы в азарт тут войти, и думаю в целом лучше изучать не фреймворки, а паттерны что они несут, а потом уже плюшки что каждый фреймворк дает. Так простому новичку, и не только, очень сложно лезть в этот космический корабль со всем готовым — ты только делай как мы просим и все будет хорошо. Хорошо вроде звучит, но ооочень много всего и сразу. Ну и фреймворки как бы просят ждать свои мажорные версии, чтоб более менее использовать новые фишки PHP, и наверно из-за своей «полноты» обновляться так быстро не могут. Может если бы разбить весь фрейморк на части, то было бы легче? Взять тот минимум который нужен для самого простого сайта и плясать от него, а все остальное в расширения, которые можно подключить через тот же композер по мере необходимости, когда ты реально устал сам делать что-то. Очень долго выходил Zend2, такая же история с Yii2, когда 3 ждать никто наверно и не знает. Ларавел вроде как раз и начал выкидывать лишнее, теперь вроде нет генератора форм, надо что-то подключать отдельно. Но это ведь не значит, что нельзя сделать сайт без генератора форм? Или без интернационализации, консольных вещей, почт и т.д.? Эти вещи больше отвлекают в начале, чем помогают по-моему. Без этого фона «у нас много чего готового» и старт был бы для всех легче. Документацию за час всю можно прочитать. За день сайт сделать и понимать что ты попробовал основную часть. За неделю/месяц посмотреть и попробовать топовые расширения и тем более все официальные(?), которые можно будет менять по необходимости. Но основа уже будет крепкая и за короткий срок.
Отчасти соглашусь с вами. Но только отчасти.
Заметил недавно, что уж очень я отстал от языка и текущих веяний.
Вроде все новшества знаю, но как-то староват.
Еще в пхп4 я оброс своими библиотеками которые превращались в ЦМС (как у всех), менялись, жили своей жизнью, и вот в 2015 у меня наконец не осталось проектов живущих на чем-то старом. Почти все живые проекты на поддержке перенес на юии или ларавел.
Но тот факт что в свое время писал несколько собственных нанофреймворков очень помогало в освоении чужих.
И вот сейчас я понял, что начинаю отставать. Что уже всё немного не так.
Начал писать чисто для себя. Для восстановления понимания — новый велосипед. И я вроде понимаю, что без экосистемы я всё равно его брошу. Что скорее всего ни одного проекта я на нем не напишу. Но пишу чтобы освежить, чтобы улучшить навыки архитектуры…
Я уверен, что начинать новичку нужно с фреймворка в котором он понимает весь код. Чтобы он прочитал документацию, код, комментарии. Почитал статьи с объяснением не «как этим пользоваться» а «почему мы сделали так а не иначе».
Я уверен что тогда не будет таких детских глупостей как у топикстартера.
У меня даже появилась шальная мысль, что может в таком вот учебном контексте может этот «проект» даже и послужит и «взлетит».
Но вот всерьез считать, что голый скелет может летать — это вам в кинотеатр на Марсианина. Нет, поучиться. Блог себе нарисовать.
Сайт-визитку. «Портал». Как замена вордпрессу, да и то с такой же жирной экосистемой вокруг — это пожалуйста. Но все те «ненужные» вещи, которые в «Марсианине» отвинтили — очень даже нужны, и должны быть. И подход как у Ларавел — всё можно поставить из композера это тупик. Очень плохо когда в одной команде, на одном фреймворке везде разные подходы, библиотеки и т.п.
Заметил недавно, что уж очень я отстал от языка и текущих веяний.
Вроде все новшества знаю, но как-то староват.
Еще в пхп4 я оброс своими библиотеками которые превращались в ЦМС (как у всех), менялись, жили своей жизнью, и вот в 2015 у меня наконец не осталось проектов живущих на чем-то старом. Почти все живые проекты на поддержке перенес на юии или ларавел.
Но тот факт что в свое время писал несколько собственных нанофреймворков очень помогало в освоении чужих.
И вот сейчас я понял, что начинаю отставать. Что уже всё немного не так.
Начал писать чисто для себя. Для восстановления понимания — новый велосипед. И я вроде понимаю, что без экосистемы я всё равно его брошу. Что скорее всего ни одного проекта я на нем не напишу. Но пишу чтобы освежить, чтобы улучшить навыки архитектуры…
Я уверен, что начинать новичку нужно с фреймворка в котором он понимает весь код. Чтобы он прочитал документацию, код, комментарии. Почитал статьи с объяснением не «как этим пользоваться» а «почему мы сделали так а не иначе».
Я уверен что тогда не будет таких детских глупостей как у топикстартера.
У меня даже появилась шальная мысль, что может в таком вот учебном контексте может этот «проект» даже и послужит и «взлетит».
Но вот всерьез считать, что голый скелет может летать — это вам в кинотеатр на Марсианина. Нет, поучиться. Блог себе нарисовать.
Сайт-визитку. «Портал». Как замена вордпрессу, да и то с такой же жирной экосистемой вокруг — это пожалуйста. Но все те «ненужные» вещи, которые в «Марсианине» отвинтили — очень даже нужны, и должны быть. И подход как у Ларавел — всё можно поставить из композера это тупик. Очень плохо когда в одной команде, на одном фреймворке везде разные подходы, библиотеки и т.п.
Я немного другое имел виду. Вся IT-сфера относительно молода, еще 10-20 лет назад единицы работали с кодом, такие мозги имели чтоб понять всего с чем они работают! Сегодня только лентяй не собрал на конструкторе сайт, а некоторые даже умудрились написать «Hello world» на php или еще на чем то. Все что вложили вчера сегодня пользуется успехом, была открыта дорога для таких как я. Я не стесняюсь что мне до некоторых как до Марса, и вот такой я решил тут только свою точку зрения написать обо всем этом, возможно, да, ошибочное. Я не говорил что Yii и т.д. плохи, просто такие гиганты не для всех, чтоб сразу начать пробовать надо пройти другие этапы. Нам было легче, потому что мы более менее знакомы с большей частью паттернов, уже поняли что ООП — добро, что преждевременная оптимизация — ЗЛО и т.д. Все сами пробовали на своей шкуре, похоронили тонны кода, или кто-то ткнул носом на факты. Сейчас как я вижу молодых ребят: набросали пару скриптов, вроде сайты работают у них и хотят себе работу программистов с большой ЗП. Открывают вакансии и видят красивые ярлыки Yii, Laravel и т.д. Конечно они открывают оф. сайты начинают разбираться, делают все по документации и… все. На них такой поток данных идет, а вот мы почту шлем, а вот форму собираем, а тут собираем все через elixir, вы еще не поставили Node.js? -неудачник! А теперь вот эту зависимость, а теперь то, а теперь это. Это какой-то огромный поток реки из которой вылетают менее опытные, думая что это все не для них. Закрывают это все и забывают обо всех вакансиях в этой сфере. И вот для них я и говорю что пока рано опускать руки, надо просто изучить паттерны, а потом уже брать на вооружение то что помогает экономить время. Вот тут бы огромный плакат, баннер! Что если тяжело получается с Yii и т.д. попробуйте что легче. И такого легче очень мало и толком не ценится. Вот и пришла мысль, чтоб если один из таких гигантов выкинул все лишнее, то больше было шансов понять новичкам. Я не говорил что будут разные либы или код разный, просто будут отдельными пакетами со своей документацией, что когда надо будет прочитают все и поставят. Мы же не читали весь мануал php или mysql, а по мере необходимости. А у этих гигантов все и сразу идет. Плюс из-за этого сами неповоротливые на обновления. Вспомним Lunix! Одно ядро и кучу пакетов/приложений. Тут я тоже хотел. Оставить только то что позволит сделать простой сайт, без почты, без капчи, без форм и т.д. только каркас! Вот вышел месяц назад php7, на нем можно запускать Yii2 — хорошо! Но когда он сам будет в полной мере пользоваться новинками, а не то что добавили в php 5.4? А если бы был только каркас, то может в альфе уже был бы каркас для php 7 и остальные пакеты бы подтягивались по возможности, как между laravel 4 и 5, как между расширениями yii1 и 2.
Повторюсь, что могу ошибаться. И соглашусь что над новичками надо жестко следить, что можно разбаловать, но такой подход больше для среднего образования, после уже каждый может забросить это дело, если будет тяжело для них.
По-моему новички должны сами за добавкой приходить, а не тыкать в них все подряд.
Повторюсь, что могу ошибаться. И соглашусь что над новичками надо жестко следить, что можно разбаловать, но такой подход больше для среднего образования, после уже каждый может забросить это дело, если будет тяжело для них.
По-моему новички должны сами за добавкой приходить, а не тыкать в них все подряд.
Если использовать ту же кодовую базу, то нет смысла что-то урезать. Это уровень документации. Не описал фичу, и всё.
Где нельзя просто упустить — забутстрапили в дефолтной сборке простой пример, и можно не читать.
Вариант очень низкой связности, когда всё является внешним, всё просто может быть переписано, а должно быть использовано сторонними разработчиками это порочный путь. Равно как и бегство за свежими фичами. И дело даже не в том, что окружение (тот же хостинг) могут не поспевать за требованиями софта. Это еще полбеды. Обновимся, поменяем хостера, или запинаем поддержку. Не суть. Слишком частые обновления приводят к тому, что теряется совместимость даже у минорных версий. Сообщество не приходит к единому мнению и появляются как новые расширения для новых версий так и «со старым добрым АПИ»… Даже «медленное» развитие Юии ведет к тому, что большие проекты многие без критических обновлений не обновляют. Большая гибкость и скорость использования новых фишек имеет большой плюс когда у тебя небольшой парк проектов с коротким сроком жизни и/или частым переписыванием. А в перспективе вызывает дискомфорт.
Где нельзя просто упустить — забутстрапили в дефолтной сборке простой пример, и можно не читать.
Вариант очень низкой связности, когда всё является внешним, всё просто может быть переписано, а должно быть использовано сторонними разработчиками это порочный путь. Равно как и бегство за свежими фичами. И дело даже не в том, что окружение (тот же хостинг) могут не поспевать за требованиями софта. Это еще полбеды. Обновимся, поменяем хостера, или запинаем поддержку. Не суть. Слишком частые обновления приводят к тому, что теряется совместимость даже у минорных версий. Сообщество не приходит к единому мнению и появляются как новые расширения для новых версий так и «со старым добрым АПИ»… Даже «медленное» развитие Юии ведет к тому, что большие проекты многие без критических обновлений не обновляют. Большая гибкость и скорость использования новых фишек имеет большой плюс когда у тебя небольшой парк проектов с коротким сроком жизни и/или частым переписыванием. А в перспективе вызывает дискомфорт.
В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели. В результате чего можно было наблюдать несколько моделей из 10 000 — 15 000 строк кода, которые были связанны чуть ли не с большей половиной всего проекта. Естественно настал момент, когда все крестились и просто боялись их трогать, зная что если что-то сломают может полететь весь проект. Это не критично на небольшом проекте, но если проект набирает популярность и разрастается, ждите беды.
С таким подходом независимо от фрейма и яп будет такой результат. Yii2 не навязывает вам арихитектуру, это фреймворк в первую очередь.
Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.
Если грамотно наследоваться от коммон модели, то таких проблем практически не будет. Говорю с уверенностью тк сам практикую такой подход.
Если приложение со сложной бизнес логикой, то основную валидацию я рекомендую делать описывать в модели формы, а не в основной модели, и тогда у вас не будет ни жирных моделей, ни проблем с перекрытием, ни проблем с мертвым кодом, когда вы выпилите какую-то функциональность.
ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).Тот подход который навязывают виджеты действительно тяжеловесный, в большом и сложном проекте у вас скорее всего будут самописные (или переделанные) виджеты, тк все универсальное имеет много лишнего в угоду универсальности. JS часть виджетов нужно отключить на уровне ассетов и сгруппировать и упаковать grunt`ом например. ЭктивФорм надо уметь готовить, в процессе разработки у вас должно было появится понимаение какие и как формы используются, и уже имея понимание, нужно сделать свою обертку, благодаря которой у вас описание самыех сложных форм будет укладываться в несколько строк.
Расширения. Что касается расширений Yii2 (конечно-же от сторонних разработчиков), то 99% этих расширений решают только примитивные стандартные задачи. Если возникает суровая серьезная задача, то в 99% случаях Вам придется писать все самому.
Есть довольно качественные расширения, которые реализуют достаточно сложную функциональность, которую порой сам и за неделю не реализуешь, при этом они покрыты тестами, а разработчики активно общаются на гитхабе и принимают реквесты. Но есть и куча расширений-оберток над разными js либами и виджетами. Это есть в практически любом фреймворке. Для меня выбор расширения всегда начинается с просмотра кода, потом issues, и активности автора, лояльности на гитхабе.
Yii или там Laravel хорошие фреймворки для небольших и средних проектов, для прототипов или MVP. С ними можно добиться очень высокой скорости разработки. Но как только сложность проекта (и я не про инфраструктуру а именно про бизнес логику) увеличивается начинаются проблемы. Не потому что фреймворки в чем-то ограничивают, а как раз таки наоборот.
Новичкам нужен бандаж и строгость. Строгие стандарты, строгие практики, жесткий код ревью и т.д. Никаких «делай как удобно», «будь прагматичным» и тд. TDD и подобные практики очень хорошо подходят именно новичкам. Это уже потом, с опытом можно переключаться на инструменты которые дают больше свободы. И тогда процесс обучения станет намного проще.
Людям же кто считает что «новичкам не нужно использовать фреймворки» в корне не правы, как минимум потому что это максимальная степень свободы, а как я уже говорил выше — ночков надо держать в ежевых рукавицах.
Почему-то когда люди приходят в Ruby сообщество они начинают учить RoR, сразу же людей учат писать тесты, процессам разработки и т.д. В PHP же можно встретить людей которые за 5 лет ниразу не писали тестов.
Новичкам нужен бандаж и строгость. Строгие стандарты, строгие практики, жесткий код ревью и т.д. Никаких «делай как удобно», «будь прагматичным» и тд. TDD и подобные практики очень хорошо подходят именно новичкам. Это уже потом, с опытом можно переключаться на инструменты которые дают больше свободы. И тогда процесс обучения станет намного проще.
Людям же кто считает что «новичкам не нужно использовать фреймворки» в корне не правы, как минимум потому что это максимальная степень свободы, а как я уже говорил выше — ночков надо держать в ежевых рукавицах.
Почему-то когда люди приходят в Ruby сообщество они начинают учить RoR, сразу же людей учат писать тесты, процессам разработки и т.д. В PHP же можно встретить людей которые за 5 лет ниразу не писали тестов.
Вы наверно один из не многих, кто почти все понял, что я имел ввиду. Но еще не забывайте, что под словом «новичок», можно подрозумивать совершенно разные уровни знаний.
Например можно хорошо, знать php. Каждую функцию знать на память. Но при этом не слышать про паттерны, это новичок?
Или например можно знать php, работать с паттернами, но не разу не писать тесты, это новичок?
А можно знать php, знать паттерны, писать тесты, но не знать про DDD.
От сюда вопросы:
Что значит знать php?
и
Кто такой новичок?
Например можно хорошо, знать php. Каждую функцию знать на память. Но при этом не слышать про паттерны, это новичок?
Или например можно знать php, работать с паттернами, но не разу не писать тесты, это новичок?
А можно знать php, знать паттерны, писать тесты, но не знать про DDD.
От сюда вопросы:
Что значит знать php?
и
Кто такой новичок?
Но при этом не слышать про паттерны, это новичок?
Паттерны это больше способ общения, а не средства проектирования. Напомню что в конце 90-х было много холиваров на тему должны ли программисты знать паттерны или это несет больше вреда чем пользы. А все потому что паттерны… они просто есть. Только ближе к 2000-ым появились хоть какие-то обоснования (SOLID, GRASP) из которых можно вывести все паттерны.
То есть тут занятная ситуация, перепутались причина и следствие. Знаете вы паттерны или нет — если вы будете соблюдать принципы SOLID и понимать зачем это надо и какие преимущества дает разделение ответственности и т.д. то они у вас всеравно получатся.
Так что я не считаю что знание паттернов это обязательно для новичков.
Или например можно знать php, работать с паттернами, но не разу не писать тесты, это новичок?
Это скорее просто ленивый разработчик. Зачем тратить время на тесты если все можно проверить руками? Ну подумаешь будет много регрессий, это больше к культуре разработки относится а не к уровню знаний.
А можно знать php, знать паттерны, писать тесты, но не знать про DDD.
DDD — это способ управления сложностью. Сложностью именно бизнес логики. Как и BDD, основная соль тут — уменьшение стоимости перевода требований из языка стэкхолдеров в код. Способ устранения двусмысленности и т.д.
Помимо DDD есть еще куча вариантов как добиться ясности в описании требований и т.д. (то же BDD). Опять же есть бизнес аналитики которые могут предоставить разработчику готовую модель предметной области, которую он просто перепишет в код.
Основная соль DDD не в паттернах или там в том как вы проектируете архитектуру приложения, а в том что разработчики должны концентрировать внимание именно на потребностях бизнеса. Потому оно и называется domain-driven. Большинство же проектов имеют весьма простой домен, а значит DDD там не особо поможет. Есть проекты с дико сложной инфраструктурой и простой бизнес логикой.
Что значит знать php?
Знать PHP как средство решения проблем.
Кто такой новичок?
Человек с минимальным опытом. Вообще тут стоит прояснить что это даже не джуниор. То есть выполнять коммерческие проекты на этом уровне вообще нельзя. Даже за джуниорами нужен контроль.
Тут еще момент в том, что «Человек с минимальным опытом» может быть в конкретной области. Например человек может спокойно писать на Yii2 делая 10 средних проектов в год при этом даже не догадываясь про существования таких понятий архитектуры, которые мы обсуждаем.
У меня знакомый уже лет 5 наверно сидит на codeigniter 1.xx версии, делает интернет магазины и не знает проблем. Я смотрел на его код, там от ооп только контроллеры и модели самого CI, остальное процедурный код по 5к — 10к строк кода. Тем не менее это ему не мешает выполнять заказы для клиентов и поддерживать их. Кое-ка они там работают.
Я бы опыт разделил на этапы. Да и понятие «джуниор» для каждой так сказать конторы будет свое.
У меня знакомый уже лет 5 наверно сидит на codeigniter 1.xx версии, делает интернет магазины и не знает проблем. Я смотрел на его код, там от ооп только контроллеры и модели самого CI, остальное процедурный код по 5к — 10к строк кода. Тем не менее это ему не мешает выполнять заказы для клиентов и поддерживать их. Кое-ка они там работают.
Я бы опыт разделил на этапы. Да и понятие «джуниор» для каждой так сказать конторы будет свое.
Ну и пусть себе кодит. Для некоторых программирование это просто способ заработка. Пришел, покодил, ушел домой. И развиваются эти люди только тогда когда за это платят.
А может оно и не надо? Ну вот серьезно. Зачем мы вообще придумываем всю эту чушь? DDD, BDD, гексагональные архитектуры, микросервисы и т.д.?
А для того что бы эффективнее выполнять задачи бизнеса. Скажем обычный CRUD с толстыми контроллерами это плохая но архитектура. И в принципе у нее есть свои плюсы. Основной — если ты можешь нормализовать базу данных — ты можешь написать CRUD. То есть разработка становится дешевой, а если у нас нет сложных взаимодействий и все элементы слабо связаны друг с другом это и поддерживать не так сложно.
Я вот не так много проектов знаю где микросервисы нужны. И еще меньше проектов где нужны загоны по DDD. Они есть, их не мало, но это небольшая доля от рынка.
Те же интернет магазины — не так много владельцев магазина осознают что можно делать для повышения продаж и т.д. Покупают и здорово. А то что если бы мы практиковали какой event sourcing мы бы могли найти потенциальных покупателей больше и потом заспамить их предложениями какими-то и оптимизировать продажи — ну так это надо много думать. Зачем…
даже не догадываясь про существования таких понятий архитектуры, которые мы обсуждаем.
А может оно и не надо? Ну вот серьезно. Зачем мы вообще придумываем всю эту чушь? DDD, BDD, гексагональные архитектуры, микросервисы и т.д.?
А для того что бы эффективнее выполнять задачи бизнеса. Скажем обычный CRUD с толстыми контроллерами это плохая но архитектура. И в принципе у нее есть свои плюсы. Основной — если ты можешь нормализовать базу данных — ты можешь написать CRUD. То есть разработка становится дешевой, а если у нас нет сложных взаимодействий и все элементы слабо связаны друг с другом это и поддерживать не так сложно.
Я вот не так много проектов знаю где микросервисы нужны. И еще меньше проектов где нужны загоны по DDD. Они есть, их не мало, но это небольшая доля от рынка.
Те же интернет магазины — не так много владельцев магазина осознают что можно делать для повышения продаж и т.д. Покупают и здорово. А то что если бы мы практиковали какой event sourcing мы бы могли найти потенциальных покупателей больше и потом заспамить их предложениями какими-то и оптимизировать продажи — ну так это надо много думать. Зачем…
Он кодит, а потом проект растет и кому-то его приходится поддерживать и «чуть допилить». Может не надо?
Может сразу человеку объяснить? Не рассказать а объяснить.
Недавно собеседовал человека чтобы «белить и красить, штукатурить и еще немного вышивать» — партнеру нужен был человек который сможет поддерживать его проекты на вордпрессе, юии1, юии2 и т.п., но по мелочи.
Пообщались. Вроде нормально. Даже умные вещи говорит типа тонкий контроллер и т.п. Но слышу что не понимает.
Вычитал, но не понимает. Знает что так нужно.
Привел пару примеров из жизни, пару сферических. Дошло.
Вообще я часто сталкиваюсь с тем, что люди могут рассказать тебе как всё правильно, но ничерта не понимают.
Может сразу человеку объяснить? Не рассказать а объяснить.
Недавно собеседовал человека чтобы «белить и красить, штукатурить и еще немного вышивать» — партнеру нужен был человек который сможет поддерживать его проекты на вордпрессе, юии1, юии2 и т.п., но по мелочи.
Пообщались. Вроде нормально. Даже умные вещи говорит типа тонкий контроллер и т.п. Но слышу что не понимает.
Вычитал, но не понимает. Знает что так нужно.
Привел пару примеров из жизни, пару сферических. Дошло.
Вообще я часто сталкиваюсь с тем, что люди могут рассказать тебе как всё правильно, но ничерта не понимают.
Если дошло, надо брать :)
Вычитал, но не понимает. Знает что так нужно.
Большинство людей которые узнают о MVC действуют так же. Ну то есть MVC, модель контроллер представление. А что есть что и зачем — все путается. В итоге часть презентационной логики появляется в контроллере, модели и т.д. а логика потихоньку вытекает наружу. Все потому что люди знают что так надо но что есть что — не понимают.
Ну или там инкапсуляция — вроде простая штука, но многие разработкики ее не понимают и не могут сказать «почему этот код нарушает инкапсуляцию».
денормализовать?
Например можно хорошо, знать php. Каждую функцию знать на память. Но при этом не слышать про паттерны, это новичок?
====
Да. Новичек. Худшая форма. Не знаю и знать не хочу всех функций пхп. Мало того — часть из них знать опасно. Тянет знаете ли на велосипеды. Есть гугл, справка языка, хелпы ИДЕ. Зачем? С паттернами не так однозначно. Паттерны знать надо, не обязательно от зубов чтобы названия отскакивали и т.п. но это намного важнее чем мелкие нюансы языка. Каждый раз когда встречаю тернарный оператор я лезу в гугл. Не хочу я себе голову забивать этим. Но это не делает меня новичком. А вот патологическая склонность к велосипедостроению — делает.
Если у человека класс на 15тыс строк кода, то не важно на каком языке или фреймворке он написан, и модель это или контроллер. Ему нужно повышать свою грамотность в архитектуре. Точка.
Нет, шаблонов это не касается, хотя тоже навивает. Нет, бывает когда дедлайн и ты в чужом коде. Но так чтобы сам…
====
Да. Новичек. Худшая форма. Не знаю и знать не хочу всех функций пхп. Мало того — часть из них знать опасно. Тянет знаете ли на велосипеды. Есть гугл, справка языка, хелпы ИДЕ. Зачем? С паттернами не так однозначно. Паттерны знать надо, не обязательно от зубов чтобы названия отскакивали и т.п. но это намного важнее чем мелкие нюансы языка. Каждый раз когда встречаю тернарный оператор я лезу в гугл. Не хочу я себе голову забивать этим. Но это не делает меня новичком. А вот патологическая склонность к велосипедостроению — делает.
Если у человека класс на 15тыс строк кода, то не важно на каком языке или фреймворке он написан, и модель это или контроллер. Ему нужно повышать свою грамотность в архитектуре. Точка.
Нет, шаблонов это не касается, хотя тоже навивает. Нет, бывает когда дедлайн и ты в чужом коде. Но так чтобы сам…
Нет, бывает когда дедлайн и ты в чужом коде. Но так чтобы сам…
Рекомендую почитать заметки Мартина Фаулера на тему Tradable Quality. А еще у него есть неплохая пародия на Роберта (Дядю боба) Мартина: youtu.be/B_KIAmFZJz0?t=29m50s
Скорее всего основная проблема не в Yii как таковом, а именно в использовании ActiveRecord. Фаулер предупреждал, что годится он лишь для несложной логики домена и(или) базы и важно не пропустить момент, когда ActiveRecord усложняет разработку. Другое дело, что имеет ли смысл Yii без своей ActiveRecord?
Субъективно, главная опасность ActiveRecord — частые и большие соблазны в одном методе объединять и основную логику и работу с базой. То есть малого того, что и изначально у объекта две ответственности, так мы ещё и в каждый метод начинаем их пихать.
Субъективно, главная опасность ActiveRecord — частые и большие соблазны в одном методе объединять и основную логику и работу с базой. То есть малого того, что и изначально у объекта две ответственности, так мы ещё и в каждый метод начинаем их пихать.
Статья полна любви и обожания (с) к Симфони.
Yii удобный и практичный инструмент, не накладывающий на разработчика груз рамок и ограничений.
Низкий порог входа, логичная архитектура, удобная документация и большое грамотное сообщество.
А без опыта любой фреймворк приведет в АД. Вопрос в том, насколько просто будет из него выбраться.
Yii удобный и практичный инструмент, не накладывающий на разработчика груз рамок и ограничений.
Низкий порог входа, логичная архитектура, удобная документация и большое грамотное сообщество.
А без опыта любой фреймворк приведет в АД. Вопрос в том, насколько просто будет из него выбраться.
не накладывающий на разработчика груз рамок и ограничений.
Вот как раз таки тут Symfony предоставляет намного большую свободу. При разработке на Yii вы полностью завязываетесь на инфраструктуре этого фреймворка. Правда для большинства проектов это нормально, и собственно по этой причине многие и выбирают Yii.
Низкий порог входа, логичная архитектура, удобная документация и большое грамотное сообщество.
Опять же не соглашусь. Низкий порог входа в большинстве случаев заключается в том, что люди не дочитывают документацию и принимаются писать велосипеды. Я много раз такое видел, когда разработчики писали кастыли, не смотря на то что разработчики фреймворка уже позаботились об этом. И это обидно, потому что документация на самом деле неплохая. Но в среднем грамотность сообщества довольно низкая.
А без опыта любой фреймворк приведет в АД. Вопрос в том, насколько просто будет из него выбраться.
Полностью согласен. Без опыта и без присмотра — все выйдет плохо.
Кстате, когда я писал «Без опыта» тут как раз ввиду имелось: что без опыта работы в больших проектах, когда не знаешь, что тебя может ждать, если проект будет стремительно развиваться.
Статья неактуально для небольших и частично средненьких проектов. Я наткнулся на все проблемы yii2 именно тогда, когда проект стал все больше и больше и нужно было делать все быстрее и быстрее и все сложнее функционал.
Статья неактуально для небольших и частично средненьких проектов. Я наткнулся на все проблемы yii2 именно тогда, когда проект стал все больше и больше и нужно было делать все быстрее и быстрее и все сложнее функционал.
А если был опыт больших проектов на разных фреймворках и вообще без них, но Yii первый раз попался?
Тогда все должно быть ок, по идее. Это все-таки фреймворк, причем довольно простой.
Был просто опыт. В больших проектах нет. Я мог написать почти все, что угодно, но понятия не имел о существовании например DI, да и вообще паттернов как таковых. И на обычных сайтах сайтах это никак не мешало. Ну тоесть сделал 4 круда небольшую логику и норма. Но когда получались ситуации, когда что-то нужно доделать, добавить условия или усложнить поведения, были проблемы, переписывания и тп.
Можно сказать относительно недавно, когда я познакомился с SOLID, прочитал книжку и начал подозревать Yii в халтуре.
Но при этом я согласен, что это не проблема инструмента, а минус скорее в том, что yii не направляет в нужную сторону. И я проходил можно сказать по такому сценарию:
— В начале писал запросы и логику в контроллерах. Потом понял, что это косяк.
— Начал писать запросы и логику в статических методах модели. Чуть лучше но все равно косяк.
— Потом оказывается узнал про репозиторий и сервисы.
И этапы этого примерно года два. Так как я прост описал на yii, даже не догадываясь о проблемах. В примере с симфони, я открываю его, смотрю:
— опа, а что такое DI. Для чего он?
— опа, а зачем сервисы?
— опа,…
Должен признать, что когда я первый раз взял симфони, я подумал. Да зачем писать столько фигни, если можно уместить в 1 класс и работает в 10 раз быстрее. Но теперь я знаю ответ, что это хорошие инвестиции в будущее.
Yii это хороший инструмент, для тех кто уже хорошо знаком с вышеперечисленными штуками и понимает чего ждать. К сожалению, я пока еще не вышел на нужный уровень.
Можно сказать относительно недавно, когда я познакомился с SOLID, прочитал книжку и начал подозревать Yii в халтуре.
Но при этом я согласен, что это не проблема инструмента, а минус скорее в том, что yii не направляет в нужную сторону. И я проходил можно сказать по такому сценарию:
— В начале писал запросы и логику в контроллерах. Потом понял, что это косяк.
— Начал писать запросы и логику в статических методах модели. Чуть лучше но все равно косяк.
— Потом оказывается узнал про репозиторий и сервисы.
И этапы этого примерно года два. Так как я прост описал на yii, даже не догадываясь о проблемах. В примере с симфони, я открываю его, смотрю:
— опа, а что такое DI. Для чего он?
— опа, а зачем сервисы?
— опа,…
Должен признать, что когда я первый раз взял симфони, я подумал. Да зачем писать столько фигни, если можно уместить в 1 класс и работает в 10 раз быстрее. Но теперь я знаю ответ, что это хорошие инвестиции в будущее.
Yii это хороший инструмент, для тех кто уже хорошо знаком с вышеперечисленными штуками и понимает чего ждать. К сожалению, я пока еще не вышел на нужный уровень.
понятия не имел о существовании например DI, да и вообще паттернов как таковых
Ну так это проблема лично ваша а не фреймворка) Собственно это основная проблема большиинства разработчиков — фреймворк это центр вселенной и все чего там нет знать не надо. А расширять кругозор — зачем… и так хватает о чем беспокоиться.
прочитал книжку и начал подозревать Yii в халтуре.
Тут не халтура а сильное упрощение. Если бы вы взяли например Symfony — ситуация не сильно бы изменилась, так как пока не наступишь на грабли не поймешь обычно как надо (если рядом нет того, кто на эти грабли уже наступал).
Потом оказывается узнал про репозиторий и сервисы.
Еще одна проблема. Именование. Сервисы это не что-то такое эдакое. Это логично выносить какие-то куски в отдельные сущности, дабы не засорять систему. Декомпозиция. И тут важно понимать что дробиться система должна сверху вниз а не снизу вверх (есть и такие, да, кто начинают проектировать систему по «паттернам» с самых мелких уровней).
А ну и да, «репозитории» — в контексте ActiveRecord в них нет смысла. И жить с ActiveRecord проще если перед этим посмотреть, что было до этого. А до этого было Row Data Gateway. И смотря на код большинства проектов на Yii — AR там в большинстве случаев именно как row data gateway и использовали (анемичные модельки — просто структуры данных с возможностью их сохранить). И с Row Data Gateway описывались отдельные сущности — файдеры (Finder), просто какой-то объект, который умеет доставать наши ряды таблицы из базы. За запись же отвечают уже отдельные ряды. И в качестве упрощения предлагалось не делать отдельные объекты для файндеров, а запихивать их в статические методы-фабрики. и т.д. Репозитории же должны полностью отвечать за логику хранения данных, но по итогу понятия смешались в кучу.
Я считаю это основной проблемой индустрии. Новички не считает нужным изучать «что было до этого и как так вышло что мы используем то что используем». Какие проблемы послужили причиной тому, что придумали Data Mapper например, жили же хорошо и без него.
И этапы этого примерно года два
А вот это косяк именно PHP. Почему-то джуниорам .NET-чикам положено знать что такое Unit-of-Work, джуниоры рубисты умеют покрывать код тестами. А джуниор PHP… ну вы поняли. Культура разработки — это то что в PHP комьюнити только только начало появляться.
Но теперь я знаю ответ, что это хорошие инвестиции в будущее.
И самое сложное тут — соблюдать баланс между «надо подумать о будущем» и «а будет ли у этого куска кода будущее в принципе?».
Ну так это проблема лично ваша а не фреймворка) Собственно это основная проблема большиинства разработчиков — фреймворк это центр вселенной и все чего там нет знать не надо. А расширять кругозор — зачем… и так хватает о чем беспокоиться.
Я согласен, но тут есть один момент. Yii можно сказать не открывает глаза на эти вещи. Тоесть я себе пишу, не знаю даже что-то такое, зачем и оно мне не нужно. Пишу никого не трогаю, а потом наступаю на грабли, потому что у меня 10 000 строк кода в моделе 25 сценариев, и что бы добавить 26 сценарий мне нужно переписать пол проекта, почто еще куски кода в контроллерах.
В случае с симфони, как только открываешь этот инструмент, прямо сразу видишь DI и еще интересные вещи, и как минимум открываешь гугл, для того чтобы понять, вообще что это такое и для чего и тут пошло поехало много интересной ифы.
Именно в этом случае симфони более грамотный, так как направляет на нужный путь. В случае с yii можно просто годами писать проекты даже не зная и не сталкивая с такими терминами. Особенно если проекты не большие. Можно всю жизнь проработать генерируя груды через gii.
Но когда речь зайдет о поддержки или развитии проекта, вот тогда уже как вы говорите придет понимание. Но уже может быть поздно.
Понимаете, я видел людей которые еще не наступили на ваши грабли, брали в руки симфони, и точно так же писали километровые сервисы нарушая принцип единой ответственности, их код превращался в кашу, и опять же при добавлении 26-ого сценария приходится либо впиливать кастыли либо переписывать часть кода.
DI им позволяет только удобно дергать этот мусор в контроллерах.
DI им позволяет только удобно дергать этот мусор в контроллерах.
На самом деле это еще не так страшно. С недавних пор я устроился в контору, которая занимается разработкой и поддержкой различных зарубежны проектов. Мне попалось два проекта:
— cake2.3: вся логика в контроллерах и видах. Особенно порадовал контроллер из 10к строк кода, где было 4 метода по 1к строк, которые делали почти оно и то-же. Обрабатывали формы и сохраняли данные. (Создать, редактировать и то-же самое для админки).
— codeigniter: где проект был в 10 раз меньше, содержал 50 видов и внимание, каждый вид был отдельным html файлом. Тоесть в каждом были свои body и html.
Я очень удивился, я можно сказать впервые работаю в офисе и получил проект из западного рынка, которые написаны не просто плохо, а с максимальным количеством зла.
При этом я так и не понял, как люди, на чьем языке написаны все доки, можно сказать все родное, пишут такое?
Поэтому есть люди без опыта совсем. А есть без опыта в больших проектах, которые более менее пишут хороший код для мелких проектах. Вот например я стараюсь максимально в пределах своих возможностей сделать хороший код в yii. Тоесть разграничивать формы, поисковые модели, основные, выносить логику, чистые контроллеры и нет логики в видах. Но я всеравно чувствую дискомфорт, будто все это можно сделать более удобнее.
Скорее всего все пошло из-за того, что есть брать в пример DDD и обычную разработку, я могу написать 1 класс и все работает, в DDD придется написать 15 классов, хотя на вид разницы не будет. От сюда вопросы, зачем DDD?
Но через год, когда клиент скажет, что проанализировал проект и нужно поменять логику работы, то разработчики 1 класса начнут паниковать.
Еще я заметил, что yii очень плохо поддается принципам SOLID, по крайней мере у меня не выходит адаптировать это все дело, разве что выносить все в отдельные классы, облепливать интерфейсами и строить свою структуру.
В общем планирую после завершения текущего проекта серьезно засматриваться на симфони.
— cake2.3: вся логика в контроллерах и видах. Особенно порадовал контроллер из 10к строк кода, где было 4 метода по 1к строк, которые делали почти оно и то-же. Обрабатывали формы и сохраняли данные. (Создать, редактировать и то-же самое для админки).
— codeigniter: где проект был в 10 раз меньше, содержал 50 видов и внимание, каждый вид был отдельным html файлом. Тоесть в каждом были свои body и html.
Я очень удивился, я можно сказать впервые работаю в офисе и получил проект из западного рынка, которые написаны не просто плохо, а с максимальным количеством зла.
При этом я так и не понял, как люди, на чьем языке написаны все доки, можно сказать все родное, пишут такое?
Поэтому есть люди без опыта совсем. А есть без опыта в больших проектах, которые более менее пишут хороший код для мелких проектах. Вот например я стараюсь максимально в пределах своих возможностей сделать хороший код в yii. Тоесть разграничивать формы, поисковые модели, основные, выносить логику, чистые контроллеры и нет логики в видах. Но я всеравно чувствую дискомфорт, будто все это можно сделать более удобнее.
Скорее всего все пошло из-за того, что есть брать в пример DDD и обычную разработку, я могу написать 1 класс и все работает, в DDD придется написать 15 классов, хотя на вид разницы не будет. От сюда вопросы, зачем DDD?
Но через год, когда клиент скажет, что проанализировал проект и нужно поменять логику работы, то разработчики 1 класса начнут паниковать.
Еще я заметил, что yii очень плохо поддается принципам SOLID, по крайней мере у меня не выходит адаптировать это все дело, разве что выносить все в отдельные классы, облепливать интерфейсами и строить свою структуру.
В общем планирую после завершения текущего проекта серьезно засматриваться на симфони.
Мне попалось два проекта:
Знаете что самое замечательное в таких проектов? Там весьма примитивный код и все скатывается к банальному дублированию. А такие вещи очень легко рефакторить.
впервые работаю в офисе и получил проект из западного рынка, которые написаны не просто плохо, а с максимальным количеством зла.
То что вы описали — это цветочки. Это пожалуй 2/3 проектов так писаны. Бывает намного хуже, когда в дело идут «архитекторы», лепят там бездумно паттерны, бездумно устраняют дублирование и загоняют все в глобальные зависимости (god object например)… Рефакторить такое ад. И если в вашем случае у нас все довольно просто, мы можем покрыть интересующий нас кусок e2e тестами относительно быстро и поправить, то в этом случае перед тем, как что-то поменять важное, нужно покрыть весь проект e2e тестами (автоматический смоук).
От сюда вопросы, зачем DDD?
DDD нужен для борьбы со сложностью предметной области. Если у вас предметная область простая (нет двусмысленности, все явно и очевидно, скажем… блог или любой CRUD) — то в загонах по DDD нет смысла. Это все нужно только тогда, когда у вас бизнес логика приложения не умещается в голове. Тогда вещи типа «единого языка» и т.д. сильно помогают не потеряться и сохранить смысл того что вы делаете в коде.
Еще я заметил, что yii очень плохо поддается принципам SOLID
Ну да, потому что если соблюдать все принципы и правила, то выходит ооочень много кода. Для проектов, на которые ориентирован Yii это просто не нужно.
Адаптировать можно, в Yii2 например есть относительно сносный IoC (хотя как я выяснил им мало кто пользуется). ActiveRecord — это нормальная штука если ею правильно пользоваться, но на больших и сложных проектах лучше взять data mapper (и я не о Doctrine, это уже монстр для проектов, где вы хотите абсолютно полностью отделить ваше приложение от слоя хранения данных), вроде Isolate или Spot2. А так же придется выкинуть «модели» Yii, используемые для валидации и использовать что-то еще. Я обычно вообще валидирую только request а далее уже полагаюсь на бизнес правила и ограничения сервисного слоя.
Но если у нас реально есть необходимость в этом всем, изначально стоило брать не Yii а хотя бы Laravel или уже Symfony. Последний вообще ни в чем вас не ограничивает и позволяет легко интегрировать любые решения.
засматриваться на симфони
Опять же, симфони сам по себе кроме DI и кучи крутых компонентов ничем вам не поможет, если вы не знаете как эти компоненты использовать. А Doctrine — это самая сложная ORM из всех, и нужно потратить немало времени на ее изучение (хотя бы документацию прочитать), просто что бы понять что вы можете с ней делать. Далее уже есть целый огромный пласт знаний, который не привязан к фреймворкам и т.д.
Короче подытожу — лучше учитесь писать тесты. Сложные вещи вроде бизнес правил — покрывайте юнит тестами. Не забываем интеграционные и маленький процент e2e тестов. Еще еще и TDD/ATDD будете использовать, будет еще лучше. Мне вот нравится ограничивать разработчиков при помощи phpspec и behat.
Еще наверно можно сказать, что если хорошо освоить SOLID и следовать его принципам ну и как пример DDD, то инструмент не имеет значения. Логика инкапсулирована, все легко расширяемо. Но к сожалению, у нас такое не везде работает. В 90% нужно сделать сайт за 2 часа и сдать.
Знать и следовать правилам не всегда проходит.
Вот сейчас проект в разработке. В цейтноте проглядел что MVC-движок оказался совсем не MVC, потому что авторы явно не понимают принцип. Программист написал пару модулей, решил много задач, а потом начали подключать купленный модуль, и он не завелся. Оказывается купленный плагин с использованием некоего стороннего инструмента внедряет свой код по горячему в чужие классы. А мой боец увидев тамошний ад кода дописывал какие-то нужные функции и попутно очеловечивал код. Совместимость по возможности соблюдалась, но код был изрядно отрефакторен. Соблюдение открытости/закрытости было невозможно ввиду методов по тысяче строк в родных «контроллерах», и прочих моментах совершенно не предусматривающих расширение.
В общем подчищая после его проект и приводя ветку к виду пригодному к мержингу пришлось долго руками откатывать все нормальные правки до исходного говнокода. Простым откатом коммитов не отделаться, рефакторинг чужого кода велся им попутно с целевыми правками и входил в те же коммиты. Это конечно немного коряво, но не ожидал человек такой подставы)
Вот сейчас проект в разработке. В цейтноте проглядел что MVC-движок оказался совсем не MVC, потому что авторы явно не понимают принцип. Программист написал пару модулей, решил много задач, а потом начали подключать купленный модуль, и он не завелся. Оказывается купленный плагин с использованием некоего стороннего инструмента внедряет свой код по горячему в чужие классы. А мой боец увидев тамошний ад кода дописывал какие-то нужные функции и попутно очеловечивал код. Совместимость по возможности соблюдалась, но код был изрядно отрефакторен. Соблюдение открытости/закрытости было невозможно ввиду методов по тысяче строк в родных «контроллерах», и прочих моментах совершенно не предусматривающих расширение.
В общем подчищая после его проект и приводя ветку к виду пригодному к мержингу пришлось долго руками откатывать все нормальные правки до исходного говнокода. Простым откатом коммитов не отделаться, рефакторинг чужого кода велся им попутно с целевыми правками и входил в те же коммиты. Это конечно немного коряво, но не ожидал человек такой подставы)
Вы сейчас просто аписали ад в плане процессов… И да, когда мы говорим о MVC, то важно понимать о каком из вариантом MVC мы говорим. Классического MVC на бэкэнде нет, и все что есть — это mediating-controller MVC или MVA. Может и вправду стоит переименовать эту триаду что бы избавить новичков от мусора в голове.
когда проект стал все больше и больше и нужно было делать все быстрее и быстрее и все сложнее функционал.
Тут надо не фреймворк винить, а культуру которая сложилась вокруг него. Да и в целом в PHP. Большой проект без тестов — это уже означает что код со временем превратится в кашу, ибо чистить его будет сильно дорого.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка приложений на Yii2 без опыта — прямой путь в АД