Являются ли несериализуемые свойства `Props` антипаттерном?

Question

Пример:

Предположим, у меня есть субъект, который управляет связью с некоторой внешней службой, поэтому у него есть объект Client внутри него для выполнения запросов к внешней службе. Чтобы избежать превращения этого актора в монолитный c, я мог бы создать дочерних акторов для обработки различных частей взаимодействия: поддержания пульса службы, выполнения и координации сложных запросов и т. Д. c. Этим дочерним акторам потребуется ссылка на Client службы.

Учитывая, что эти клиентские объекты вряд ли будут сериализованы и могут иметь состояние, например, содержат состояние соединения, является ли их антишаблон для передачи их в дочерние актеры через Props? Документация Akka, кажется, настоятельно рекомендует поддерживать сериализуемые свойства, но в данном случае это кажется чрезвычайно ограничивающим.

Answer 1

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

Мне не известно об этом предложении, не могли бы вы поделиться ссылкой в ​​вопросе?

From По моему опыту, довольно часто эти Client ссылки передаются от родительских акторов к дочерним. Иногда я могу передать точный метод (функцию) вместо ссылки Client для простоты модульного тестирования. Пока вы не создаете актера через границу сети, я не вижу причин, почему это плохо.

Относительно объекта Client, который вы описываете, для вещей сетевого уровня (например, , состояние подключения и т. д. c) Я буду использовать API клиента akka-http . Если бы вы оставили вещи на уровне приложения, я бы предпочел, чтобы для такого использования был выделен отдельный субъект. Для меня это звучит немного антипаттерном - сохранять состояние приложения в неактере при условии, что у вас есть актор Akka, который предназначен для размещения состояния.