Здравствуйте, vaa, Вы писали:
vaa>В проектах на сишарпе часто вижу такие классы как PersonManager. vaa>В чем возможная отличительная семантика от PersonService
Service обслуживает Person, а Managerа обслуживают Personы.
Здравствуйте, vaa, Вы писали:
vaa>В проектах на сишарпе часто вижу такие классы как PersonManager. vaa>В чем возможная отличительная семантика от PersonService
Одно и то же.
Я бы сказал, что Service точно должен быть stateless.
А Manager может иметь какое-то состояние.
Manager управляет объектами. Загрузить, сохранить, смерджить и тд. Вообще обычно такой класс называется Repository, если речь идёт о чём-то вроде БД.
Service предоставляет некие сервисы для объектов. К примеру определить полное имя человека или проверить контрольную сумму ИИНа. ООП парадигма предписывает подобный функционал класть рядом с данными, то бишь в класс Person, но некоторые практикуют альтернативный подход, когда поведение и данные разделяются. Вот PersonService можно считать неким универсальным именем для поведения, которое связано с классом Person.
Здравствуйте, vaa, Вы писали:
vaa>В проектах на сишарпе часто вижу такие классы как PersonManager.
За такие названия надо сразу отрубать руки. И лучше ноги, чтобы не размножался.
Я на проектах часто запрещал такие нейминги в принципе. Они ничего не дают.
Здравствуйте, vsb, Вы писали:
vsb>Manager управляет объектами. Загрузить, сохранить, смерджить и тд. Вообще обычно такой класс называется Repository, если речь идёт о чём-то вроде БД.
vsb>Service предоставляет некие сервисы для объектов. К примеру определить полное имя человека или проверить контрольную сумму ИИНа. ООП парадигма предписывает подобный функционал класть рядом с данными, то бишь в класс Person, но некоторые практикуют альтернативный подход, когда поведение и данные разделяются. Вот PersonService можно считать неким универсальным именем для поведения, которое связано с классом Person.
В джава энтерпрайзе такое практикуется, называется анемичная модель. Т.е. доменные классы анемичные, хилые, содержат лишь поля, а вся бизнес-логики (мощь) находится в сервисах. Тем самым ООП подменяется процедурным стилем. Попытки делать настоящее ООП, например по методологии DDD, обычно ни к чему хорошему не приводит, потому что у среднего разработчика мозговых силёнок не хватает, чтобы запилить правильное DDD, выходит какаха. Поэтому джависты пилят примитивную анемичную процедурную парадигму, гребут бабло и не парятся такой ерундой, как тръу ООП. Благо, что бизнесу другого и не надо, чем проще — тем надёжнее, тем более и других задач хватает — транзакционность, реактивность, ИБ и прочие энтерпрайзные практики соблюдать, которые гораздо важнее для бизнеса, чем сомнительный ООП.
