-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Laravel Чем вызван взрывной интерес к Лярве?
- Автор темы Фанат
- Дата начала
Я понял причину популярности Laravel: "Mongo is web scale."
Каждая страница документации начинается с мантры: easy, automatic, fluent.
Если вчитаться в детали, отличий от yii2 - минимум. Ну, маппинг сервисов на объекты для инъекции вынесен в отдельный конфиг. Тот же индусский хренак-хренак и в productuin, только с фасадами. И зашкаливающим пафосом. Больше было только у MySQL, которые в документации ругали конкурентов.
Каждая страница документации начинается с мантры: easy, automatic, fluent.
И народ ведется.
Если вчитаться в детали, отличий от yii2 - минимум. Ну, маппинг сервисов на объекты для инъекции вынесен в отдельный конфиг. Тот же индусский хренак-хренак и в productuin, только с фасадами. И зашкаливающим пафосом. Больше было только у MySQL, которые в документации ругали конкурентов.
@grigori, как раз фасады - это и есть прямой аналог Service locator в Yii. И то, что продвинутый laravel-народ советует их не юзать, должно навести на правильные мысли ;-)
А так, да. Пиар неплохой. Но это законы рынка. Фреймворк обязан быть как можно с меньшим порогом вхождения. И документация должна этому способствовать. Но у ларки кроме этого полно прикольного под капотом. Мне достаточно даже того, что там простой IoC-контейнер, который конфигурится из кода.
А так, да. Пиар неплохой. Но это законы рынка. Фреймворк обязан быть как можно с меньшим порогом вхождения. И документация должна этому способствовать. Но у ларки кроме этого полно прикольного под капотом. Мне достаточно даже того, что там простой IoC-контейнер, который конфигурится из кода.
@grigori, это смотря что тебе от фреймворка надо.
Если писать на ларавеле как на yii^W^W^W по мануалу - разница минимальная.
Если же на фреймворк особо не завязываться, AR и прочие фасады не трогать, и использовать его чисто как web application layer-фреймворк и базовую обязку - с ларавелом это делается элементарно: есть нормальный DI, есть минимум два датамаппера на выбор (Doctrine или AnalogueORM), а вот на yii так не получится совсем, он гораздо более монолитен. Впрочем, наверняка при глубоком знании внутренностей yii получится, но усилий придется приложить намного больше, да и от yii мало что останется.
То, что я из ларавела использую, в целом можно легко собрать из симфони-компонентов, добив пакетами с композера и написав простенькую обвязку, и не будет никакой принципиальной разницы, но с ларавелом оно привычнее, и на готовеньком
А по теме - да, наверное, причина популярности в пиаре и низком пороге вхождения, и пишут на нем в основном такое же говно, как на yii.
Если писать на ларавеле как на yii^W^W^W по мануалу - разница минимальная.
Если же на фреймворк особо не завязываться, AR и прочие фасады не трогать, и использовать его чисто как web application layer-фреймворк и базовую обязку - с ларавелом это делается элементарно: есть нормальный DI, есть минимум два датамаппера на выбор (Doctrine или AnalogueORM), а вот на yii так не получится совсем, он гораздо более монолитен. Впрочем, наверняка при глубоком знании внутренностей yii получится, но усилий придется приложить намного больше, да и от yii мало что останется.
То, что я из ларавела использую, в целом можно легко собрать из симфони-компонентов, добив пакетами с композера и написав простенькую обвязку, и не будет никакой принципиальной разницы, но с ларавелом оно привычнее, и на готовеньком
А по теме - да, наверное, причина популярности в пиаре и низком пороге вхождения, и пишут на нем в основном такое же говно, как на yii.
Последнее редактирование:
Alexey Mezenin
Новичок
grigori, а как же самое большое и вполне "качественное" комьюнити со всеми вытекающими (быстрее решаются проблемы, больше классных книг и туториалов и пр.)? Не плюс ли?
Конечно это очень субъективно, но мне Laravel сразу показался более логичным, этакий Symfony с долей "плохих практик", но используемых к месту. С Yii пытался подружиться несколько раз, но вообще никак не пошел.
Многим, в том числе и мне, очень нравится более читаемый "like simple English" код. Правда есть те, кому-то не нравится какими средствами это достигается.
Конечно это очень субъективно, но мне Laravel сразу показался более логичным, этакий Symfony с долей "плохих практик", но используемых к месту. С Yii пытался подружиться несколько раз, но вообще никак не пошел.
Ну так правильно, yii2 писался с оглядкой на laravel, у которого подобный апи был как минимум с 3-й версии.
Ты уже не первый раз упоминаешь о каком-то конфиге для апи. Такого нет, фишка как раз в том, что ты просто прописываешь в кнструкторе-методе инъекцию и она самостоятельно резолвится если есть такой класс, но если тебя надо подменить эту зависимость в тесте или по другой причине, то ты можешь сконфигурировтаь DI. Но по дефолту ты не делаешь лишьних движений и никаких апи. ВРоде в 3-й symfony добавили похожую функциональность.
Фасады не надо использовать, это мусор оставшийся с перехода от 3-й версии, где была просто статика, без LSB, просто до сиз пор в пару местах она осталась, да и доки не менялись в некоторых местах со времён той же 3-ки. Если видишь фасады или статические вызовы для AR вроде User::find, то надо сразу бить по рукам. Тут даже не проблема в фасадах, а в том, что это запах плохого знакомства с фреймворком и его современными фичами.
Это Грик ознакомился с кодом девконфа
там у меня интерфейсы к нужным классам биндятся. И это кстати более правильный подход. Просить интерфейс, а не реализацию.Боюсь показаться быдлом, но расскажи как правильно
Alexey Mezenin
Новичок
А в Yii нет IoC?
Тем не менее, все самые именитые Ларавелевские авторы их используют, особенно при работе с моделями, видел в 3 книгах по 5ке. Сейчас читаю книгу о тестировании в Laravel 4, дак ее автор очень сильно хвалит фасады и говорит о том, что их неприятие у некоторых девелоперов связано с ассоциацией со "статикой". Пишет, что благодаря фасадам, очень удобно имитировать любой встроенный класс.
Там только SL. Не понимают всей радости жизни.
Alexey Mezenin
Новичок
Видимо так.
Код:
$user = new User();
$user->find(1);
Код:
return view('some.view');
Последнее редактирование:
Обычный инджектБоюсь показаться быдлом, но расскажи как правильно
PHP:
function(User $user) {
return $uesr->find(1);
}https://laravel.com/docs/5.2/routing#route-model-binding
Да, имитировать можно, но зачем, если УЖЕ есть нормальный DI с инъекциями в контроллер, метотод, гибкой возможностью биндинга в зависимости от контекста.
При этом исчезают проблемы вроде проблем с автокомплитом, ругательства IDE на двойное определение в случае ide_helper, возможность нормального статического анализа и т.д.
Alexey Mezenin
Новичок
Имитировать - я имел ввиду "мокить" при тестировании (mocking).
Мне вот тоже нравилась валидация на уровне реквеста. Но потом мне понадобилась для валидации кое-какая бизнес-логика. А в реквест иньекции не получается делать красиво. Потом до меня дошло что неправильно в HTTP-реквест классе делать валидацию для бизнес-логики. Как итог в реквест классах у меня только самые простейшие правила типа required and email(просто для более приятных error сообщений), и удобные методы-геттеры(getFirstName()) для избавления от магических строк. А настоящая валидация все равно в бизнес-логике.
Вурдалак
Продвинутый новичок
Сама зависимость там внутри статическая, раз позволяет писать User::find(). Отсюда вывод: бессмысленно требовать писать $user->find(42).
Может объяснишь логику?