Интерфейс для получения всех интерфейсов...

Не пишу интерфейсы тем более для сервисов. Ладно ещё репозитрий (хотя тоже холивар), но какой профит от сервиса?

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

Всем привет! Подскажите, как вы используете интерфейсы для сервисов? У меня три варианта: 1) Для каждого сервиса пишется свой интерфейс 2) Не писать интерфейсы 3) Писать общие интерфейсы. Например, многие сервисы имеют методы getAll() и getById(). Третий вариант мне нравится, но меня вот что коробит. Если такой интерфейс написать, то там нельзя будет указать возвращаемый тип, потому что метод getById в UserService вернет User, а в CarService вернет Car. Дальше мне приходит мысль объединить все entity общим интерфейсом, например EntityInterface и его возвращать в методе getById в интерфейсе для сервисов. Но тут возникает вопрос: нормально ли, что в интерфейсе будет одно возвращаемое значение, а в реализации другое? Поделитесь, пожалуйста, как вы используете интерфейсы

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

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

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

Кого делить? Сущности?

Ну я вижу три варианта: 1) Сущность участник БЛ, рич моделька. Логика в сущностях + сервисах. 2) Сущность не участник БЛ, анемик моделька, логика в сервисах 3) Харкор, но прям очень спорный. Сущность не участник БЛ, анемик моделька, есть отдельные Сущности не доктрины, на которые мапятся сущности доктрины. Вот уже эти сущности рич, участвуют в БЛ.

Ну вот третий вариант видел в ддд проекте, где у домена всё своё внутри, а стейт сохраняется через ивенты вообще ) Т.е. мапинг на сущности доктрины в ивентах домена и в бд. Потом задался вопросом на кой член так делать вообще? чем плоха ентитя доктрины как дто?

Ну вот третий вариант видел в ддд проекте, где у домена всё своё внутри, а стейт сохраняется через ивенты вообще ) Т.е. мапинг на сущности доктрины в ивентах домена и в бд. Потом задался вопросом на кой член так делать вообще? чем плоха ентитя доктрины как дто?

А чем ентити доктрины не домен? Про ентития доктрины = дто вообще не понял. Я такой подход видел на стековерфлоу как для жуткого интерпрайза, который вообще ото всего наружнего открещивается

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

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

Персистенс итак спрятан за mapper

так ентитя часть доктрины, считай персистенс слой

так ентитя часть доктрины, считай персистенс слой

Почему ты так решил? Если маппинг лежит где то сбоку, каким образом чистый php класс в твоем проекте - это доктрина?

А почему ентити доктрины это персистенс? Представь что ты пилишь домен, написал сущности, написал репозитории. Потом такой, а возьму ка я доктрину и написал рядом xml маппинг.

Даже если в аннотациях лежит, это нормально

Ну тут спорно, потому что меняем персистенс - лезем в слой домена для изменений. Хотя сам юзаю онли анотации/атрибуты. Не вижу смысла для спора :)

поэтому в репозиториях доктрины появились методы save\remove? 😄

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

Бизнес логика в орм приводит к тому что в определенный момент тебе вообще стремно делать flush() потому что без понятия сколько всего будет сделано под капотом и что там происходит

И иногда тебе нужно просто сделать флаш, без бизнес логики

Странный флоу

Этот холивар уже был

Для цикла и атомарности придумали транзакции

флаш и так транзакция )

И ты такой сори у меня тут бизнес логика на любой чих изменения модели

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

А если нужно руками?

Дать возможность менять из админки супер админу какому-то

Так у тебя там бизнес логика

Никто не мешает. Вопрос насколько это все удобно и хорошо

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

Если бизнес логика не привязана к орм это проще сделать

Ну а о чем тут разговор?

@Cawa87

а почему именно c помощью symfony отправляете логи?