Обновить

Комментарии 31

Можно надеяться, что после этого все силы разработчиков пойдут на 2.0/2.1?
Да.
НЛО прилетело и опубликовало эту надпись здесь
Да. Тестами поломавшаяся у вас часть покрыта? issue есть на GitHub? Если знаете как фиксить, помогайте. Только мелкими кусочками. Сразу огромные порции кода очень тяжело проверить.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Есть «Да» которое покрывает данный кейс.
«переводить свои проекты» слишком мягко сказано для данного случая, скорее все таки переписывать, потому и процент желающих не так уж велик несмотря на все преимущества
Переписывать это г-но, называемое проектом, все равно нужно.
Но вот разумных причин делать это на Yii 2 не наблюдается
На Yii 1.1 будете переписывать? :)
Вообще без Yii.

Одна из причин, хотя далеко не единственная, почему это стало «г-ном», как раз Yii на котором его изначально писали.

Так что может быть Symfony, а может быть Zend
НЛО прилетело и опубликовало эту надпись здесь
Вы бы лучше спросили что хорошего…

Дублирование методов реализации функционала. Практически повсеместно (расширения/модули, виджеты/компоненты)
Активная привязка и поощрение использовать AR.
Фильтры, которые не фильтры.

Кстати, в самом фреймворке откровенно встречается китайский(индуский) код. Искать сейчас лень, но когда в очередной раз погружусь в него, то, если не забуду, пример выложу.
НЛО прилетело и опубликовало эту надпись здесь
Вас никто не заставляет его использовать.


В Yii2 есть что-нибудь типа ларавелевский FormRequest-ов? Ну мол что бы отделить валидацию данных запроса от бизнес объектов?

В целом проблема в том что обычно люди используют то что есть, а не то что надо в данной конкретной ситуации. Тут уже была рядом дискуссия на эту тему, что AR подходит далеко не для всех задач, но есть «фанаты» которые просто не знают о других подходах.
Да, валидация не в AR, конечно, есть. Можно использовать не AR-модель, а можно вообще без модели.
Вы об этом? Ну то есть надо замэпить данные на какого-то наследника Model, сделать например MyActionRequest < — Model, замэпить руками параметры реквеста (благо это просто), провалидировать… Как собственно это и происходило в Yii1.1.
Это справедливо для версии 1.1. В 2.0 не сказать что координально изменилась ситуация, но хотя бы есть IoC и можно писать нормально, если приложить усилия. Потому без жесткого код ревью давать новичку в руки Yii я бы не стал (ну и Laravel туда же). В прочем это справедливо для любого PHP фреймворка.

Спасает только то, что новички обычно пишут весьма простой говнокод, который вполне себе поддается рефакторингу.
Именно. На любом фреймворке можно превратить проект в неперевариваемую субстанцию.
Ну… в Yii1.1 приходилось прикладывать слишком много усилия что бы сделат так как я хочу, а не как заложено фреймворком. Банально много бойлерплейта. С 2.0 ситуация конечно получше (насколько я могу судить бегло пробежавшись по документации).
Бессмысленно, хотя бы в силу того, что когда вы ещё только начинали подвизаться на стезе Yii (помню ещё по Винграду) опыт работы с легаси кодом у меня уже был.
А с фреймворками? Инструмент так и так обвиняешь после заваленного проекта. Я за собой тоже замечал.
С фреймворками тоже нормально (Codeigniter, ZF оба, Kohana, Symfony 2)
И это не «мой» проект и он не завален ещё :) я получил то, что хотел — сложную кучу дерьма.

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

Но это не отменяет факт — одна из причин именно фреймворк и то, к чему он подталкивает, например, зенд страдал от раздутых контроллеров далеко не в одном проекте.

Я даже примерно понимаю откуда родились все эти scopes, behaviors etc. в самом Yii вместе с сценариями и событиями.
Писало как минимум несколько людей без четкого проектирования. Или было желание попробовать каждую новую «фишку».
А, ну так legacy оно legacy и есть. Мне тоже такие проекты доставались, вытягивали. Попробовать каждую фишку и использовать её по делу и без — это болячка распространённая. С любым фреймворком выходит боком.
Надо развивать культуру разработки, а не фреймворками меряться.
Верно. Я этим занимаюсь в меру сил и возможностей.
Yii мой любимый фреймворк (после ASP.NET MVC) на котором мной написано множество проектов, думаю что обновлять сайты клиентов за счет своего рабочего времени не буду, они и так работают отлично, за поддержку php7 отдельное спасибо, т.к. я просто обновлю версию фреймворка без изменения кода проекта, это ещё лет на 5-10 продлит жизнь сайтам написанным под yii1.1
обновлять сайты клиентов за счет своего рабочего времени не буду


а как же обновления безопасности? Не? Ну ладно.
Фреймворк достаточно защищен, это не Wordpress какой-нибудь, я и сам иногда свои фичи добавляю чтобы усилить безопасность сайтов, так что обновление существующих проектов ради обновления с переписыванием кода и овер 20-30 рабочего времени это не про меня, заплатят за работу обновлю, не заплатят — не обновлю, да и свои собственные проекты пока не спешу обновлять )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации