Почему Yii/Yii2 не подходит для крупных проектов?

Question

[EvgMul]

Здравствуйте. Изучаю фреймворк Yii2 и в процессе обучения очень часто на всяческих форумах встречаю мнение о том, что Yii для больших проектов - это боль и страдания. Только вот внятных объяснений, почему это так, я не нашел.
Некоторые говорят о том, что если с самого начала делать все правильно, зная слабые моменты Yii, то и для большого проекта он подойдет.
Уважаемые разработчики, объясните пожалуйста, почему Yii слабо подходит для больших проектов, какие у него слабые места и как их решать?
Заранее благодарен всем отозвавшимся.

Comments

[DrunkMaster]

Всё подойдёт для всего если с самого начала делать всё правильно )) На этом можно и закончить обсуждение по существу )

[EvgMul]

DrunkMaster: написали чтобы написать.

[DrunkMaster]

EvgMul: Ну это ж правда. В прямых руках все инструменты хороши

[EvgMul]

DrunkMaster: кто же с вами спорит. Вы вопрос читали? Он касается конкретного фреймворка, конкретно его слабых мест. Мнение о том, что laravel для больших проектов не подходит, не распространено, а вот про Yii я на каждом углу это слышу, только внятных объяснений получить не могу. Все ответы в духе вашего первого комментария.

[kpa6uu]

EvgMul: человек потратил время, чтобы вам написать своё мнение, а вы ведётся себя как говно.

[EvgMul]

kpa6uu: действительно.

Answer 1

[Антон Иванов]

У нас в компании 4 энтерпрайзных проекта на Yii2. В том числе CRM. В том числе и связь с телефонией, 1С, баг-трекером. Всё работает отлично, без нареканий. О каких "слабых" местах вы говорите? Прекратите читать - начните делать!

Comments

[Максим Тимофеев]

100500 вам в карму

[BoShurik]

Антон А на других фреймворках есть энтерпрайзные проекты?

[Никита]

Слабое место - карма и популярность самого фреймворка. Люди считают что на нем даже новички могут писать. Но, у него маленький порог вхождения лишь из-за gii, в остальном надо неплохо так разбираться в ремесле.

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

[Casper Phantom]

>> Если у вас в Enterprise, в качестве сущностей используются AR

С учётом того что MVC лежит в Presentation Layer в DDD, то да прикольно когда AR становится Domain Layer

[evilray]

Видел сильно больше четырех проектов написанных без фреймворков, в том числе CRM. По вашей логике - фреймворки не нужны, нужно "делать".

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

То, что на yii делают такие проекты, не означает что он для них подходит.

К этому всему стоит добавить, что если вы столкнетесь с проблемами самого фреймворка, то уважаемый Александр Макаров ответит вам шаблоном "давно бы сделали пулл-реквест". Подобный подход к поддержке автоматически делает инструмент не подходящим для энтерпрайза.

[Александр Макаров]

evilray, платная поддержка для предприятий — не то же, что OpenSource. Вам уже ответили на эту тему в https://github.com/yiisoft/yii2-queue/issues/143#i...

[evilray]

Александр Макаров В моём мире существует стоимость разработки и стоимость поддержки, поддержка больших проектов на yii2 необоснованно дорогая. Из этого опыта я делаю соответствующие выводы и делюсь ими с коллегами.

При этом сайт по заказу пиццы написанный на yii2 прекрасно работает и трогать его нет ни желания ни потребности.

Answer 2

[Walt Disney]

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

Comments

[Игорь Воротнёв]

+100500 к ответу

[Casper Phantom]

>> на деле же они просто не имели понятия о проблемах с которые появляются в больших проектах.

я надеюсь эти ваши проблемы, не на фреймворк были завязаны ))

Answer 3

[Максим Федоров]

Хоть Yii и создан в первую очередь как фреймворк для быстрой разработки приложений, ничего не мешает сделать на нем крупный проект. Как сказал oxidmod Yii ничего не навязывает разработчику, в этом его плюс и минус одновременно. Если проект реализовывают профессионалы - они спокойно его сделают на Yii качественно, если новички - они спокойно заговнокодят проект. Т.е. тут вопрос только в радиусе кривизны рук. Yii реже выбирают для крупных проектов чем тот же Symfony, т.к. с точки зрения бизнеса он более оптимальный, например:
- в стандартной реализации Yii нацелен в первую очередь на скорость разработки, симфони - на качество. Соответственно в крупном проекте дешевле использовать Symfony со всеми его инструментами, чем реализовывать эти инструменты с нуля. Например, yii-шный ActiveRecord - хорош на простых проектах, но в сложных проектах он приносить больше проблем чем пользы, а в стандартной реализации никаких альтернатив ему не предусмотрено ...
- Symfony накладывает определенные правила разработки для программистов, соответственно из за этого проще внедрять на проект новых разработчиков, не боясь что они заговнокодят.
- в Yii низкий порог входа, соответственно "качество" многих разработчиков желает лучшего ...

Comments

[latteo]

>ActiveRecord - хорош на простых проектах, но в сложных проектах он приносить больше проблем чем пользы, а в стандартной реализации никаких альтернатив ему не предусмотрено

Там же есть DAO https://yiiframework.com.ua/ru/doc/guide/2/db-dao/

[Максим Федоров]

я не о том. Я имею ввиду что в больших проектах гораздо проще использовать тот же Data Mapper со всеми связующими чем AR. Хотя опять же никто не мешает это реализовать в Yii самостоятельно

[Миха Панкратов]

AR - противоречит 2 принципам SOLID, а это значит что нам будет тяжело его маштабировать и поддерживать. и я не говорю о том если мы вдруг решили подменить хранилище.

Но на самом деле AR, с легкостью можно заменить на Doctrine и работать дальше.

Но у yii2 есть и другие базовые минусы которые просто нет смысла заменять.
- роуты
- sao структура(проблемы с маштабированием частей сайта), все лучше работа на микросервисах

ЗЫ: это мое мнение сложившиеся с опытом работы

[Casper Phantom]

europanzer, на без рыбье и рак - рыба

вместо костылей там нужен напильник, пробуйте

[Nurbek Nurjanov]

Миха Панкратов, Можно узнать какой принцип СОЛИДа рушит AR ?
и чем вам не понравились роуты ?
И что вы имеете ввиду sao структура.

Не ради спора. У вас опыт, поэтому я что то конкретное могу узнать у вас.

Answer 4

[Николай Конюхов]

Есть крупный проект на Yii1, порядка 500 моделей и 300 контроллеров и 2000 вьюх. Изменений в фреймворке не делалось, при необходимости создавались наследники которые и используются по проекту вместо стандартных компонентов фреймворка. Бывают встречаются небольшие проблемы связанные с говнокодом и большим объемом данных (изменение afterFind модели, к примеру, с необоснованным использованием связей AR), которые приводили к тормозам, но это редко. Собственно, правильно спроектированный проект избавляет от многих проблем говнокода. К сожалению, не использовал другие php-фреймворки в энтерпрайзе и сравнить удобство использования не могу

Comments

[Максим Тимофеев]

цифры впечатляют

[atis //]

что то соотношение моделей к контроллерам маленькое. кожет у вас большинство контроллеров лендинги?
у меня 200+ моделей и 40 контроллеров + ~200 вьюх.

[atis //]

может*

[Николай Конюхов]

atis //: Не совсем понял, если честно, как соотношение влияет на тип контроллера

[atis //]

я могу понять как могло появится 500 моделей, а вот 300 контроллеров нет.

[atis //]

Николай Конюхов: никак. кофига их просто.

[Николай Конюхов]

atis //: адский энтерпрайз и старое приложение. Плюс еще часть кода в legacy, который неизвестно когда будет переведён на yii)

Answer 5

[Дмитрий Александров]

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

Comments

[Максим Тимофеев]

Какие хотелки сложно дописать к yii? Почему это будет костылем? Придумайте абстрактную задачу, которая в yii2 может быть реализована только костылем? Я не могу придумать.

[Дмитрий Александров]

Максим Тимофеев: я вообще то не писал конкретно про yii. Но если так то все что связанно с yii требует расширения и стиля писания как yii-way, шаг в сторону сразу расстрел на месте.
К примеру попробуйте сделать сложную форму? Ааа, вроде виджетов много но подходящего нет, пробуй написать свой виджет ииии (yii-way):
"Разрабатываемые виджеты должны быть самодостаточными. Это означает, что для их использования должно быть достаточно всего лишь добавить виджет в представление. Добиться этого бывает затруднительно в том случае, когда для его функционирования требуются внешние ресурсы, такие как CSS, JavaScript, изображения и т.д. "
Отсюда родится костыль или отхождение от стиля фреймворка.

Answer 6

[Олег Гамега]

Yii2 подходит для больших проектов(неверное =D ) но если вам не нравится возьмите другой фреймоврк, язык, что угодно
Мне например не нравится php .... никаких шуток про php программистов и тд, нет реальных претензий, просто не нравится и все. Я заказываю на нем если нужно разработку, не вижу в нем ничего ужасного, но мне ближе asp и Python

Рынок огромен. решений много и на любой вкус, ничего не мешает выбрать нужное

Answer 7

[Dmitriy Ronzhin]

1) Меня отпугивает AR. Он хорош в админке, но очень плох на пользовательской части сайта. Получать данные в виде массива не всегда удобно, т.к. уже нельзя применить какую-то бизнес логику, работать с моделями через чур накладно (например при кэшировании) и не безопасно (может кто-то во вьюхе сохранить к примеру).
2) Монолитный проект, допустим сложно проект разбить на микросервисы, всегда будет качаться компоненты связанные с базой данных, assets итд

Comments

[Максим Тимофеев]

1. Не используйте ar там где он не нужен или не удобен
2. проект можно разбить на app отдельные, само app сложно дробить, но и не надо.

[Dmitriy Ronzhin]

1. Конечно на пользовательской части использую только массивы. Что бы кэш использовать и для безопасности. Но работать с массивами не удобно, т.к. логику не реализуешь.

[Александр Калинин]

используйте Phalcon и забудьте о этих неудобствах Yii

[Nurbek Nurjanov]

Dmitriy Ronzhin, Используйте модели. И ничего не сохраняйте. Разве турдно самому себе негласно запретить ?? Раз уж хотите самому себе запретить, можно написать поведение или эвент, где beforeSave throwException сделать