Р
Но
dd('test') работаетdd('test') работаетSize: a a a
2019 December 11
A
Но
Ну значит метод работает), это есть хорошо. Я бы искал по названию поля в плагине
'xxxxx' => 'required
'xxxxx' => 'required
A
блин, комрады, рассудите, а то у меня гавно кипит...
делаю api на ларе. накатал контроллер, который дергает сервис (в нём вся логика), репозиторий (он уже был, ну и пусть будет, закинул свой запрос туда). В сервисе создаётся Resource, который радостно возвращает преобразованную коллекцию, которую сервис радостно возвращает к контроллер, который и отдаёт это в response ...
И тут мне один комрад (да комрад ли он мне?!) выдаёт мне вот такое (цитирую) -
For example, what if we want to use that from cli. In cli we don't have a request. So, we will face exception because the function return is based on resource and resource is based on request. And that does not hides complexity, actually creates complexity since we need to handle that in multiple places
And what is at the servise function is what it should be on controller, which is responsible to return http response
But, repository, only returns data. Models, collections and so on ... So, they are readable everywhere
And now we just have additional service
I can say that's overusing design patterns and can be considered as an anti-pattern
делаю api на ларе. накатал контроллер, который дергает сервис (в нём вся логика), репозиторий (он уже был, ну и пусть будет, закинул свой запрос туда). В сервисе создаётся Resource, который радостно возвращает преобразованную коллекцию, которую сервис радостно возвращает к контроллер, который и отдаёт это в response ...
И тут мне один комрад (да комрад ли он мне?!) выдаёт мне вот такое (цитирую) -
For example, what if we want to use that from cli. In cli we don't have a request. So, we will face exception because the function return is based on resource and resource is based on request. And that does not hides complexity, actually creates complexity since we need to handle that in multiple places
And what is at the servise function is what it should be on controller, which is responsible to return http response
But, repository, only returns data. Models, collections and so on ... So, they are readable everywhere
And now we just have additional service
I can say that's overusing design patterns and can be considered as an anti-pattern
A
я ему конечно ответил
1. why we will try to call my service from cli?
2. Resource is based on request, yes. What a problem with request, if this request generation and sending by service?
3. this service is callable from any place using DI or creating new instance
4 . "controller, is responsible to return http response", "repository, only returns data" - so, where must be business logic then?
1. why we will try to call my service from cli?
2. Resource is based on request, yes. What a problem with request, if this request generation and sending by service?
3. this service is callable from any place using DI or creating new instance
4 . "controller, is responsible to return http response", "repository, only returns data" - so, where must be business logic then?
A
но он уже радостно свалил с работы, а у меня теперь кипит...
A
в общем хочется мнения общественности и плескавицу
K
в общем хочется мнения общественности и плескавицу
Так так) то есть он говорит отвязаться от реквеста, чтобы сервис можно было использовать не только через контроллер, а тебя это калит?
v
Ну так то он прав.
A
А ничего, что реквест для ресурса генерируется в сервисе?
A
Контроллер в сервис ничего не передаёт, Get запрос там
A
Соответственно сервис спокойно юзается где угодно
A
В данном случае реквест - это ж нифига не объект класса Request
v
Сервисный слой обычно реализуется для переиспользования. С учетом, что сервисный слой и правда может использоваться в консольных командах или других частях приложения, завязывать его за реквестом или ресурсом не совсем корректно.
Однако без видимости кода на самом деле сложно рассудить. Так как на понятно даже зачем реквест генерируется в самом сервисном слое.
Однако без видимости кода на самом деле сложно рассудить. Так как на понятно даже зачем реквест генерируется в самом сервисном слое.
v
В данном случае реквест - это ж нифига не объект класса Request
Вот, уже больше вводных))) на гист пример может скинуть выйдет?
v
Без связи с оригиналом естественно
A
Сейчас уже нет, ушёл от компа
A
Но ты ж понимаешь, какой реквест юзает Resource в ларе
A
Там коллекция
v
Если про стандартный от Http, тогда зачем он генерируется в сервисном слое?
Без примера затрудняюсь придумать необходимость кроме как подмены даных постранички или передачи link‘ов на связанные ресурсы или себя.
Без примера затрудняюсь придумать необходимость кроме как подмены даных постранички или передачи link‘ов на связанные ресурсы или себя.
Р
Время тупых вопросов. Запускаю миграции с сидером. Что это значит?