Нужен шаблон дизайна

Question

Я собираюсь разработать инструмент, который будет делать следующее:

• собирать файлы с удаленного сервера - периодически каждые несколько минут.
• Экспорт собранных файлов в один файл.

От клиента он отправляет запрос на сервер каждые 5 или 10 минут. Затем сервер отправляет список файлов. Эта часть называется «коллекция». После «сбора» необходимо выполнить «экспорт» (объединить все файлы, которые были собраны за период «сбора».

Моя идея заключается в том, что вышеуказанные действия по сбору и экспорту похожи на «производитель» и «потребитель». Итак, могу ли я использовать шаблон «наблюдатель» для реализации вышеуказанных действий? Если нет, предложите любой другой шаблон проектирования.

С уважением, Каннан Д.В.

Answer 1

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

Однако, если вы хотите получать уведомления от сборщика , вы действительно можете посмотреть шаблон Observer:

Наблюдатель. Определите зависимость один-ко-многим между объектами, чтобы при изменении состояния одного объекта все его иждивенцы уведомлялись и обновлялись автоматически.

С другой стороны, как я понимаю, экспорт не выполняется, когда Exporter запрашивает его, но через фиксированные интервалы, поэтому Exporter может получить Collection в любое время, поэтому вам, вероятно, понадобится какой-нибудь механизм кэширования в Collector (а не система уведомлений).

Answer 2

Здесь можно применить шаблон наблюдателя с правильным дизайном ... В настоящее время вы опрашиваете свой сервер и перевариваете данные, которые по своей сути не поддаются шаблону наблюдателя (если я правильно понял ваш пост). Здесь есть два хороших варианта: сервер должен уведомлять очередь JMS, когда изменения / обновления / дополнения готовы к экспорту, а затем вы можете использовать шаблон наблюдателя для получения сообщений и их дайджеста. В качестве альтернативы, вы можете сделать так, чтобы ваш сервер публиковал данные в фиде (например, RSS), а затем имел службу, которая опрашивает фид и создает уведомление (при наличии изменений с момента последнего обновления фида). Тогда вы могли бы использовать шаблон наблюдателя, чтобы переварить данные.

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

Надеюсь, это поможет.

Answer 3

Сервер не может предварительно уведомить сборщик, поэтому сборщик опрашивает сервер.Это означает, что между сборщиком и сервером не существует шаблона наблюдения.

Если вы хотите, чтобы экспортер запускал свой процесс автономно, вы можете предоставить ему BlockingQueue, в который сборщик помещает уведомление (т. Е. Объект 'Job', указывающий, какие файлы необходимо экспортировать).Экспортер неоднократно вызывает queue.take () для получения следующего задания.Обратите внимание, что BlockingQueue.take () ожидает, пока элемент не станет доступным в очереди, без загрузки процессора.См .: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html, который включает в себя пример кода.

Answer 4

Трудным моментом здесь является обеспечение / управление тем, что производитель должен знать, что потребитель успешно получил коллекцию.

Когда он отправляет файлы, но не получает квитанцию ​​о подтверждении, он делает это автоматическипросто оставьте файлы на месте для следующей коллекции и дайте потребителю разобраться со всем этим, или ему нужен пользовательский интерфейс, чтобы управлять им как человеческой задачей, или как?

Answer 5

Звучит многообещающе. Чтобы дать хороший совет, кому-то может понадобиться больше информации о вашем контексте и ваших ожиданиях от инструмента. Это зависит от вас, чтобы найти правильное распределение ответственности для ваших компонентов.

Я нахожу эту статью очень полезной, чтобы найти правильное разделение компонентов:

ссылка О критериях, используемых при разложении систем на модули