Я давненько по рабочей необходимости перебрался на laravel5, однако продолжаю следить, как там у Yii2 дела продвигаются, так вот возможно я что-то пропустил или не знаю, но есть следующий список фитч, которых нет в (или я об этом не знаю):
Seeds: — возможность наполнения базы данных тестовыми данными. В Yiii2 такое можно делать в миграциях, однако в laravel5 это сделанно в виде отдельной команды, что дает возможность получить как голую схему базы данных, так и заполнить ее тестовыми данными.
Composers: — весьма интересная штука, которая позволяет внедрять данные в одну и/или более вьюшек. Что-то похожее на виджеты, такой себе класс, который может содержать логику и передать некоторые данные в вид. Что бывает удобно, например когда нужно передать одни и те-же данные в несколько страниц.
Middleware: — во круг этого крутилось множество обсуждений, но я упустил конкретный ответ. Все останется по прежнему, тоесть поведения (фильтры и тп.) или все-же Middleware будут жить в Yii2?
(хеш тег: Yii2, give a chance to Middleware)
Requests: — спорная штука, но иногда удобно. Во первых вынос валидации из модели в отдельный спец. класс, а во вторых можно сделать так, что пока валидация не пройдет, мы даже до экшина не дойдем.
И так-же присоединяюсь к тому, что нужно разбить Yii2 на отдельные компоненты. Что мне нравится в этом инструменте, что почти о любом наркоманстве, о котором я могу подумать, оно уже есть. Я имею ввиду хелперы или вспомогательные методы (например сравнение 2 объектов активрекорд https://github.com/yiisoft/yii2/issues/9036, equals вместо === и много еще чего интересного в хорошем смысле).
Однако по факту есть разные области применения Yii2 и не всегда это просто сайт. что делает более 50% функционала просто не нужными в зависимости от определенных ситуаций.
В общем было бы здорово получить комментарии от разработчиков по теме.
А как было бы хуже:
1) Отсутствие ключа и абстрактное entity_id
или
2) Перечисление всех полей для джоина на другие таблицы: student_id, instructor_id, tester_id, но с ключами.
Тогда еще пользуясь случаем спрошу про полиморфические связи. Вроде в Yii2 такой реализации нет, но вот в Laravel5 сделали. Тоесть смысл такой, что есть entity_id и type. Type это алиас, который соответствует определенной таблице, а entity_id соответственно идентификатор сущности. Тогда появляется возможность джоинить разные данные из других таблиц.
Но остается такая задняя мысль, что по скольку нет возможности поставить внешний ключ, мы не можем гарантировать целостность базы и пользоваться фишечками типа каскад, делет и тп. На сколько это вообще оправданный функционал?
Вообще как я понял лучше всего завернуть все в репозитории и вообще инкапсулировать все ваши запросы. Тогда разницы на чем вы их пишите не будет. Так как если, что-то просядет, мы быстренько подменим реализацию на другой репозиторий и все должно отработать как следует.
+ Как многие утверждают: за ранее мы не можем узнать, что и где просядет при нагрузках. Тоесть подстава может быть в самом простом запросе счетчика.
Кстате по поводу WHERE IN, в laravel5 так-же используется такой подход, при этом в Yii2 есть with и joinWith.
Так вот вопрос: WHERE IN используется в основном вместо join для того, чтобы было легче написать код билдера и отойти от некоторых багов при этом производительность примерно одинаковая (что JOIN, что WHERE IN)?
<?php
final class Money
{
private $amount;
public function getAmount()
{
return $this->amount;
}
public function add($amount)
{
return new self($this->amount + $amount, $this->currency);
}
}
Я что-то не понял? Или откуда тут взялся $this->currency?
Только еще один момент, отправка email может занимать достаточно долгое времени в некоторых ситуациях. Лучше бы это дело отправлять в фоне (или в очереди). Но далеко не все разработчики Yii2 знают про существование очередей или командной шины.
Так походу основной смысл в том, что под словом Модель подразумевается не просто один класс. Это еще не учитывая того, что почти все пихают логику в котроллер. Хотя я иногда тоже так делаю, если ее не больше 20 строк.
Нужен инструмент, который будет жестко контролировать действия разработчика =).
Еще наверно можно сказать, что если хорошо освоить SOLID и следовать его принципам ну и как пример DDD, то инструмент не имеет значения. Логика инкапсулирована, все легко расширяемо. Но к сожалению, у нас такое не везде работает. В 90% нужно сделать сайт за 2 часа и сдать.
На самом деле это еще не так страшно. С недавних пор я устроился в контору, которая занимается разработкой и поддержкой различных зарубежны проектов. Мне попалось два проекта:
— cake2.3: вся логика в контроллерах и видах. Особенно порадовал контроллер из 10к строк кода, где было 4 метода по 1к строк, которые делали почти оно и то-же. Обрабатывали формы и сохраняли данные. (Создать, редактировать и то-же самое для админки).
— codeigniter: где проект был в 10 раз меньше, содержал 50 видов и внимание, каждый вид был отдельным html файлом. Тоесть в каждом были свои body и html.
Я очень удивился, я можно сказать впервые работаю в офисе и получил проект из западного рынка, которые написаны не просто плохо, а с максимальным количеством зла.
При этом я так и не понял, как люди, на чьем языке написаны все доки, можно сказать все родное, пишут такое?
Поэтому есть люди без опыта совсем. А есть без опыта в больших проектах, которые более менее пишут хороший код для мелких проектах. Вот например я стараюсь максимально в пределах своих возможностей сделать хороший код в yii. Тоесть разграничивать формы, поисковые модели, основные, выносить логику, чистые контроллеры и нет логики в видах. Но я всеравно чувствую дискомфорт, будто все это можно сделать более удобнее.
Скорее всего все пошло из-за того, что есть брать в пример DDD и обычную разработку, я могу написать 1 класс и все работает, в DDD придется написать 15 классов, хотя на вид разницы не будет. От сюда вопросы, зачем DDD?
Но через год, когда клиент скажет, что проанализировал проект и нужно поменять логику работы, то разработчики 1 класса начнут паниковать.
Еще я заметил, что yii очень плохо поддается принципам SOLID, по крайней мере у меня не выходит адаптировать это все дело, разве что выносить все в отдельные классы, облепливать интерфейсами и строить свою структуру.
В общем планирую после завершения текущего проекта серьезно засматриваться на симфони.
Ну так это проблема лично ваша а не фреймворка) Собственно это основная проблема большиинства разработчиков — фреймворк это центр вселенной и все чего там нет знать не надо. А расширять кругозор — зачем… и так хватает о чем беспокоиться.
Я согласен, но тут есть один момент. Yii можно сказать не открывает глаза на эти вещи. Тоесть я себе пишу, не знаю даже что-то такое, зачем и оно мне не нужно. Пишу никого не трогаю, а потом наступаю на грабли, потому что у меня 10 000 строк кода в моделе 25 сценариев, и что бы добавить 26 сценарий мне нужно переписать пол проекта, почто еще куски кода в контроллерах.
В случае с симфони, как только открываешь этот инструмент, прямо сразу видишь DI и еще интересные вещи, и как минимум открываешь гугл, для того чтобы понять, вообще что это такое и для чего и тут пошло поехало много интересной ифы.
Именно в этом случае симфони более грамотный, так как направляет на нужный путь. В случае с yii можно просто годами писать проекты даже не зная и не сталкивая с такими терминами. Особенно если проекты не большие. Можно всю жизнь проработать генерируя груды через gii.
Но когда речь зайдет о поддержки или развитии проекта, вот тогда уже как вы говорите придет понимание. Но уже может быть поздно.
Был просто опыт. В больших проектах нет. Я мог написать почти все, что угодно, но понятия не имел о существовании например DI, да и вообще паттернов как таковых. И на обычных сайтах сайтах это никак не мешало. Ну тоесть сделал 4 круда небольшую логику и норма. Но когда получались ситуации, когда что-то нужно доделать, добавить условия или усложнить поведения, были проблемы, переписывания и тп.
Можно сказать относительно недавно, когда я познакомился с SOLID, прочитал книжку и начал подозревать Yii в халтуре.
Но при этом я согласен, что это не проблема инструмента, а минус скорее в том, что yii не направляет в нужную сторону. И я проходил можно сказать по такому сценарию:
— В начале писал запросы и логику в контроллерах. Потом понял, что это косяк.
— Начал писать запросы и логику в статических методах модели. Чуть лучше но все равно косяк.
— Потом оказывается узнал про репозиторий и сервисы.
И этапы этого примерно года два. Так как я прост описал на yii, даже не догадываясь о проблемах. В примере с симфони, я открываю его, смотрю:
— опа, а что такое DI. Для чего он?
— опа, а зачем сервисы?
— опа,…
Должен признать, что когда я первый раз взял симфони, я подумал. Да зачем писать столько фигни, если можно уместить в 1 класс и работает в 10 раз быстрее. Но теперь я знаю ответ, что это хорошие инвестиции в будущее.
Yii это хороший инструмент, для тех кто уже хорошо знаком с вышеперечисленными штуками и понимает чего ждать. К сожалению, я пока еще не вышел на нужный уровень.
Кстате, когда я писал «Без опыта» тут как раз ввиду имелось: что без опыта работы в больших проектах, когда не знаешь, что тебя может ждать, если проект будет стремительно развиваться.
Статья неактуально для небольших и частично средненьких проектов. Я наткнулся на все проблемы yii2 именно тогда, когда проект стал все больше и больше и нужно было делать все быстрее и быстрее и все сложнее функционал.
Я вот читаю и плачу. Я примерно так-же начинал. Тоесть конечно не на таком серьезном проекте, но постоянно когда писал проект, появлялся опыт и я понимал, что все это говно и нужно переписывать с 0 и так циклично.
Но тут вопрос, что лучше: Хоть как-то или вообще никак?
Я дочитал до «Перфекционизм» и вспомнил себя. Как когда начинал, всегда стремился к идеалу, а опыта не хватало и каждый раз все переписывал и в результате остался не с чем (ну может чуть опыта больше).
И «притча» в тему:
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
Так вообще интересная история, во многом узнал себя.
Seeds: — возможность наполнения базы данных тестовыми данными. В Yiii2 такое можно делать в миграциях, однако в laravel5 это сделанно в виде отдельной команды, что дает возможность получить как голую схему базы данных, так и заполнить ее тестовыми данными.
Composers: — весьма интересная штука, которая позволяет внедрять данные в одну и/или более вьюшек. Что-то похожее на виджеты, такой себе класс, который может содержать логику и передать некоторые данные в вид. Что бывает удобно, например когда нужно передать одни и те-же данные в несколько страниц.
Middleware: — во круг этого крутилось множество обсуждений, но я упустил конкретный ответ. Все останется по прежнему, тоесть поведения (фильтры и тп.) или все-же Middleware будут жить в Yii2?
(хеш тег: Yii2, give a chance to Middleware)
Requests: — спорная штука, но иногда удобно. Во первых вынос валидации из модели в отдельный спец. класс, а во вторых можно сделать так, что пока валидация не пройдет, мы даже до экшина не дойдем.
И так-же присоединяюсь к тому, что нужно разбить Yii2 на отдельные компоненты. Что мне нравится в этом инструменте, что почти о любом наркоманстве, о котором я могу подумать, оно уже есть. Я имею ввиду хелперы или вспомогательные методы (например сравнение 2 объектов активрекорд https://github.com/yiisoft/yii2/issues/9036, equals вместо === и много еще чего интересного в хорошем смысле).
Однако по факту есть разные области применения Yii2 и не всегда это просто сайт. что делает более 50% функционала просто не нужными в зависимости от определенных ситуаций.
В общем было бы здорово получить комментарии от разработчиков по теме.
1) Отсутствие ключа и абстрактное entity_id
или
2) Перечисление всех полей для джоина на другие таблицы: student_id, instructor_id, tester_id, но с ключами.
Но остается такая задняя мысль, что по скольку нет возможности поставить внешний ключ, мы не можем гарантировать целостность базы и пользоваться фишечками типа каскад, делет и тп. На сколько это вообще оправданный функционал?
+ Как многие утверждают: за ранее мы не можем узнать, что и где просядет при нагрузках. Тоесть подстава может быть в самом простом запросе счетчика.
Так вот вопрос: WHERE IN используется в основном вместо join для того, чтобы было легче написать код билдера и отойти от некоторых багов при этом производительность примерно одинаковая (что JOIN, что WHERE IN)?
Я что-то не понял? Или откуда тут взялся $this->currency?
Нужен инструмент, который будет жестко контролировать действия разработчика =).
— cake2.3: вся логика в контроллерах и видах. Особенно порадовал контроллер из 10к строк кода, где было 4 метода по 1к строк, которые делали почти оно и то-же. Обрабатывали формы и сохраняли данные. (Создать, редактировать и то-же самое для админки).
— codeigniter: где проект был в 10 раз меньше, содержал 50 видов и внимание, каждый вид был отдельным html файлом. Тоесть в каждом были свои body и html.
Я очень удивился, я можно сказать впервые работаю в офисе и получил проект из западного рынка, которые написаны не просто плохо, а с максимальным количеством зла.
При этом я так и не понял, как люди, на чьем языке написаны все доки, можно сказать все родное, пишут такое?
Поэтому есть люди без опыта совсем. А есть без опыта в больших проектах, которые более менее пишут хороший код для мелких проектах. Вот например я стараюсь максимально в пределах своих возможностей сделать хороший код в yii. Тоесть разграничивать формы, поисковые модели, основные, выносить логику, чистые контроллеры и нет логики в видах. Но я всеравно чувствую дискомфорт, будто все это можно сделать более удобнее.
Скорее всего все пошло из-за того, что есть брать в пример DDD и обычную разработку, я могу написать 1 класс и все работает, в DDD придется написать 15 классов, хотя на вид разницы не будет. От сюда вопросы, зачем DDD?
Но через год, когда клиент скажет, что проанализировал проект и нужно поменять логику работы, то разработчики 1 класса начнут паниковать.
Еще я заметил, что yii очень плохо поддается принципам SOLID, по крайней мере у меня не выходит адаптировать это все дело, разве что выносить все в отдельные классы, облепливать интерфейсами и строить свою структуру.
В общем планирую после завершения текущего проекта серьезно засматриваться на симфони.
Я согласен, но тут есть один момент. Yii можно сказать не открывает глаза на эти вещи. Тоесть я себе пишу, не знаю даже что-то такое, зачем и оно мне не нужно. Пишу никого не трогаю, а потом наступаю на грабли, потому что у меня 10 000 строк кода в моделе 25 сценариев, и что бы добавить 26 сценарий мне нужно переписать пол проекта, почто еще куски кода в контроллерах.
В случае с симфони, как только открываешь этот инструмент, прямо сразу видишь DI и еще интересные вещи, и как минимум открываешь гугл, для того чтобы понять, вообще что это такое и для чего и тут пошло поехало много интересной ифы.
Именно в этом случае симфони более грамотный, так как направляет на нужный путь. В случае с yii можно просто годами писать проекты даже не зная и не сталкивая с такими терминами. Особенно если проекты не большие. Можно всю жизнь проработать генерируя груды через gii.
Но когда речь зайдет о поддержки или развитии проекта, вот тогда уже как вы говорите придет понимание. Но уже может быть поздно.
Можно сказать относительно недавно, когда я познакомился с SOLID, прочитал книжку и начал подозревать Yii в халтуре.
Но при этом я согласен, что это не проблема инструмента, а минус скорее в том, что yii не направляет в нужную сторону. И я проходил можно сказать по такому сценарию:
— В начале писал запросы и логику в контроллерах. Потом понял, что это косяк.
— Начал писать запросы и логику в статических методах модели. Чуть лучше но все равно косяк.
— Потом оказывается узнал про репозиторий и сервисы.
И этапы этого примерно года два. Так как я прост описал на yii, даже не догадываясь о проблемах. В примере с симфони, я открываю его, смотрю:
— опа, а что такое DI. Для чего он?
— опа, а зачем сервисы?
— опа,…
Должен признать, что когда я первый раз взял симфони, я подумал. Да зачем писать столько фигни, если можно уместить в 1 класс и работает в 10 раз быстрее. Но теперь я знаю ответ, что это хорошие инвестиции в будущее.
Yii это хороший инструмент, для тех кто уже хорошо знаком с вышеперечисленными штуками и понимает чего ждать. К сожалению, я пока еще не вышел на нужный уровень.
Статья неактуально для небольших и частично средненьких проектов. Я наткнулся на все проблемы yii2 именно тогда, когда проект стал все больше и больше и нужно было делать все быстрее и быстрее и все сложнее функционал.
Но тут вопрос, что лучше: Хоть как-то или вообще никак?
И «притча» в тему:
Так вообще интересная история, во многом узнал себя.