Комментарии 76
Хочу заметить что
это не проблема конкретного фреймворка, также как и низкий порог вхождения.
Быстрое прототипирование, может создавать у заказчика и менеджмента иллюзию
это не проблема конкретного фреймворка, также как и низкий порог вхождения.
Да, не только конкретно Yii.
Но, на мой вкус, в сравнении с другими решениями, часто используемыми в стеке для аналогичных задач (Symfony, Zend) он лучше именно для быстрого прототипирования и легче для новичков.
Но, на мой вкус, в сравнении с другими решениями, часто используемыми в стеке для аналогичных задач (Symfony, Zend) он лучше именно для быстрого прототипирования и легче для новичков.
У меня тут нарисовалось несколько legacy проектов на Yii, которые поддерживают подрядчики, а я… ну вероятно курирую их. Так вот, у меня создалось впечатление, что некоторые особенности Yii поощряют использование «слабых» сторон PHP, ну и вообще непопулярных практик.
Например, модели с доступом через публичные поля класса, PHP шаблоны, которые буквально подначивают, чтобы в них всунули что-то не свойственное для представлений.
Повсеместное использование god object и его публичных статических полей типа \Yii::$app->{whatever}, и, как следствие на вопрос, а «где DI» — глаза как у Кота из Шрека — «нет, не видели...»
Собственно отсюда и низкий порог вхождения. И соответствующее качество на выходе.
Например, модели с доступом через публичные поля класса, PHP шаблоны, которые буквально подначивают, чтобы в них всунули что-то не свойственное для представлений.
Повсеместное использование god object и его публичных статических полей типа \Yii::$app->{whatever}, и, как следствие на вопрос, а «где DI» — глаза как у Кота из Шрека — «нет, не видели...»
Собственно отсюда и низкий порог вхождения. И соответствующее качество на выходе.
>PHP шаблоны, которые буквально подначивают, чтобы в них всунули что-то не свойственное для представлений.
Это каким таким образом?
Такое можно везде наделать при желании :)
Это каким таким образом?
Такое можно везде наделать при желании :)
Ну в Twig надо приложить смекалку, чтобы такое провернуть =)
Я вообще против дополнительных шаблонизаторов.
PHP сам отличный шаблонизатор.
С твигом не работал, но видел извращения в смарти, а иногда без них никуда. :)
PHP сам отличный шаблонизатор.
С твигом не работал, но видел извращения в смарти, а иногда без них никуда. :)
Не могу поддержать данную точку зрения (особенно в свете высказываний в стиле «не работал, но осуждаю»). Но если вас всё устраивает — пользуйтесь. Я не навязываю свою позицию.
С твигом не работал, но видел извращения в смарти, а иногда без них никуда. :)
Поработайте, шутки ради. А заодно разберитесь как оно работает. На данный момент это лучшее решение для организации шаблонизации в PHP. Одно и самый главных преимущесвт — ограничения которые оно налагает на разработчиков. Для того что бы сделать что-то не правильное надо разбираться, и для многих это повод задуматься как же все же делать правильно. Новичкам нужна смирительная рубашка, и «снимать ограничения» нужно только по мере получения опыта и понимания того с чем работаешь.
А извращения никогда не нужны. Если они нужны — значит вы где-то свернули нетуда. Хороший код должен быть скучным и предсказуемым.
p.s. Смарти ужасная штука… лет так 10 назад было прикольно, сейчас не очень.
>Новичкам нужна смирительная рубашка, и «снимать ограничения» нужно только по мере получения опыта и понимания того с чем работаешь.
Новичкам не стоит сразу лезть на фреймворки…
Целевая аудитория фреймворков — не новички ж? :)
Новичкам не стоит сразу лезть на фреймворки…
Целевая аудитория фреймворков — не новички ж? :)
Новичкам не стоит сразу лезть на фреймворки…
Разумеется, но и в коммерческую или серьезную разработку им тем более не стоит лезть. Новички первый годик должны другие вещи изучать.
Проблему как раз таки представляют разработчики, которые пару месяцев потыкали PHP, взяли какой laravel и пошли «грабить караваны» на фриланс биржах. В итоге потом во всяких gitter-сообществах лавина тупых вопросов, которые решаются прочтением документации к фреймворку или к PHP (не говоря о базовых вещах вроде алгоритмизации или работе с базами данных).
Причем в силу того что это коммерческие проекты, обычно времени на системное получение знаний не хватает, и в итоге либо человеку повезет с командой, либо он вместо года систематизированного обучения получит тот же уровень знаний годика за 3-4 таких вот тыканий.
Целевая аудитория фреймворков — не новички ж? :)
Фреймворки нужны для того что бы более эффективно подходить к разработке. Разработчик может инвестировать пару месяцев своего времени что бы разобраться во фреймворке, и это окупится за несколько проектов. Или же разработчик получит возможность влиться в команду более опытных чуваков на уже активно пилящийся проект и т.д. Словом вопрос трудозатрат и т.д.
А вот думать что фреймворки нужны просто так потому что без них не круто — это вредно, и да, такие люди тоже есть. Людей много, крайности разные бывают.
Однако же какой кайф был, когда я первый раз котлеты (разметку) отделил от мух (логики). Да, смарти был тяжёл. Но это для меня тогда был первый качественный шажок вперёд к грамотной организации кода, к созданию приложений, поддерживать и развивать которые, уже не было одной сплошной болью ))
Были не поддерживаемые тесты под Selenium, почему-то написанные на Java
Потому что раньше не было нормального драйвера под PHP. То, что было фейлило слишком часто.
Сохранилось ещё такое предание, что писались они студентом-стажёром, которого занять чем-то надо было, а кроме Java он не владел ничем =)
Как я предполагаю, год написания упомянутых тестов, вероятнее всего 2014.
Я codeception уже использовал вместе с силениумом, примерно в это время, если ничего не путаю, не помню чтобы были большие проблемы. Но там не было потенциальных сложностей для тестирования, так что может просто повезло.
Как я предполагаю, год написания упомянутых тестов, вероятнее всего 2014.
Я codeception уже использовал вместе с силениумом, примерно в это время, если ничего не путаю, не помню чтобы были большие проблемы. Но там не было потенциальных сложностей для тестирования, так что может просто повезло.
Селениум изначально Java-фреймворк. Лет 10 назад, когда вставал вопрос на чем писать тесты к API на Java мы проголосовали за Java, чтобы не париться с конвертациями. Но порог входа там конечно повыше чем в Yii, хотя традиционно (ошибочно) считается что тестировщик (в идеальном мире — инженер по качеству) должен быть не умнее программиста-джуниора.
Не, ну в 2014 всё было уже нормально. Я про 2007—2009 где-то.
Столкнулись на большом продукте с адовыми тормозами ActiveRecord и непрозрачностью DefaultScope'ов. Действительно, эти подходы годятся только для совсем маленьких сайтов.
А можно подробнее про тормоза ActiveRecord?
Вангую что тормоза не в самом ActiveRecord, а в чудовищном SQL-коде, который производят сложные relations в моделях Yii при неправильном их использовании.
Но это не Yii виноват, разумеется, а DBA проекта.
Yii, несомненно, дрянь еще та. Но не стоит перекладывать на PHP-фреймворк ответственность за кривизну архитектуры базы данных и думать, что фреймворк вам тут сейчас всё магически разрулит.
Но это не Yii виноват, разумеется, а DBA проекта.
Yii, несомненно, дрянь еще та. Но не стоит перекладывать на PHP-фреймворк ответственность за кривизну архитектуры базы данных и думать, что фреймворк вам тут сейчас всё магически разрулит.
Не зная броду, не суйся в воду
Видимо, у Вас совсем нет опыта с Yii, раз вы его так поливаете. Очень даже неплохой фреймворк. Как говорится, проблема в прокладке между рулем и сиденьем.
Вы хотите сказать, что есть возможность спроектировать реляционную БД с миллионными табличками так, что производительность сильно нагруженного приложения, построенного с применением YII AR будет сопоставима с производительностью того же приложения, использующего для доступа к данным «простые запросы»?
Если запросы из приложения на Yii будут возвращать десятки записей, т.е. фреймворку придется создавать только десятки AR, то вполне сопоставимы. Скажем так, конечный пользователь не заметит разницу.
Но если вы имеете ввиду, что запросы будут возвращать 100500+ записей, то от AR надо отказаться.
Но если вы имеете ввиду, что запросы будут возвращать 100500+ записей, то от AR надо отказаться.
если вы имеете ввиду, что запросы будут возвращать 100500+ записей, то от AR надо отказаться
От запросов таких нужно отказаться. Нет никакой необходимости тащить на сторону PHP тысячи и более записей из БД. Если же такая необходимость возникает — пора заняться аудитом архитектуры. И зарплат разработчиков.
Зачем же так категорично. Лично мне пришлось такую задачу решать. Банальный экспорт данных. Их может быть много и их надо тащить на сторону PHP.
Сперва пробовал CActiveDataProvider, таскал по 100 записей. Получилось невыносимо медленно. Переделал на CArrayDataProvider и все зашевелилось.
Сперва пробовал CActiveDataProvider, таскал по 100 записей. Получилось невыносимо медленно. Переделал на CArrayDataProvider и все зашевелилось.
Вот прям сразу аудитом архитектуры? Даже если задача свормулирована как «отобразить 100500 записей»?)
Вряд ли тот, кто ставил такую задачу, действительно хочет на одном экране видеть более 100 тысяч записей. Уточните задачу для начала ))
Бывало и такое, что нужно очень много записей на одном экране, и это именно то, что хотели те, кто ставили такую задачу. В прочем, я уверен, что разницу очень легко заметить и на меньших количествах данных, я возможно даже провести несколько синтетических тестов для установления примерного порядка этой разницы, если не обленюсь.
Конкретно в нашей команде, после названного Вами выше аудита архитектуры, мы внутри команды (не маленькой и не дешевой) пришли как-раз к тому, что от использования AR в пользовательской части системы имеет смысл отказаться, так как оверхед по ресурсам не стоит удобства, которое приносит использование данного шаблона.
Конкретно в нашей команде, после названного Вами выше аудита архитектуры, мы внутри команды (не маленькой и не дешевой) пришли как-раз к тому, что от использования AR в пользовательской части системы имеет смысл отказаться, так как оверхед по ресурсам не стоит удобства, которое приносит использование данного шаблона.
А что такого экстраординарного в «миллионных табличках»?
Даже для MySQL без всякого тюнинга таблицы на 10**6 — 10**7 записей не составляют никаких проблем. Я уж не говорю о более «взрослых» СУБД.
И да. Я не знаю, что такое «сильно нагруженное приложение» в вашем комментарии. Вы в Badoo работаете? Или в Mamba? А может быть mail.ru? Нет? А откуда у вас тогда нагрузки? Ах, от собственной же архитектуры…
Даже для MySQL без всякого тюнинга таблицы на 10**6 — 10**7 записей не составляют никаких проблем. Я уж не говорю о более «взрослых» СУБД.
И да. Я не знаю, что такое «сильно нагруженное приложение» в вашем комментарии. Вы в Badoo работаете? Или в Mamba? А может быть mail.ru? Нет? А откуда у вас тогда нагрузки? Ах, от собственной же архитектуры…
При чем тут СУБД, если мы говорим о конкретной реализации конкретного шаблона проектирования, а если точнее о ее минусах? И при чем тут мое место работы, оно как-то влияет на эту эти минусы? Я всего лишь говорю, что данная реализация не подходит для нагруженной работы с крупными данными, и у меня есть примеры, когда в продакшене от этого было реально больно. Вы утверждаете, что дело в архитектуре БД/Приложения, возможно, вы сможете привести контрпример?)
Я могу вам привести множество примеров и контрпримеров. Но, боюсь, вы меня не поймете, если для вас «количество записей в таблице» == «нагрузка»
Разговор бессмысленный.
— не тащите на сторону PHP много данных из базы, берите только необходимое
— используйте базу, как СУБД, а не как хранилище, переносите логику выборки на сторону базы
— не используйте MySQL
— не используйте без нужды сложные relations в Yii, без четкого понимания, какие именно запросы генерируются
И будет вам счастье.
А если вам вдруг мешает реализация ActiveRecord в Yii — подумайте, может в танцоре дело?
Разговор бессмысленный.
— не тащите на сторону PHP много данных из базы, берите только необходимое
— используйте базу, как СУБД, а не как хранилище, переносите логику выборки на сторону базы
— не используйте MySQL
— не используйте без нужды сложные relations в Yii, без четкого понимания, какие именно запросы генерируются
И будет вам счастье.
А если вам вдруг мешает реализация ActiveRecord в Yii — подумайте, может в танцоре дело?
Я нигде не приводил равнозначности нагрузки и количества записей в БД, прошу прощения, если неправильно формулировал.
Я ничего не имею против реализации AR в целом, я просто пытаюсь сказать, что ее использование уместно не всегда. Вы же меня как будто не слышите и тычите мне в лицо очевидными постулатами.
Я ничего не имею против реализации AR в целом, я просто пытаюсь сказать, что ее использование уместно не всегда. Вы же меня как будто не слышите и тычите мне в лицо очевидными постулатами.
>не используйте без нужды сложные relations в Yii
То есть фреймворк предназначен только для выбора примитивных данных?
Для хоумпаджей?
Кстати, Yii 1.1 не способен отобразить связанную модель связанной модели. :)
То есть фреймворк предназначен только для выбора примитивных данных?
Для хоумпаджей?
Кстати, Yii 1.1 не способен отобразить связанную модель связанной модели. :)
способен
И каким же образом можно обратиться к профилю автора в
$posts = Post::model()->with('author.profile')->findAll();
?
$posts = Post::model()->with('author.profile')->findAll();
?
вопрос уточните. В комменте вы написали про отображение связанной модели, а сейчас пишете про обращение к модели. Конкретнее кейс укажите.
Что не ясно? :)
Как вытащить данные из profile?
Как вытащить данные из profile?
неясно то, что я написал комментом ранее — вы в разных комментах по разному сформулировали проблему.
$profile = $post->author->profile;
$profile = $post->author->profile;
$post->author->profile выводит только первичный ключ
Обратиться к
$post->author->profile->name уже не выходит,
Вышло так:
$post->author->getRelated('profile')->name
Не совсем в одном стиле :)
И в документации это почему-то не отражено.
Обратиться к
$post->author->profile->name уже не выходит,
Вышло так:
$post->author->getRelated('profile')->name
Не совсем в одном стиле :)
И в документации это почему-то не отражено.
>>> $post->author->profile->name уже не выходит,
это чисто ваша какая-то проблема с описанием связи. Связи работают именно в едином стиле.
это чисто ваша какая-то проблема с описанием связи. Связи работают именно в едином стиле.
Подозреваю, что у вас поле в БД тоже называется profile (а надо называть profile_id), и при обращении читается прямое значение атрибута, а не вызывается геттер для связи.
Ну, разница в производительности выполнения одного и того же запроса, построенного через тот же command и те же criteria легко может составлять до десятка раз.
1) DefaultScope / Lifecycle Callbacks (beforeSave, afterUpdate) — зло, не используйте их никогда
2) ActiveRecord хорош до тех пор, пока вы не переборщите с магией. Как только появляются симптомы bottleneck в ActiveRecord — бежим к DataMapper/QueryBuilder
2) ActiveRecord хорош до тех пор, пока вы не переборщите с магией. Как только появляются симптомы bottleneck в ActiveRecord — бежим к DataMapper/QueryBuilder
1) Слишком категоричное утверждение. DefaultScope является хорошим решение для некоторых кейсов. before / after стоит использовать с осторожностью, но в некоторых случая они бывают полезны. Инструмент не зло, а помощник, если им владеть. В той же doctrine, event based hooks имеют место быть, у событий есть свои сценарии применения, полезности и сложности.
2) С магией всегда стоит быть осторожным, на то она и магия) Я стараюсь избегать.
2) С магией всегда стоит быть осторожным, на то она и магия) Я стараюсь избегать.
Ага, запустили проект так, что-то изменили, а тут вдруг появились бутылочные горлышки.
Нужно все переписывать.
Это типа строили дом, а потом его нужно сломать и заново построить :)
Шикарно.
Архитектура на все 100.
А, ну да, хоумпаджи с такими проблемами не столкнутся, что намекает на что расчитан AR.
Нужно все переписывать.
Это типа строили дом, а потом его нужно сломать и заново построить :)
Шикарно.
Архитектура на все 100.
А, ну да, хоумпаджи с такими проблемами не столкнутся, что намекает на что расчитан AR.
+100500 про маленькие сайты.
Не знаю, почему минусуют :)
Не знаю, почему минусуют :)
Я бы не сказал, что у Yii низкий порог входа. Как ни крути, но для работы с фреймворком нужно хотя бы немного понимать ООП, знать некоторые паттерны, научиться генерировать модели. Новичок вряд ли сможет осознанно разработать приложение, разве что поставить и запустить, как делают с CMS.
У Yii есть три очень весомых преимущества — хорошая документация, качество фреймворка и большое сообщество. Первое и второе способствует привлечению новых программистов и познанию фреймворка. Третье — грамотным консультациям, разработке новых дополнений и переработке фреймворка. На выходе мы получаем хороший и популярный продукт.
Здесь стоит кинуть палку в сторону Angular. Документация никакая, сообщество маленькое. Как результат имеем скверный фреймворк и малое количество специалистов.
У Yii есть три очень весомых преимущества — хорошая документация, качество фреймворка и большое сообщество. Первое и второе способствует привлечению новых программистов и познанию фреймворка. Третье — грамотным консультациям, разработке новых дополнений и переработке фреймворка. На выходе мы получаем хороший и популярный продукт.
Здесь стоит кинуть палку в сторону Angular. Документация никакая, сообщество маленькое. Как результат имеем скверный фреймворк и малое количество специалистов.
Но простите, репо angular1 48,787 звезд, yii2 7,957. Более того, angular распространен повсеместно, а yii2 большей частью на территории СНГ.
Относительно минусов yii2, главным на мой взгляд минусом является гвоздями приколоченное ActiveRecord и отсутствие в документации инструкций по интеграции DataMapper, что влечет за собой непопулярность TDD\DI\DDD практик в сообществе.
Так же к минусам (а возможно и к плюсам) следует отнести явную нацеленность фреймворка на прототипы, об этом говорит обилие странных виджетов, вроде Pjax\Modal\Nav\Carousel, полезных на этапе прототипа, но слишком сложных в кастомизации для продакшена.
Относительно минусов yii2, главным на мой взгляд минусом является гвоздями приколоченное ActiveRecord и отсутствие в документации инструкций по интеграции DataMapper, что влечет за собой непопулярность TDD\DI\DDD практик в сообществе.
Так же к минусам (а возможно и к плюсам) следует отнести явную нацеленность фреймворка на прототипы, об этом говорит обилие странных виджетов, вроде Pjax\Modal\Nav\Carousel, полезных на этапе прототипа, но слишком сложных в кастомизации для продакшена.
мне понравилась фраза автора статьи про «прототип выкидывать». Yii — RAD-фреймворк, и действительно хорош для прототипирования: набросали, нагенерили — работает. А дальше начинаем программировать с нуля на инструменте без навязанной архитектуры. Рядовой же член сообщества Yii уверен, что фреймворк популярен из-за своего качества и удобства и подходит для любых задач, ничего не знает о техническом долге, и ничего не слышал о ddd/solid/tdd. И продолжает набивать в модель следующую тысячу строк: «ну не еще же один класс создавать»/«сервис? это сложно!».
немного понимать ООП и научиться тыкать кнопки — это и есть низкий порог входа. Знать некоторые паттерны для yii не надо.
Именно этот низкий порог и способствует наряду с хорошей документацией привлечению новых программистов, но ни в коем случае не качество. Если фреймворк и работает, то уровень 99% сторонних расширений ниже плинтуса. И все это опять же следствие низкого порога. Низкий порог => большое сообщество программистов низкого уровня. Популярность всегда напрямую коррелирует с уровнем. Это просто данность.
Именно этот низкий порог и способствует наряду с хорошей документацией привлечению новых программистов, но ни в коем случае не качество. Если фреймворк и работает, то уровень 99% сторонних расширений ниже плинтуса. И все это опять же следствие низкого порога. Низкий порог => большое сообщество программистов низкого уровня. Популярность всегда напрямую коррелирует с уровнем. Это просто данность.
Кодеры и под этот порог не подходят. А их очень и очень много.
Развернуть прототип действительно может программист начального уровня, но написать нормальное приложение — нет.
Yii подходит для большинства задач. Ведь в большинстве своем сайты достаточно просты (визитки, корп-порталы, простые crm).
Если система достаточно сложна, естественно, используют другие решения. Да и уровень задействованных программистов гораздо выше.
Развернуть прототип действительно может программист начального уровня, но написать нормальное приложение — нет.
Yii подходит для большинства задач. Ведь в большинстве своем сайты достаточно просты (визитки, корп-порталы, простые crm).
Если система достаточно сложна, естественно, используют другие решения. Да и уровень задействованных программистов гораздо выше.
>знать некоторые паттерны, научиться генерировать модели
Можно поподробнее?
Можно поподробнее?
Ну совсем новичкам вообще не стоит начинать с фреймворков.
Выростут неумехи не знающие ни фреймворка, ни языка, не умеющие ступит и шагу самостоятельно.
Выростут неумехи не знающие ни фреймворка, ни языка, не умеющие ступит и шагу самостоятельно.
А как вы видите перспективы фреймворка Yii (пока второй версии) в будущем? В беседах с коллегами по цеху, всплывает тема, что это умирающий фреймворк, имеет ли смысл начинать учить его сейчас?
Добрый вечер!
Интересная статья, понравилась.
Сейчас работаю над крупным строительным порталом(пользователи, компании, товары, лоты, комментарии, статьи, монетизация, личные сообщения и т.д.), который уже разрабатывается год. Никаких тестов там не используется и я подумываю начать покрывать тестами имеющийся функционал, чтобы спокойно двигаться дальше.
В связи с этим прошу совета, с чего лучше начать покрытие теста подобного проекта. Опыт в тестировании совсем незначительный, поэтому важно Ваше мнение.
Спасибо!
Интересная статья, понравилась.
Сейчас работаю над крупным строительным порталом(пользователи, компании, товары, лоты, комментарии, статьи, монетизация, личные сообщения и т.д.), который уже разрабатывается год. Никаких тестов там не используется и я подумываю начать покрывать тестами имеющийся функционал, чтобы спокойно двигаться дальше.
В связи с этим прошу совета, с чего лучше начать покрытие теста подобного проекта. Опыт в тестировании совсем незначительный, поэтому важно Ваше мнение.
Спасибо!
Скорее всего, если код писался на протяжении года без тестов, с ним в нагрузку идёт существенный технический долг, и он будет сопротивляться тестированию. Учитывайте, что одно из главных преимуществ unit-тестирования, не в верификации правильности программы (этим QA-инженеры должны заниматься или профессиональные тестировщики), а в том, что тесты улучшают архитектуру приложения на уровне кода. Иными словами, чтобы код был тестируемым, Вы будете вынуждены делать его более модульным, менее связанным и простым.
Покрывать тестами существующий код, без хорошего опыта в тестировании и существенного рефакторинга, может оказаться невыполнимой задачей.
Возможно, на первом этапе, будет проще попробовать новый функционал писать через тесты: сперва тесты — потом код.
Рекомендую так же, если ещё не читали, почитать книгу Кента Бека: очень доходчивая методичка о разработке через тестирование на простых и очевидных примерах.
Покрывать тестами существующий код, без хорошего опыта в тестировании и существенного рефакторинга, может оказаться невыполнимой задачей.
Возможно, на первом этапе, будет проще попробовать новый функционал писать через тесты: сперва тесты — потом код.
Рекомендую так же, если ещё не читали, почитать книгу Кента Бека: очень доходчивая методичка о разработке через тестирование на простых и очевидных примерах.
Очевидно же, с того, что чаще всего используется… :)
Так дело в том, что Yii рекомендует жирные модели:
www.yiiframework.com/doc/guide/1.1/ru/basics.best-practices#sec-2
:)
www.yiiframework.com/doc/guide/1.1/ru/basics.best-practices#sec-2
:)
Вы лукавите, выдёргивая один тезис из контекста. Там же написано:
Далее идёт пример разделения ожиревшей модели при помощи наследования. Но, как я писал и статье, композиция предпочтительнее наследования, хотя и несколько сложнее в реализации.
Иногда следование последнему правилу делает модель очень толстой, то есть содержащей очень много кода в одном классе. Это может привести к трудностям поддержки кода в том случае, если модель используется для выполнения различных задач.… Для небольших и средних приложений это допустимо. Для крупных же приложений в целях упрощения дальнейшей поддержки кода можно сделать следующее:
Далее идёт пример разделения ожиревшей модели при помощи наследования. Но, как я писал и статье, композиция предпочтительнее наследования, хотя и несколько сложнее в реализации.
В стате почему-то смешаны лучшие практики с личным опытом, не совсем касающимся этих практик :)
>Программируйте с использованием языка, а не на языке.
Во-во. А то выростают программисты на одном фреймворке, не меющие шагу самостоятельно ступить без костылей. :)
Во-во. А то выростают программисты на одном фреймворке, не меющие шагу самостоятельно ступить без костылей. :)
Из всех критикующих комментариев складывается впечатление, как будто Yii всей своей сущностью и натурой заставляет программиста писать неэффективный/буксующий код, а все остальные фреймворки — нет. По-моему все зависит от программиста, его компетенции в PHP в целом и в Yii в частности!
Как говорится, нечего на зеркало кивать, коли рожей не вышел.
Как говорится, нечего на зеркало кивать, коли рожей не вышел.
Нет конечно, но разработчики люди ленивые, и если брать новичков — они редко задаются вопросом «правильно ли я делаю». Если чего-то нет из коробки или какой-то подход не навязывается фреймворком будут делать как попало. Добавить к этому простоту самого фреймворка (низкий порог входа если хотите) и получается совсем плохо. Причем потом слышишь от этих людей фразы в духе «контейнер зависимостей хуже для тестирования».
В руках сильного разработчика Yii вполне себе годный фреймворк. Либо под контролем сильного разработчика. Но только как правило у этого сильного разработчика Yii далеко не первый фреймворк и он знает когда оно хорошо а когда не очень.
В руках сильного разработчика Yii вполне себе годный фреймворк. Либо под контролем сильного разработчика. Но только как правило у этого сильного разработчика Yii далеко не первый фреймворк и он знает когда оно хорошо а когда не очень.
Все фреймворки заставляют писать буксующий код :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii: лучшие практики