Когда имеет смысл вместо сервисов использовать «обычные» классы?

Question

[Алексей Солодкий]

Недавно начал знакомство с fw Symfony.
Как я понимаю большинство кода в проекте живёт в сервисах - глобальных классах которые подгружают друг друга как зависимости.

Есть задача:
Обойти таблицу в бд и для каждой извлечённой строки выполнить некоторую работу.

Написав сервис я обнаружил что он содержит:
конструктор куда помещаются зависимости (две фабрики и EntityManager),
Один публичный метод который принимает два параметра (пока) Entity из базы и ещё один внешний обьект.
И кучу приватных методов в которые эти два параметра и путешествуют. (именно этот момент с кучей методов практически одинаковой сигнатурой меня и смущает. Однако добавить эти параметры в конструтор я не могу. Так они не статичны а беруться из базы и мне необходимо выполнить метод)

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

Я вижу такой вариант:
Сделать сервис - фабрику который будет на основании этих двух динамических параметров генерировать новый объект описанный абзацом выше. И при этом будет импортировать все зависимости в этот объект.

Насколько корректен такой вариант относительно первого?
Смущает количество параметров для конструктора этого нового объекта (и зависимости и параметры).

Вопрос был поднят так как я хочу логгировать каждую работу на данными отдельно. А это значить что мне надо передавать в исходный сервис ещё один параметр - логгер. И таскать его по приватным методам.
Либо просто добавить метод setLogger к объекту описанному во втором варианте.

Спасибо.

Comments

[Alex]

Лучше бы реальный код привели, а не абстракции

[Алексей Солодкий]

shoomyst:
Реальный код: ideone.com/p2dyMB

Answer 1

[Alex]

Нормальный код на первый взгляд.
Ну можно getBySource() вызывать в public методе, тогда можно два параметра заменить одним. Ну это уже если совсем заняться нечем.
Ну а логгер в вашем коде должен передаваться в конструктор и храниться в свойстве

Comments

[Алексей Солодкий]

i.imgur.com/vtEKugh.png
Тут типичное наследование которые я не могу реализовать так как у меня сервис.

Логировать каждый вызов updateTransactions я хочу в отдельный поток (один поток на AccountSource).
Так что конструктор не вариант.

Answer 2

[Сергей Протько]

Но это не соответствует парадигме фреймворка.

Это нарушает принципы инверсии зависимостей а не "парадигме фреймворка". По сути такие вот штуки ломают принципы ООП и все best-practice которые навыдумывали всякие java-разработчики (и не только java) за последние 20 лет.

Когда имеет смысл вместо сервисов использовать «обычные» классы?

Сервисы - это и есть "обычные" классы. Просто за создание этих классов отвечает отдельный компонент, он один умеет всех создавать и разруливать зависимости что бы вам не пришлось это делать руками. Другой вопрос что если взять какой PHP-DI то он это делает чуть удобнее (за счет автоконфигурации на основе нэймспейсов).

Далее... то что у вас в один класс инджектятся и логгер, и две каких-то фабрики и EntityManager подводит меня к мысли что что бы вы там не делали, вы не стараетесь даже соблюдать принцип единой ответственности. Возможно я ошибаюсь и все это реально нужно... Увы деталей вы не предоставили.

Словом... все это не Symfony-specific штуки, это классическое ООП и только. Если вы распишите задачу чуть по подробнее (хотя бы на уровне интерфейсов) уже можно будет подсказать что-то конкретное. Пока я не вижу ничего плохого в куче приватных методов. Главное что бы интерфейс чистым был. Что-то на уровне:

interface EntityProcessor
{
    public function process(Entity $entity);
}

Comments

[Алексей Солодкий]

код ideone.com/p2dyMB

>Это нарушает принципы инверсии зависимостей
Да, я понимаю. Выразился не корректно.

В моей терминологии сервисы от обычных классов отличаются тем что все параметры сервиса жёстко прописаны в конфиге и не меняются во время исполнения. В то время как "обычный класс" можно создать с динамическими параметрами в конструкторе. (например из бд)

[Сергей Протько]

Алексей Солодкий: ок...

1) вместо EntityManager можно инджектить напрямую репозиторий. И убрать flush из сервиса и перенести его куда-нибудь на уровень выше. Я к примеру делаю flush перед отдачей респонса в большинстве случаев (на уровне ивентов http kernel). Иначе пользы от Unit of work предоставляемого вам доктриной не особо много.

2) merge можно вынести в TransactionsCollection так как ему там самое место. Затем можно заперсистить всю коллекцию одиним махом.

3) Не уверен, но мне кажется что setSource надо делать в loadTransactions и передавать туда accountSource вместо sourceParams. Но это я не трогал ибо не знаю бизнес логики.

4) Не понятно почему у вас accountContextFactory умеет сохранять контексты... тогда это не фэктори а репозиторий.

5) С перечисленными изменениями в том виде в котором вы скинули можно заDRYить обработку транзакций и объеденить все в insertTransactions.

Думаю можно еще код почистить и поразносить. Скажем loadTransactions вообще вынести в репозиторий.

[Сергей Протько]

https://gist.github.com/fesor/ba2892f24e63204eac24 - как бы это выглядило.

[Сергей Протько]

Алексей Солодкий: и да, для меня сервис, это обычный класс который не влазит в слой предметной области. Все те классы которые указывают доменным моделям направления действий и занимаются такой грязной работой как сохранение в базу, кеширование и т.д.

[Алексей Солодкий]

Сергей Протько: 1. Сразу после insert мне нужно провести некую работу надо этими транзакциями. Хотя возможно я смогу обойтись обьектами в памяти не делая по ним выборки в бд. Но в общем случае я бы хотел сохранять элементы после каждого вызова метода.

2. Да идея хорошая если вынести insert из merge.Так как не хочу инжектить в коллекцию репозиторий.

3. Возможно. но это добавить ещё одну зависимость в SourceObject (//$sourceParams = $this->container->get('wt.extractor_params')->extract($sourceParams);)

4. Ок. будет репозиторием.

loadTransactions не связан с бд. Он получает данные из внешнего api.

Обновил работу с коллекциями.
Единственное что всё ещё смущает это куча параметров которые передаются из метода в метод.
https://gist.github.com/XLegion/6a80b80a597eed985038

[Алексей Солодкий]

Сергей Протько: Перефразирую мой основной вопрос:
Когда имеет смысл использовать конструктор объектов напямую или через фабруику вместо использования DI?
т. е создавать каждый раз новый объект с новыми параметрами вместо использования одного экземпляра сервиса и передачи ему этих параметров через метод.

[Сергей Протько]

Алексей Солодкий: вы можете сделать сервис-фабрику, и тогда все зависимости будет хндлить DI.

[Алексей Солодкий]

Сергей Протько: Я понимаю. Именно так я и думал делать в предложенном коде. Вопрос в том когда это имеет смысл?

[Сергей Протько]

Алексей Солодкий: так а что вас смущает? Фабрика как минимум должна знать кого она должна создавать. Все остальные зависимости ей передают (часть в конструктор и часть в параметрах). Все хорошо.

[Алексей Солодкий]

Сергей Протько: Текущий код написан как обычный сервис принимающий параметры в метод.
Его можно переписать на вышеописанную фабрику когда параметры пойдут в конструктор нового объекта (Именно этот вариант описан в конце исходного вопроса.).
Вопрос в том стоит ли это делать в этом конкретном случае а также когда это имеет смысл в общем случае.