All streams
Search
Write a publication
Pull to refresh
64
0
Адель Файзрахманов @Adelf

Пользователь

Send message
ну в какой-нибудь доктрине тоже отношения часто через прокси реализованы. смысл в персисте. во всех реализациях Active Record — приходится вручную их в базу кидать, либо минуя репозиторий, либо использовать другой «репозиторий».
ну вы очень кратко как раз статью и пересказали :)
Если же у вас в проекте Eloquent и очень хочется побаловаться шаблонами проектирования, то в следующей статье я покажу как можно частично применить шаблон Репозиторий и получить от этого пользу.

Как раз про это будет.
Люди часто доктрину связывают с симфони. Я спокойно юзаю доктрину в ларавель проекте…
Вон в PHP-дайджесте недавнем была — habr.com/en/post/441584. Это кстати и стало поводом для написания этой статьи.
Я конечно не эксперт, но ведь выигрыш данной партии дал бы вам дополнительных пол-очка. Т.е. первый разряд все равно не светил? )
А самому прочитать внимательно? Доктрина с репозиториями — нормально. Элоквент с репозиториями — бесполезное жонглирование паттерном.
Ну, с википедии(или откуда там) и я смог бы скопипастить… вопрос был именно в использовании Элоквента и Репозитория вместе. Любая сущность с подсущностями и все рушится.
Раз в два-три месяца стабильно кто-то пишет про репозитории и Eloquent. и как «правильно» их использовать. Притом ни для чего они нужны, ни примера чуток посложнее Post у них не находится.
Лицензию мне не надо, уже купил на следующий год.

Шторм позволяет при некоторых манипуляциях работать с php как со статически типизируемым кодом. Даже во фреймворках со всякой магией как Laravel.
Все эти довольно умные анализаторы phpDoc, фича с .phpstorm.meta.php файлом, типизация параметров к шаблонизатору blade(банальным phpDoc вначале).
Имея такой код, который по Find Usages способен найти каждое использование метода/класса или свойства, мы можем очень продуктивно искать баги и проводить крупные рефакторинги.
Именно эта фича меня больше всего радует.
Плюс огромные возможности по написанию плагинов.
Прикольные интеграции это конечно приятно, но это не такие базовые вещи, без которых работать невозможно.
Могу лишь согласиться. Так написано прямо начиная с 4.2, я проверил :)
А мы в своих проектах в миграциях держали лишь структурные изменения. В сидах же лежали умные классы, которые любые старые наборы изначальных данных приводили к нужному свежему набору.
Так удобнее… поскольку сид можно было менять. а вот миграцию будь добр каждый раз создай новую.
Похоливарить можно, но нет смысла.
Ну… прям опровергнуть полностью ваш подход мне нечем. всякие SRP приплетать тут не очень умно наверно. Могу лишь сказать, что один из пакетов неявно рекомендует именно сиды — github.com/spatie/laravel-permission#database-seeding
Это, кстати, хороший вариант :) но немного холиварный. Не по себе мне миграции использовать не для изменения структуры бд. Но, возможно, я не прав.
Я не открываю gates & policies, а просто намекаю, что можно пользоваться ими безо всяких доп пакетов. В статье по вашей линке, они юзаются параллельно. Посыл совсем другой.
Где моя табличка сарказм?
Верно говорите. Вон как шахматы быстро загнулись :)
Если что-то сильно исковеркал, прошу поправить :)
Опускал — это да. Хотел сделать выжимку.
Я про case sensitive названий :)
Исправил. Спасибо. Мы, ларавельщики, такой тонкой разницы не чувствуем.
Это просто краткий пересказ доклада. Я не мог вписать то, о чем докладчик не говорил.
И я уже написал, что мне больше понравились подробности внутреннего строения СУБД, чем холиварные.

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Date of birth
Registered
Activity