прокидывать все зависимости в методы / контроллеры класса,вместо event юзать 'Illuminate\Events\Dispatcher', например и так далее

Справедливо наверное. Но ни разу сам не использвал миддлвары. Судя по доке - их можно в конструктор запихать. Тогда мой класс бесполезен :)

обязательно попробуйте, это нужная вещь.

в миддлварах вся валидация должна быть.

в контроллере уже валидация логики, но не входных данных.

ок. заюзаю. 😊 поработать копипастером придется конечно, но не страшно 😊

Пока не знаю как миддлвары ведут себя в тестах

Но узнаю 😊

а я до сих пор тесты не писал под реальные проекты ) вот как раз собираюсь )

какой смысл миддлваре тестить отдельно? или контроллеры даже

кстати, вот насущный вопрос: что тестировать? говорят, что нужно тестировать всё, что может вести себя не так, как ожидается. то есть, всё, что написал сам, например, какие-то методы не из коробки.

верно ли это?

Ты сначала подумай, для чего нужны тесты, чтобы не писать тесты ради тестов

А там уже будет понятно, какие кейсы в каких местах тестировать

тесты нужны чтобы было понимание, что при очередном изменении кода текущий код не был сломан.

Я тесты пишу для а) проверки логики, б) построения архитектуры

ребят, подскажите а куда лучше выносить сложную логику? Я так понимаю для этого сервисы нужно делать?

ребят, подскажите а куда лучше выносить сложную логику? Я так понимаю для этого сервисы нужно делать?

+

+

а как их лучше организовать и связать с приложением? Как тестировать?

ребят, подскажите а куда лучше выносить сложную логику? Я так понимаю для этого сервисы нужно делать?

Сервисы, Работа, кто то их Action называет )

Я тесты пишу для а) проверки логики, б) построения архитектуры

а как тесты помогают в построении архитектуры?

а по сути работа с моделями в идеале должна тоже через сервисы быть?

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

а как тесты помогают в построении архитектуры?

test driven development же

а как их лучше организовать и связать с приложением? Как тестировать?

организовать как имплементации интерфейсов, т.е. каждый сервис какойто интерфейс имплементит. потом проще мокать будет, или юзать несколько разных реализаций интерфейса исходя из контекста. зависимости прокидывать исключительно через DI, никаких фасадов или хелперов в сервисах

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

а скажи, где в таком случае долна модель быть тоже в сервисе?

? Не понял

Модель это модель

сервис это сервис

В сервисе должна идти бизнес логика

test driven development же

сперва тест, потом реализация, знаю. я думал, как-то иначе, ОК, спасибо

у тебя в статье сервис зависит от модели

и ?

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

Есть ли выгода в такой архитектуре, когда есть ТОЛЬКО веб версия или только АПИ? В таком случае у нас будет по сути экш в экшене

Я или не проснулся или чет не понимаю, в чем вопрос

Ребят статья не моя )) Это пример как выносить логику из контролеров и модели

Парень в стать называет это дело Action

Я думла ты пробовал

Ребят статья не моя )) Это пример как выносить логику из контролеров и модели

а ты не знаешь хорошие проекты на гитхабе которые можно поизучать где такой подход реализован?

у него оно отличается от Jobs тем что оно может возвращать значения

Я так примерно и делаю ток я сервисами обзываю

а вынести логику можно просто создав отдельный класс у меня такие классы хелперами называются

Ну хоть "Беда" назови )

главное что б суть ясна была

а ты не знаешь хорошие проекты на гитхабе которые можно поизучать где такой подход реализован?

Я не пойу что тебе не ясно то ?

Я не пойу что тебе не ясно то ?

ну почему к примеру как Иван говорит не создать отдельный класс, а делать сервис и через DI прокидывать его, в чем к примеру тут профит

а вынести логику можно просто создав отдельный класс у меня такие классы хелперами называются

название хелпер как то не вяжется с single responsibilty принципом. когда вижу хелпер/manager классы, чаще всего оказывается что в них куча разного шлака понапихано, этакие god objects

не ясно еще как связывать эти сервисы.. Допустим в статье userservice почему то зависит от блога.. Думаю это можно как то лучше и гибче сделать

Ты не понял, сервис выполняет по факту какое то действие, которое несет в себе логику

ТЫ его выносишь из Модели и Контроллера для того что б не привязываться к системе скажем так

Т.е. Сервис получает объекты и что то с ними делает и отдает какой то результат

Это улучшает читабельность кода, и помогает при миграции проекта

Еще он спасает тебя от дублирования кода

пример

сперва тест, потом реализация, знаю. я думал, как-то иначе, ОК, спасибо

Я пытаюсь написать тест на проверку планируемой логики. И пока я не смогу прогнать тесты (в идеале) без бд, ну или с минимальным обращением к бд - я не считаю логику хорошей

Есть у тебя сложное создание пользователя, которое завязано на каких то действиях, там человеку счет открыть или привзяать его проекту или еще что то

И у тебя два действия(маршрута) которое это делают

Я пытаюсь написать тест на проверку планируемой логики. И пока я не смогу прогнать тесты (в идеале) без бд, ну или с минимальным обращением к бд - я не считаю логику хорошей

спасибо

Я пытаюсь написать тест на проверку планируемой логики. И пока я не смогу прогнать тесты (в идеале) без бд, ну или с минимальным обращением к бд - я не считаю логику хорошей

с актив рекордом это ой как геморно, либо юзать доктрину либо самопальные реализациирепозиториев

Т.е. Сервис получает объекты и что то с ними делает и отдает какой то результат

ну смотри, к примеру у меня есть товар.. Есть скажем сервис корзины, в который я могу пихнуть этот товар и сервис заказа, которому я также хочу отдать товар.. Вопрос в том, что такое товар и как его связать правильно с несколькими сервисами

Один тупо создание юзера, второй импорт массовый, если ты не используешь сервис, вероятность того что ты повторишь код велика

Корзина это у тебя не сервис это по факту сущность

Я так понимаю через контракты (интерфейсы), но что будет если несколько сервисов имеют очень похожие контракты.. Или как вариант товар, корзину и сервис заказа объединить в какой то глобальный модуль, чтобы они могли знать друг про друга

Я так понимаю через контракты (интерфейсы), но что будет если несколько сервисов имеют очень похожие контракты.. Или как вариант товар, корзину и сервис заказа объединить в какой то глобальный модуль, чтобы они могли знать друг про друга

избегай god object-ов, пусть у тебя таким глоабльным модулем будет экшен контроллера)

с актив рекордом это ой как геморно, либо юзать доктрину либо самопальные реализациирепозиториев

А почему, собствннно это так? Потому что у тебя нет возможности протестиповать обработку данных. Ты сразу их потом сохраняешь

В теории класс должен получить данные и вернуть результат

А там уже делай что хочешь с ним

я их не сохраняю

я из них получаю какие то поля

тогда не понимаю в чем проблема

в некоторых сервисах

Можешь пример привести?

Я так понимаю через контракты (интерфейсы), но что будет если несколько сервисов имеют очень похожие контракты.. Или как вариант товар, корзину и сервис заказа объединить в какой то глобальный модуль, чтобы они могли знать друг про друга

Я не пойму ты пытаешься сделать какой то обособленный компонент или что ?

в некоторых сервисах

моки не помогают?

моки не помогают?

помогают, проблема в том что приходится мокать по ублюдочному. магический __get, для того чтобы нужные проперти возвращались когда сервис их требует

помогают, проблема в том что приходится мокать по ублюдочному. магический __get, для того чтобы нужные проперти возвращались когда сервис их требует

можно пример? интересно стало

Dead Loppi: Пыха выдержит если будет 3к запросов в секунду ?

можно пример? интересно стало

Почему стало интересно: магический гет это реакция на отсуствующий проперти

Dead Loppi: Пыха выдержит если будет 3к запросов в секунду ?

да 😇😂😜

Я не пойму ты пытаешься сделать какой то обособленный компонент или что ?

просто хочу понять, как все из контроллера вынести и сделать его максимально тупым

Почему стало интересно: магический гет это реакция на отсуствующий проперти

а откуда у тебя в моке модели элокуентовой возьмутся проперти заполненые с учетом того что ты в БД не лезешь?