А так же что можно стандартные селекты (например книги со всеми данными кроме текста) зашить например в скоупах (в элоквенте) и "пользовательский" код в контроллере или сервисе будет простым.
Когда вы говорите про просадку перфоманса от WHERE IN или от *. То забываете упомянуть что обычно в приложении оперировать приходится не всеми хранимыми сущностями. Пагинация или бесконечная прокрутка или обработка чанками идет практически всегда. И эти факторы превращаются в экономию на спичках. А удобство и простота кода гораздо более приоритетные.
Ну например SOLID. Прекрасный набор принципов. И Их соблюдение важно. Но тот же AR их нарушает весьма сильно (особенно S). И в небольших приложениях это дает простоту архитектуры и скорость разработки. То же самое и с внедрением зависимостей например в контроллеры. Я например отделяю для себя сервисы инкапсулирующие бизнеслогику и сервисы окружения так сказать. И вот их я явно не буду пробрасывать через внедрение зависимостей а могу просто использовать хелпер (например view) или или извлеку из контейнера прямо в коде метода. И т. д.
Наверное выражу непопулярное мнение, но лично мне Лара нравится именно "гибкостью" в плане подхода к коду. Т. е. на ней легко писать очень быстро маленькие приложения сильно отходя от академичных подходов (тобишь с долей говнокода). Прекрасно получается писать средние приложения возможно добавляя какие то свои архитектурные коснтрукции при этом так же местами забивая на академичность. Ну и ничего не мешает строить поверх свои архитектурные решения и идти страшным энтерпрайз путем) При этом вполне получается идти от первого к последнему рефакторингом.
Очень многие большие и сложные проекты написаны на фреймворках (Рельсы, Джанго, Лара и Симфони) вполне легко найти инфу. Полемика нужны ли фреймворки гудел лет 4-5 назад. И фреймворки победили.
Почему у вас классы то в UpperCamelCase, то lowerCamelCase, то с нелепейшим постфиксом _. Поддиректория (и поднеймспейс) для ошибок есть и с большой буквы, а для трейтов с маленькой. При этом интерфейсы своей поддиректории лишены. Чем они хуже?) Префиксы венгерской нотации то большая буква, то маленькая а например трейт синглтон обделен префиксом. Что он вам сделал? И т.д. и т.п. Вот что я имел ввиду под "причесать именование".
По PSR я имел ввиду не только 4 ый для автолоудинга а больше второй.
Но это всё косметика, гораздо хуже godobject'ы (типо роутер). Называние вещи не своими именами (тот же роутер, MVC и т.д.). Методы по 100 строк. Проблемы безопасности. И так далее.
Как и Eloquent, как впрочем и большинство ORM
Что такое "типовые объекты-строки"?
Если у нас данные о сущности хранятся в разных таблицах, то есть связи.
А так же что можно стандартные селекты (например книги со всеми данными кроме текста) зашить например в скоупах (в элоквенте) и "пользовательский" код в контроллере или сервисе будет простым.
Когда вы говорите про просадку перфоманса от WHERE IN или от *. То забываете упомянуть что обычно в приложении оперировать приходится не всеми хранимыми сущностями. Пагинация или бесконечная прокрутка или обработка чанками идет практически всегда. И эти факторы превращаются в экономию на спичках. А удобство и простота кода гораздо более приоритетные.
Возможность удобно динамически формировать запрос
При всём уважении, не уверен, что схватил это выражение от вас)
Ну например SOLID. Прекрасный набор принципов. И Их соблюдение важно. Но тот же AR их нарушает весьма сильно (особенно S). И в небольших приложениях это дает простоту архитектуры и скорость разработки. То же самое и с внедрением зависимостей например в контроллеры. Я например отделяю для себя сервисы инкапсулирующие бизнеслогику и сервисы окружения так сказать. И вот их я явно не буду пробрасывать через внедрение зависимостей а могу просто использовать хелпер (например view) или или извлеку из контейнера прямо в коде метода. И т. д.
Наверное выражу непопулярное мнение, но лично мне Лара нравится именно "гибкостью" в плане подхода к коду. Т. е. на ней легко писать очень быстро маленькие приложения сильно отходя от академичных подходов (тобишь с долей говнокода). Прекрасно получается писать средние приложения возможно добавляя какие то свои архитектурные коснтрукции при этом так же местами забивая на академичность. Ну и ничего не мешает строить поверх свои архитектурные решения и идти страшным энтерпрайз путем) При этом вполне получается идти от первого к последнему рефакторингом.
у автора уже была статья где с ним холиварили на эту тему.
101 обозначает базовый или вводный урок (an introductory lesson on something).
"Твое последнее задание в игре синий хабр: самым первым оставить глупый комментарий под статьей "
В заголовке: "2017"
В статье: "Jquery", "CodeIgniter" (!) и "… одним нажатием Кастомной кнопки (любая картинка на ваш вкус)"
Вы хотели сказать "продвигаю"?)
Даже судя по сайту редкостное....
Так это уже его 3ая (если не ошибаюсь) реинкарнация на Хабре. И он всё время в комментах эту статью пихает)
Оставьте эту пошлую риторику. Не хотите фреймворки? Так я вам их не продаю.
Без тестов пакет не пакет. И Лару вы прям за уши притянули.
Очень многие большие и сложные проекты написаны на фреймворках (Рельсы, Джанго, Лара и Симфони) вполне легко найти инфу. Полемика нужны ли фреймворки гудел лет 4-5 назад. И фреймворки победили.
Сочувствую. Держитесь там.
Почему у вас классы то в UpperCamelCase, то lowerCamelCase, то с нелепейшим постфиксом
_. Поддиректория (и поднеймспейс) для ошибок есть и с большой буквы, а для трейтов с маленькой. При этом интерфейсы своей поддиректории лишены. Чем они хуже?) Префиксы венгерской нотации то большая буква, то маленькая а например трейт синглтон обделен префиксом. Что он вам сделал? И т.д. и т.п. Вот что я имел ввиду под "причесать именование".По PSR я имел ввиду не только 4 ый для автолоудинга а больше второй.
Но это всё косметика, гораздо хуже godobject'ы (типо роутер). Называние вещи не своими именами (тот же роутер, MVC и т.д.). Методы по 100 строк. Проблемы безопасности. И так далее.
Или приведите чей то стайлгайд для БД хоть более менее используемый приведите в котором есть венгерская нотация в именовании.