Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
По работе есть необходимость мигрировать на laravel. До этого несколько лет работал с Yii2. Смотрел в сторону symfony, но руководство указало именно на ralavel.
Хотелось бы узнать, есть ли проекты с открытым исходным кодом на git на laravel 5 ? Что-то типа вот такого https://github.com/Sylius/Sylius (для симфони).
За ранее спасибо.
Не в сети
1) "Заранее", а не "за ранее" :-)
2) https://gist.github.com/msurguy/8590765
Не в сети
1) Да бывает косяки. Исправить уже нет возможности. Извиняюсь.
2) Спасибо.
Там очень много мусора и при этом нашел следующее
https://github.com/invoiceninja/invoiceninja
https://github.com/laravelio/laravel.io
https://github.com/dwightwatson/neontsunami
https://github.com/octobercms/october
https://github.com/sseffa/fullycms
https://github.com/bestmomo/laravel5-example
Пробежался по структуре почти всех представленных проектов (которые работали) и обратил внимание на то, что походу никто из разработчиков не использует модульную структуру. Хотя есть относительно большие проекты. У кого есть опыт работы с большим проектом, поделитесь опытом работы со структурой приложения.
П.С. на первый взгляд laravel интересная штука, но чем больше его пощупал, тем больше понял, что есть очень много крутых вещей, но в тоже время очень много топорный вещей.
Не в сети
и обратил внимание на то, что походу никто из разработчиков не использует модульную структуру
Поясните, что конкретно под модульной структурой имеете ввиду? Просто сейчас много разных направлений, можно разное подумать.
Вообще, Laravel по структуре довольно сильно Ruby on Rails напоминает - заметно, откуда автор брал вдохновение.
Не в сети
У меня аллергия на Ruby. Уже многие подмечают, что он никому не нужен.
Касательно модульной структуры я имею ввиду, что-то такое:
- users
- controllers
- models
- views
- helpers
- commands
- helpdesk
- controllers
- models
- views
- helpers
- commands
- products
- controllers
- models
- views
- helpers
- comands
И тд. Оправдан ли такой подход в ларавель ?
Не в сети
А зачем это? какой-то джумла-стайл?
Сейчас принято отдельные "модули" оформлять в виде composer package
При условии, что это реально отдельные пакеты, которые могут быть переиспользованы в других проектах.
Изменено VitalN (18.02.2016 12:22:03)
Не в сети
1) Если много сущностей, их нужно группировать удобства.
2) composer package хороши подойдут для расширений или библиотек, но не как не для модулей, конкретного приложения, где присутствует достаточна сильная связанность.
3) Как минимум модуль можно разделить на 3 части. Часть для сайта, часть для админки и общая часть. И так для почти любого модуля. Хранить 500 моделей в одной папке не очень весело. Тоже касается контроллеров и других штук.
Не в сети
Часть для сайта, часть для админки и общая часть. И так для почти любого модуля. Хранить 500 моделей в одной папке не очень весело. Тоже касается контроллеров и других штук.
А что мешает просто структуру папок сделать нормальную?
Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
models/Company/Company.php
CompanyOtherClass.php
models/SomeOtherStuff/Stuff.php
StuffOtherClass.php
и также для вьюх и контролеров?
И ради любопытства. что за проект такой с 500 моделями?
Насчитал у себя в самом монстровом и старинном проекте 183 шт, живут кстати в одной папке (исторически так сложилось) Неудобств при этом я лично не испытываю, если бы с нуля проектировал сегодня, побил бы наверное на папки по смежным зонам ответственности.
Не в сети
Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
Для удобства, чтобы все было не разбросано по проекту, а в одном конкретном месте.
И ради любопытства. что за проект такой с 500 моделями?
это образно, имеется ввиду, что если моделей просто много.
Насчитал у себя в самом монстровом и старинном проекте 183 шт, живут кстати в одной папке (исторически так сложилось) Неудобств при этом я лично не испытываю, если бы с нуля проектировал сегодня, побил бы наверное на папки по смежным зонам ответственности.
Для меня это очень неудобно. Например есть модели, которые так сказать вспомогательные, например:
- Категории - переводы категорий
- Стат. страницы - переводы стат страниц.
- Ели взять eav структуру, где много промежуточных таблиц для связи мани - ту - мани.
- и тп.
Гляньте еще раз проект на симфони: https://github.com/Sylius/Sylius, вот тут https://github.com/Sylius/Sylius/tree/m … ius/Bundle все красиво разбито по бандлам.
Не в сети
VitalN пишет:Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
Для удобства, чтобы все было не разбросано по проекту, а в одном конкретном месте.
Это дело привычки просто.
models/category/* VS category/models/*
и views/category/* VS category/views/*
Те же яйца, только в профиль )
А в УИИ разве можно такую структуру "модульную" настроить?
Не в сети
Кстати, при желании раскидать именно так не вижу проблем, модели будут и так жить где скажете
Роутинг настроить на нужные контроллеры элементарно
Резолвинг пути ко вьюхам тоже, мы правда твиг юзаем через twigbridge. В нем вообще свой неймспейс определить на каждый "модуль"/папку
Не в сети
Nepster пишет:VitalN пишет:Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
Для удобства, чтобы все было не разбросано по проекту, а в одном конкретном месте.
Это дело привычки просто.
models/category/* VS category/models/*
и views/category/* VS category/views/*Те же яйца, только в профиль )
А в УИИ разве можно такую структуру "модульную" настроить?
В yii2 там есть модульность. Сам класс приложение унаследован от модуля. И можно разбивать как угодно и строить свой каркас приложения.
А почем вы выбрали твиг в качестве шаблонизатора вместо дефолтного ?
И как Вам вообще laravel ? Честно говоря меня очень сильно напрягают фасады, которые я в нем увидел.
Не в сети
В yii2 там есть модульность. Сам класс приложение унаследован от модуля. И можно разбивать как угодно и строить свой каркас приложения.
А почем вы выбрали твиг в качестве шаблонизатора вместо дефолтного ?
И как Вам вообще laravel ? Честно говоря меня очень сильно напрягают фасады, которые я в нем увидел.
С твигом давно работаем, нравится всем. Смысла отказываться нет.
С ларавелем два года, с зачатков пятерки, нравится почти всем ) Вошел как родной, хотя до него работал много лет только либо Limb либо с собственными разработками.
Сейчас новый проект решили для самообразования пилить на YII2, вот он после лары довольно убог. Первую неделю обплевались, поделуха-поделухой )) Сейчас попривыкли. Но юзаем тоже с твигом, хотя поддержка его довольно убогая (или не разобрались еще)
Единственное, что пока понравилось больше в уии - это организация логгирования.
Довольно странный фреймворк, если ларавель старается быть как можно абстрактнее, все специфичные вещи выкидываются (как тот же HTML или Form), то в УИИ они наоборот все тянут внутрь, что дает много полезных инструментов безусловно, но обязан ты их использовать так а не иначе.
Я, например, почти час убил, пока научился делать load из реквеста в модель, даже знакомый уиист не смог помочь. Оказалось, что по дефолту там везде ожидается многомерный массив, ключи - имена модели ))
А чем фасады напрягают?
Не в сети
Со своей стороны я примерно тоже самое чувствую в ларавеле. Я еще толком не писал код, а живу пока в доках.
Понравилось:
- компоненты симфони, нет велосипеда как в yii
- чуть менее связанная система чем в yii
- активный пиар DI
- очереди
- Middleware
- Командная шина
Не понравилось:
- Синтаксис и именование методов актив рекорда (туда же миграции). Да и походу он послабее
- Фасады. (Косяки с автокомплитом, нужно расширения ставить да и что-то отвратно как-то, не знаю не могу объяснить но отвратно )
- Встроенный шаблонизатор. Это еще тот костыль. Взяли бы уже твиг, раз уж остальное на компонентах симфони.
- Ну и то, что теперь нужно привыкать к новому именованию всех штуковин.
Ну а в целом остался не доволен АктивРекордом. Это опасная штука. Я чуток копал симфони, мне там очень понравился DI и доктрина, особенно миграции (не нужно постоянно новые классы создавать).
Не в сети
Согласен с VitalN
Nepster, и не понимаю, как могут напрягать фасады? Ну не нравится - не используйте.
Это же по сути просто короткий вызов, посмотрите исходный код любого фасада - там почти пусто. Это небольшой хак, чтобы доступ в $app['модуль'] был через "псевдо" статический вызов Модуль::
К тому же, разработчику в Ларавел дается выбор на вкус - можно helpers-функции типа response() вместо фасада Response использовать, и так далее.
Никто не заставляет пользоваться фасадами, это опциональная штука.
Не в сети
Согласен с VitalN
Nepster, и не понимаю, как могут напрягать фасады? Ну не нравится - не используйте.
Это же по сути просто короткий вызов, посмотрите исходный код любого фасада - там почти пусто. Это небольшой хак, чтобы доступ в $app['модуль'] был через "псевдо" статический вызов Модуль::
К тому же, разработчику в Ларавел дается выбор на вкус - можно helpers-функции типа response() вместо фасада Response использовать, и так далее.
Никто не заставляет пользоваться фасадами, это опциональная штука.
Я в курсе что такое фасады 
. Если это есть и активно используется сообществом, то он этого никуда не делаться. Тоесть я же не один в команде, поэтому придется терпеть фасады для соблюдения единого стиля.
Не в сети
По мне так удобнее дернуть фасад
Например
\DB::
нежели
\Yii :: $app->db
Ну а к вопросу об удобстве именования
\DB::select() VS \Yii :: $app->db->createCommand()->queryAll()
Хотя по сути, все дело привычки )
Не в сети
Я в yii почти никогда не использовал \Yii :: $app->db->createCommand()->queryAll(), там очень удобный AR, который позволяет вытворять ацкие штуки. Главное не наследовать от него больше 1 модели на сущность и разделять логику по другим моделям и классам.
Эта тема походу уже за рамками вопроса, пора открывать новую.
Если открыть тему сравнения Yii2 и Laravel5 и приводить примеры на том и на том инструменты, было бы это кому-то интересно ? Например было бы очень интересно как можно на ларавеле записать что-то подобное:
$model = Organization::find()
->andWhere(['alias' => $alias])
->joinWith(['user' => function ($query) {
$query->status(User::STATUS_ACTIVE);
$query->joinWith('profile');
}])->one();Не в сети
Я в yii почти никогда не использовал \Yii :: $app->db->createCommand()->queryAll(), там очень удобный AR,
AR не всегда нужен, особенно на разных фоновых рутинах со сложными запросами
Эта тема походу уже за рамками вопроса, пора открывать новую.
Надо ее просто в "болталку" переменовать )
$model = Organization::find() ->andWhere(['alias' => $alias]) ->joinWith(['user' => function ($query) { $query->status(User::STATUS_ACTIVE); $query->joinWith('profile'); }])->one();
Наверное так, если я верно понял структуру
$model = Organization::where('alias',$alias)
->with(['user.profile' => function ($query) {
$query->where('user.status', User::STATUS_ACTIVE);
}])->first();Или так
$model = Organization::where('alias',$alias)
->with('user' => function ($query) {
$query->where('status', User::STATUS_ACTIVE);
$query->with('profile');
}])->first();Честно говоря, пока в реале не использовал выборки со вложенные релейшенами. Не было такой задачи
Изменено VitalN (19.02.2016 11:55:16)
Не в сети
Nepster пишет:Я в yii почти никогда не использовал \Yii :: $app->db->createCommand()->queryAll(), там очень удобный AR,
AR не всегда нужен, особенно на разных фоновых рутинах со сложными запросами
Nepster пишет:Эта тема походу уже за рамками вопроса, пора открывать новую.
Надо ее просто в "болталку" переменовать )
Nepster пишет:$model = Organization::find() ->andWhere(['alias' => $alias]) ->joinWith(['user' => function ($query) { $query->status(User::STATUS_ACTIVE); $query->joinWith('profile'); }])->one();Наверное так, если я верно понял структуру
$model = Organization::where('alias',$alias) ->with(['user.profile' => function ($query) { $query->where('user.status', User::STATUS_ACTIVE); }])->first();Честно говоря, пока в реале не использовал выборки со вложенные релейшенами. Не было такой задачи
А чо похоже. В Yii2 есть кстате joinWith и просто with, точно не помню, но вроде with работает с WHERE IN, ну а joinWitch собственно джоинит.
И еще момент с where, сам where перебивает предыдущие where, таким образом он может быть только один, для условий есть andWhere. В laravel можно использовать несколько where ? Он поймет, что имеется ввиду andWhere ?
Не в сети
А чо похоже. В Yii2 есть кстате joinWith и просто with, точно не помню, но вроде with работает с WHERE IN, ну а joinWitch собственно джоинит.
И еще момент с where, сам where перебивает предыдущие where, таким образом он может быть только один, для условий есть andWhere. В laravel можно использовать несколько where ? Он поймет, что имеется ввиду andWhere ?
Да напарывался уже ) по привычке делал в уии ->where()->where()
where в ларе это и есть AND
Не в сети
Nepster пишет:А чо похоже. В Yii2 есть кстате joinWith и просто with, точно не помню, но вроде with работает с WHERE IN, ну а joinWitch собственно джоинит.
И еще момент с where, сам where перебивает предыдущие where, таким образом он может быть только один, для условий есть andWhere. В laravel можно использовать несколько where ? Он поймет, что имеется ввиду andWhere ?Да напарывался уже ) по привычке делал в уии ->where()->where()
where в ларе это и есть AND
Я толком еще не писал код на laravel, но походу меня ждет тоже такое.
Не в сети
В Laravel читабельнее код выходит в итоге, на это и акцент (отсюда и популярность частично).
В идеале не нужны комментарии и документация, весь код - как документация.
А вот взять приведенный кусок из Yii:
$model = Organization::find()
->andWhere(['alias' => $alias])
->joinWith(['user' => function ($query) {
$query->status(User::STATUS_ACTIVE);
$query->joinWith('profile');
}])->one();
- Как можно что-то найти без параметров поиска? Feeling lucky, как в Google?
- Как может быть andWhere() сразу после поиска? найти()->иГде()? Бред с лексической точки зрения
- один() - один откуда? случайно, из конца, из начала?
Можно подумать, что это мелочи все - но это очень сильно влияет на читаемость кода
Не в сети
В Laravel читабельнее код выходит в итоге, на это и акцент (отсюда и популярность частично).
В идеале не нужны комментарии и документация, весь код - как документация.
А вот взять приведенный кусок из Yii:
$model = Organization::find()
->andWhere(['alias' => $alias])
->joinWith(['user' => function ($query) {
$query->status(User::STATUS_ACTIVE);
$query->joinWith('profile');
}])->one();- Как можно что-то найти без параметров поиска? Feeling lucky, как в Google?
- Как может быть andWhere() сразу после поиска? найти()->иГде()? Бред с лексической точки зрения
- один() - один откуда? случайно, из конца, из начала?Можно подумать, что это мелочи все - но это очень сильно влияет на читаемость кода
На самом деле, вы можете задавать несколько условий в одном where через ассоциативный массив.
andWhere актуально, когда вам нужно собрать жирный запрос, например:
$model = Organization::find()
->where(['alias' => $alias]);
if ($status) {
$model->andWhere(['status' => $status]);
}
$model->all();
Тоесть очень большая гибкость, можно собрать что угодно. В случае ларавель, даже с расширением у меня не работает переходы по методам в ide, что очень сильно напрягает.
Опять таки в laravel есть крутые штуки по сравнению с yii2, но в тоже время в yii2 тоже есть очень крутые штуки.
Не в сети
Тоесть очень большая гибкость, можно собрать что угодно. В случае ларавель, даже с расширением у меня не работает переходы по методам в ide, что очень сильно напрягает.
Опять таки в laravel есть крутые штуки по сравнению с yii2, но в тоже время в yii2 тоже есть очень крутые штуки.
С этим то я согласен. Просто неудачные имена для методов выбраны - это делает код Yii2 менее читаемым.
Не в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)