Юра
Но если к примеру там просто геттер который возвращает полное имя конкатенируя имя и фамилию не вижу ничего в этом плохогр
Maxim Kainov
Юра
Ну да
Юра
В общем могу сказать что я использовал rich модели в своё время но в итоге отказался от этой идеи потому что она плохо масштабировалась
Юра
Но иногда надо самому к этому прийти чтобы понять
Гена
И? Теперь у вас куча сервисов которые манипулируют анемичными сущностями?
Юра
Да есть разные способы. Но по сути да сервисы которые манипулируют моделями
Юра
Анэмичные слово ещё тако, негативное
Юра
Тогда давайте назвать не РИЧ модели а жирные
Гена
То есть по сути вы занимаетесь процедурным програмированием.
множеством методов манипулируете структурами данных.
Юра
Ну под это определение попадает что угодно
Dmitry
Как пример "для чего дто"
На сайте заполняется форма из n+ полей, данные потом раскидываются на m+ entity, причем часть полей не мапится в entity, а служит индикатором или параметром для дальнейших действий или вычислений.
Поэтому я лучше приму данные и провалидирую, в dto, а уж потом сделаю нужные вычисления и кину данные в entity
Юра
Я не отрицаю что дто это плохо, просто не пойму зачем его использовать всегда
Юра
К примеру на обычные круд операции
Юра
Да и я не против дто, скорее против рич моделей
Юра
У нас на проекте вообще была аннлтация в контроллере типо какой класс дто использовать, а дальше оно само мапило в дто и валидирлвало, в итоге в контроллер приходила всегда валидная дто
Гена
Ну под это определение попадает что угодно
Ну так ООП с анемичной моделью я не вижу. Инкапсуляции уже нет. Методы для работы с сущностью гуляют где-то снаружи как было до ООП.
CRUD мы сейчас не рассматриваем. Там по сути форма мапится на дб.
Но ведь проекты это чаще всего не CRUD
Юра
А кто вам вообще сказал что orm это про ООП
Юра
Вы можете вообще без геттеров сеттеров работать
Юра
Орм это механизм мапинга объектов
Юра
То ято вы налепили туда логики и назвали это ооп эио чисто ваша заслуга
Гена
если у вас в слое бизнес логики есть полноценные сущности, а анемичные используются только для маппинга то я не прав конечно
Maxim Kainov
То есть по сути вы занимаетесь процедурным програмированием.
множеством методов манипулируете структурами данных.
В книге чистый код рассказывается, что оба подхода применимы в зависимости от ситуации, как объектный, так и процедурный, где операции выполняются над структурами данных.
Maxim Kainov
если у вас в слое бизнес логики есть полноценные сущности, а анемичные используются только для маппинга то я не прав конечно
Да, в слое бизнес логики сервисы, выполняют операции над структурами данных.
Сергей
А чего за фигня в доктрине с orphanRemoval?
Удаляю связанную сущность. В итоге вместо одной этой сущности удаляются все, связанные с родительской?
Maxim Kainov
Гена
Да, в слое бизнес логики сервисы, выполняют операции над структурами данных.
Ну каждый подход имеет право на жизнь. Мне ближе ООП.
Сервисы у меня в слое бизнес логики выполняют операции по взаимодействию между бизнес сущностями. Но своими делами каждая сущность занимается сама.
Maxim Kainov
Ну так ООП с анемичной моделью я не вижу. Инкапсуляции уже нет. Методы для работы с сущностью гуляют где-то снаружи как было до ООП.
CRUD мы сейчас не рассматриваем. Там по сути форма мапится на дб.
Но ведь проекты это чаще всего не CRUD
Почему снаружи. Можно проводить границы компонентов, слоев.
Гена
а что у нас кроме геттеров и сеттеров в анемичной модели осталось?
Maxim Kainov
Ну каждый подход имеет право на жизнь. Мне ближе ООП.
Сервисы у меня в слое бизнес логики выполняют операции по взаимодействию между бизнес сущностями. Но своими делами каждая сущность занимается сама.
А если сущность выполняла операцию сама р вдруг ей поеадобилось взаимодействовать с другой? То как, переносить все в сервис?
Maxim Kainov
а что у нас кроме геттеров и сеттеров в анемичной модели осталось?
Простые операции над данными, вычисляемые поля
Гена
А если сущность выполняла операцию сама р вдруг ей поеадобилось взаимодействовать с другой? То как, переносить все в сервис?
Ну если сущность вдруг зачем-то сама отправляла Email то это ошибка проектирования. Нет?
Maxim Kainov
Ну каждый подход имеет право на жизнь. Мне ближе ООП.
Сервисы у меня в слое бизнес логики выполняют операции по взаимодействию между бизнес сущностями. Но своими делами каждая сущность занимается сама.
Если в объекте много разных операций, которые изменяются в разное время по разным причинам? Как их разделить? На каждое поле по ембедед классу? Как здесь следовать принципу единой ответственности.
Maxim Kainov
Ну если сущность вдруг зачем-то сама отправляла Email то это ошибка проектирования. Нет?
Ну нет. Если она например валидировала поля, и тут ей вдруг понадобилось внешнее взаимодействие для этого.
Юра
А чего за фигня в доктрине с orphanRemoval?
Удаляю связанную сущность. В итоге вместо одной этой сущности удаляются все, связанные с родительской?
Оно удаляет сущности у которых нет больше связи
Юра
А не только связи
Юра
Стремная штука
Сергей
Оно удаляет сущности у которых нет больше связи
Да, но связь то есть.
Там связь по oneToMany. Вот мне одну из этих many надо удалить. Я вызываю removeTag(), например. И он вместо одного тега удаляет все нехер))
Maxim Kainov
Гена
Если в объекте много разных операций, которые изменяются в разное время по разным причинам? Как их разделить? На каждое поле по ембедед классу? Как здесь следовать принципу единой ответственности.
Если все эти операции в зоне отвественности данной сущности то SRP мы не нарушаем.
Нужно еще понимать что я в контексте идей DDD пишу.
Но не смотря на это и у меня полно тонких моделей. Когда сущность по сути и создана для хранения данных. И логики в ней просто нет.
Maxim Kainov
Если все эти операции в зоне отвественности данной сущности то SRP мы не нарушаем.
Нужно еще понимать что я в контексте идей DDD пишу.
Но не смотря на это и у меня полно тонких моделей. Когда сущность по сути и создана для хранения данных. И логики в ней просто нет.
По срп изменения должны быть в одно время и по одной причине. Причина это актор. С одной сущностью могут работать разные акторы.
Maxim Kainov
Так можно на каждую операцию сделать сервис если захотеть. А как без сервисов это сделать.
Сергей
Где то у тебя косяк
короче если кому интересно - было так
public function setSteps($steps): self
{
$this->steps = $steps;
return $this;
}
сделал так
public function setSteps($steps): self
{
$this->steps->clear();
foreach ($steps as $step) {
$this->steps->add($step);
}
return $this;
}
теперь всё работает
Сергей
ууу
Maxim Kainov
короче если кому интересно - было так
public function setSteps($steps): self
{
$this->steps = $steps;
return $this;
}
сделал так
public function setSteps($steps): self
{
$this->steps->clear();
foreach ($steps as $step) {
$this->steps->add($step);
}
return $this;
}
теперь всё работает
У тебя степс не должен быть массивом
Maxim Kainov
Если все эти операции в зоне отвественности данной сущности то SRP мы не нарушаем.
Нужно еще понимать что я в контексте идей DDD пишу.
Но не смотря на это и у меня полно тонких моделей. Когда сущность по сути и создана для хранения данных. И логики в ней просто нет.
Есть заказ, создать его может покупатель, а может менеджер. Два актора. Как ты их разделишь, две ентити сделаешь?
Maxim Kainov
Ты сделаешь сервисы, а общую логику поместишь в ентити. Но если логика будет меняться, тебе придется постоянно прекидывать код из ентити в сервисы и обратно.
Гена
Сергей
Ты сделаешь сервисы, а общую логику поместишь в ентити. Но если логика будет меняться, тебе придется постоянно прекидывать код из ентити в сервисы и обратно.
в методе создания заказа у него не будет логики. Там по сути фабрика createByManager, createByClient.
А логика будет во внешнем сервисе/юзкейсе
Maxim Kainov
в методе создания заказа у него не будет логики. Там по сути фабрика createByManager, createByClient.
А логика будет во внешнем сервисе/юзкейсе
Ну изначально он пишет код создания заказа для клиента, про менеджера еще не известно. Он пишет его просто в ентити. Потом вдруг появляется мененджер. И придется из энтити переносить код в сервис. А если бы он изначально был в сервисе, то перенести было бы проще.
Maxim Kainov
в методе создания заказа у него не будет логики. Там по сути фабрика createByManager, createByClient.
А логика будет во внешнем сервисе/юзкейсе
Два разных актора в одном объекте. Нарушение срп.
Maxim Kainov
То есть, два разных сценария использования
Юра
Я думаю не зря энтити в симфе не являются сервисами
Юра
Репозитории являются
Юра
Энтити явно внесены в exclude
Юра
Они нам как бы намекают
Гена
То есть, два разных сценария использования
Почему вы решили что логика создания заказа у клиента и менеджера одна?
Я вижу что это 2 разных контекста. И рамках каждого тот же Заказ может быть как полноценной сущностью так и просто структурой данных.
Ваш вариант с сервисами что будет делать если создание заказов у каждого будет свое? Появится 2 сервиса? Потом 20 сервисов?
Гена
пример вообще не удачный
так как Покупатель или Менеджер не являются владельцами Заказа.
Гена
А вот Заказ и Товарные Позиции
Maxim Kainov
Почему вы решили что логика создания заказа у клиента и менеджера одна?
Я вижу что это 2 разных контекста. И рамках каждого тот же Заказ может быть как полноценной сущностью так и просто структурой данных.
Ваш вариант с сервисами что будет делать если создание заказов у каждого будет свое? Появится 2 сервиса? Потом 20 сервисов?
У них могут быть как общие правила, так и разные
Гена
Заказ вполне может иметь нужные методы для упраления ТП входящими в него
Гена
сервис в данном случае это отказ от ООП
Maxim Kainov
Почему вы решили что логика создания заказа у клиента и менеджера одна?
Я вижу что это 2 разных контекста. И рамках каждого тот же Заказ может быть как полноценной сущностью так и просто структурой данных.
Ваш вариант с сервисами что будет делать если создание заказов у каждого будет свое? Появится 2 сервиса? Потом 20 сервисов?
Да, 20 сервисов. Что плохого в 20 сервисах?
Гена
У них могут быть как общие правила, так и разные
А значит это тот самый случай когда мы создаем сервис для взаимодействия между разными моделями
Maxim Kainov
пример вообще не удачный
так как Покупатель или Менеджер не являются владельцами Заказа.
Какая разница кто владелец
Maxim Kainov
А значит это тот самый случай когда мы создаем сервис для взаимодействия между разными моделями
Еще раз. Тебе придется переносить логику из ентити в сервис, что будет трудоемко. Поэтому, лучше сразу писать логику в сервисе.
Гена
Еще раз. Тебе придется переносить логику из ентити в сервис, что будет трудоемко. Поэтому, лучше сразу писать логику в сервисе.
Не приедтся потому что это вы зачем то запихнули на этапе проектирования создание заказа в модель Покупателя
Maxim Kainov
Maxim Kainov
Ооп же
Гена
что ооп?
Гена
Суть в том что если вы в бизнес слое всю бизнес логику размазываете по сервисам это существенно ухудшает структуру и поддержку проекта.
Бизнес логика все таки должна отражать реальный мир. При общении с теми же заказчиками.
Maxim Kainov
Суть в том что если вы в бизнес слое всю бизнес логику размазываете по сервисам это существенно ухудшает структуру и поддержку проекта.
Бизнес логика все таки должна отражать реальный мир. При общении с теми же заказчиками.
Объект не должен изменять поля других объектов. Закон деметры вроде как.
Maxim Kainov
Он может изменять структуры
Maxim Kainov
Или свои поля
Anonymous
Господа как часто вам предлагали выполнить тестовое на псевдокоде и в формате пдф
Anonymous
Мне вот предложили и стало несмешно
Maxim Kainov