1000+

а ты денежку за весь софт заплатил что ты используешь?

не парься, тебе всеравно за суппорт платить будут, а это уже будет привязано к серверу/клиенту

за код никто платить не будет

а все остальные штуки - это пережитки прошлого

если есть соединиение то полюбому tcp. поверх уже websockets скорее всего и на базе оного еще что свое можно навернуть

@fes0r вопрос по архитектуре. Контроллер может из репозитория брать данные напрямую? или же через сервис обращаться?

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

кажется что плохая идея хранить логику в репах

ну логика в моделях по-идеи

кажется что плохая идея хранить логику в репах

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

/stat@combot

combot.org/chat/-1001042383571

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

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

Здесь все в чем то новички

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

для нвичков более https://t.me/phpgeeks

@fes0r вопрос по архитектуре. Контроллер может из репозитория брать данные напрямую? или же через сервис обращаться?

может, репозиторий это твоя кастомная коллекция бизнес-специфичных объектов

т.е. вполне норм контроллер вида: public function listAction(UserSpec $spec) { return new JsonResponse( new UsersListDto($this->users->findAllSatisfying($spec)) ); }

для нвичков более https://t.me/phpgeeks

Спасибо Но там столько срача между участниками, что просто капец :(

Спасибо Но там столько срача между участниками, что просто капец :(

это мотивация быстрее учиться и возвращаться сюда ;)

Спасибо Но там столько срача между участниками, что просто капец :(

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

Народ, вопрос: использует ли кто pre-commit анализаторы/линтеры для php? посоветуйте что нибудь

pre-commit линтеры чем-то отличаются от остальных?)

https://github.com/phpstan/phpstan https://github.com/etsy/phan

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

Делать лучше через сервис и обработку так же в сервис. Проще будет код в дальнейшем переиспользовать.

Делать лучше через сервис и обработку так же в сервис. Проще будет код в дальнейшем переиспользовать.

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

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

В смысле данные напрямую вытянуть?

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

Сервис

В смысле данные напрямую вытянуть?

без создания сущностей

Не надо в репозиторий логику пихать — это не его задача.

ну зависит от вида логики

пока я совсем не понимаю, о чем мы говорим)

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

и то, и другое логика

А сохранять тоже репозиторий должен?

Данные

Ну простой пример. Тяну из бд текст, где есть допустим макросы

А сохранять тоже репозиторий должен?

$users->add($user);

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

Я не знаю объёмы вашего приложения. В каждом случае лучше всего думать головой и использовать здравый смысл. Если заниматься быстрым прототипированием, пилиловом MVP то вполне можно пихать репозитории в контроллеры. Если разрабатываться продукт с очень длительным жизненным циклом, то лучше сразу абстракцию в виде сервиса делать. Вопрос не только в переиспользовании кода, но и в том, что если код усложнится, то все усложнения будут инкапсулированы в этой асбтракции.

Мне их надо заменить перед выводом

$users->add($user);

добавление в коллекцию вполне задача репозитория

Я не знаю объёмы вашего приложения. В каждом случае лучше всего думать головой и использовать здравый смысл. Если заниматься быстрым прототипированием, пилиловом MVP то вполне можно пихать репозитории в контроллеры. Если разрабатываться продукт с очень длительным жизненным циклом, то лучше сразу абстракцию в виде сервиса делать. Вопрос не только в переиспользовании кода, но и в том, что если код усложнится, то все усложнения будут инкапсулированы в этой асбтракции.

так а толку в этой абстракции тогда?

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

так а толку в этой абстракции тогда?

В любой пост обработке полученных данных из репозиториев по спеке. Спека — это кстати не логика.

В любой пост обработке полученных данных из репозиториев по спеке. Спека — это кстати не логика.

а что такое логика?

В любой пост обработке полученных данных из репозиториев по спеке. Спека — это кстати не логика.

можно пример пост-обработки?

ERROR: S client not available

логикой будет, например, динамическое формирование подобной спеки.

логикой будет, например, динамическое формирование подобной спеки.

(new ProductsSpec())->onSale()->inCategory($request->category) динамическое?

или там new And(new OnSale(), new InCategory($request->category));

Этот какой то тренд все через spec делать?

Класс And звучит странно

Этот какой то тренд все через spec делать?

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

open-closed

(new ProductsSpec())->onSale()->inCategory($request->category) динамическое?

Оба примеры не являются динамическим формированием спеки. В них отсутствует логика формирования. Т.е. это можно хоть в YAML перенести с плейсхолдерами и сути не поменяется.

Есть примеры на гитхабе?

Я после ларавел. Там AR

Симфони решил изучать

Про репозитории и спеки есть статья неплохая, правда на примере доктриновских: https://beberlei.de/2013/03/04/doctrine_repositories.html

То что надо

Оба примеры не являются динамическим формированием спеки. В них отсутствует логика формирования. Т.е. это можно хоть в YAML перенести с плейсхолдерами и сути не поменяется.

так пример динамической? Если я это в полиморфный метод прокидываю, это не динамика?(

Ну если это где-то совместно со стратегией используется какой-нибудь, то тогда вполне себе динамически.

Но конкретные куски кода, где везде свежесозданные объекты — не динамические.

Но конкретные куски кода, где везде свежесозданные объекты — не динамические.

ну там логика разная внутри может быть

Может. А ещё может быть логика и до объявления этих, вырванных из контекста, строк. Я вполне способен представить, что эти строки не в сферическом вакууме существуют, но тем не более я отвечал исключительно на то, что было приведено, потому как отвечать на бесчисленное множество и бесчисленные вероятности того, что могло бы быть, но не было приведено — бессмысленно и беспощадно.

Может. А ещё может быть логика и до объявления этих, вырванных из контекста, строк. Я вполне способен представить, что эти строки не в сферическом вакууме существуют, но тем не более я отвечал исключительно на то, что было приведено, потому как отвечать на бесчисленное множество и бесчисленные вероятности того, что могло бы быть, но не было приведено — бессмысленно и беспощадно.

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

зачем какой-то мифический сервис, который непонятно что абстрагирует

А спецификацию прямо в контроллере формировать?

да

Если так удобнее в вашем случае, то на здоровье же)

Ребят, кто ещё может плиз подсказать полезные чаты связанные с php в телеграмме?