Лучший способ пойти о сериализации и десериализации объекта, не теряя его слушателей?

Question

Лучший способ пойти о сериализации и десериализации объекта, не теряя его слушателей?

Вы смешиваете два способа внедрения зависимости ( https://en.wikipedia.org/wiki/Dependency_injection#Three_types_of_dependency_injection ). Вы должны создать правильный конструктор, и только этот construstor должен быть @Autowired. Ваш класс должен выглядеть примерно так:

private Source source;
private AWSProperties awsProperties;
private AuditRepository auditRepository;
private AmazonSQS sqs;

@Autowired
public SqssreaderApplication(Source source, AWSProperties awsProperties, AuditRepository auditRepository, AWSConfig awsConfig) {
    this.sqs = awsConfig.generateSQS();

Затем в своем тесте вы можете изменить свой подход # 1 и добавить все необходимые макеты через конструктор. Небольшой оффтоп: вы используете AWSProperties как в классах AWSConfig, так и в классах SqssreaderApplication. Проверьте, действительно ли вам это нужно в SqssreaderApplication.

7

serialization java

задан 25 September 2008 в 07:14

5 ответов

Другие вопросы по тегам:

serialization java

Похожие вопросы:

score 3 · Answer 1

При реализации readObject (), можно восстановить переходное состояние как часть десериализации. Необходимо рассматривать десериализацию как объектную конструкцию (потому что это).

   private void readObject(ObjectInputStream in) 
       throws ClassNotFoundException, IOException {
     // do normal serialization first!
     in.defaultReadObject();

     // put code here that can somehow reconstruct your listeners
     // presumably you have someplace you can look them up
  }

score 2 · Answer 2

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

score 0 · Answer 3

Я создал бы отделенную платформу события, подразумевая, что производитель события не будет связан непосредственно с потребителем события. Это могло состоять из EventManager, EventProducer и EventListener, сотрудничающий с, публикуют/подписывают семантику.

Когда система запускает (или на первом использовании), EventManager создается.
EventListener регистрирует себя для получения определенного вида событий.
EventProducer производит события публикование их к EventManager

    public interface EventManager {
        public void postEvent(Event event);
        public void addListener(Class eventType, EventListener listener);
    }

    public interface EventListener {
        public void handleEvent(Event event);
    }

Таким образом при сериализации производителя затем, EventManager все еще ведет список подписанных слушателей. когда объект десериализовывается затем, он может все еще отправить события на EventManager.

score -1 · Answer 4

Используйте реестр, в котором регистрируются и Ваш издатель и подписчики. Как был отправлен Korros, он упоминается как Шаблон Электронной доски на земле OSGI.

score -1 · Answer 5

В целом я не распознал полезного шаблона для этого. Но комбинация нескольких будет в порядке :). Вопрос состоит в том, как Вы обрабатываете десериализацию? При использовании стандартного пути можно представить механизм поиска, который будет использоваться, чтобы определить местоположение локальных слушателей и оживиться их к недавно десериализованному экземпляру. Если у Вас будет собственный deserializer, то путь будет более простым. Просто десериализуйте объект и зарегистрируйте локальных слушателей. deserializer может действовать как слушатель прокси, если это возможно. Представление некоторой отделенной модели должно быть также полезным, как сказал Panagiotis. Точное решение зависит Вашей реальной потребности, но не забывайте к KISS это.