ШН
а в laravel разве нельзя юзать doctrine, не обязательно же на Symfony проект начинать
Size: a a a
2020 June 16
MA
но зачем? что делает сервис? какой профит от прослойки?
хранить там бизнес логику, чтобы не в контроллерах
AK
Шило Николай
условно на doctrine
+ я не делал большой проэкт на ларе а поднял для експеремента и отказ от eloquent обрезает много удобных плюшок (observer, policy)
MA
Шило Николай
а в laravel разве нельзя юзать doctrine, не обязательно же на Symfony проект начинать
если доктрину хочешь, используй репозитории, оно как раз преследует этот принцип, если елокент - то тут репозитории излишни
П
а что докрина дает такого для небольших и средних проектов?
IK
Этот вечный баттл между элоквэнтом и паттерном репозитория.. Достойные кандидаты на Версус)) 😎👊
AK
хранить там бизнес логику, чтобы не в контроллерах
не согласен, когда создают репозиторий в ларе и юзают eloquent туда кидают просто все запросы и не делят на бизнес логику
YP
хранить там бизнес логику, чтобы не в контроллерах
Видел проект, где под каждый котроллер был создан сервис. Типо ПостКонтроллер (в который подгружался ПостСервис), в котором все методы состояли из одной строчки - “return $this->service->sameMehtod();” . И там в сервисе абсолютно тоже самое, что было бы в контроллере.
IK
Видел проект, где под каждый котроллер был создан сервис. Типо ПостКонтроллер (в который подгружался ПостСервис), в котором все методы состояли из одной строчки - “return $this->service->sameMehtod();” . И там в сервисе абсолютно тоже самое, что было бы в контроллере.
MVS, Model View Service))
MA
Видел проект, где под каждый котроллер был создан сервис. Типо ПостКонтроллер (в который подгружался ПостСервис), в котором все методы состояли из одной строчки - “return $this->service->sameMehtod();” . И там в сервисе абсолютно тоже самое, что было бы в контроллере.
не, ну не такой же подход)
AK
Павел
а что докрина дает такого для небольших и средних проектов?
для меня автомиграции это прям килерфича
мне после питона (django) було чуть трудно без этого
мне после питона (django) було чуть трудно без этого
YP
а по поводу репозиториев - в ларке не юзаю, ни разу не пожалел
YP
зато видел кучу говнокода, где из юзали
AK
а по поводу репозиториев - в ларке не юзаю, ни разу не пожалел
я юзал, потом пожалел и переписал назад
П
для меня автомиграции это прям килерфича
мне после питона (django) було чуть трудно без этого
мне после питона (django) було чуть трудно без этого
интересное мнение, я наоборот подумывал пощупать питона с джанго. Лара все-таки лучше?
AK
+ тогда еще небыло Api Resourse и поэтому когда появился переписал все на стандартную конфигурацию
П
я юзал, потом пожалел и переписал назад
тоже юзал на 3 или 4 проектах , потом посмотрел, что повторяю код типа того примера выше с сервисами)
AK
Павел
интересное мнение, я наоборот подумывал пощупать питона с джанго. Лара все-таки лучше?
ну местами мне джанго прям лучше, там DDD с коробки, автогенерация миграции, автогенерация админки (можно отключить) то поскольку модель четко знает про все поля и колонки она лучше с ними работает
П
более того, репозиторий же не просто так сам идет. Сначала под него контракт писать, потом все это инжектить. Плюс архитектора у меня нет, потстоянно меняется код и методы. Грубо пишу метод в репозиторий и под него пишу в контракте)))
AK
а вот Ruby on Rails меня после лары чуть обломал (он неплох но и не радует как в анекдотах про шарики)