Схема трубопровода для обработки сообщений

Question

У меня есть набор служб (не WCF), которые сидят в очередях. Когда приходит сообщение, типичная услуга выполняет некоторые вычисления и выплескивает в выходную очередь ноль или более сообщений результатов. Помимо своей основной функции, каждая служба имеет некоторую логику ведения хозяйства, такую ​​как аут-аут/аудит/протоколирование/отслеживание состояния с точными шагами и последовательностью, несколько различающимися между службами. Вот где понятие конвейера входит в картину.

Я не доволен дизайном, в котором мы оказались, и ищем способы упростить его. Должен ли я моделировать порты CCR? Конвейер ASP.NET? АОП? Что-нибудь еще?

Мой текущий проект выглядит следующим образом: у меня есть интерфейс IMessageHandler<TMessage> и около 15 реализаций, которые объединены в 6 уникальных способов с помощью IoC. Интерфейс определяет один метод: Handle (TMessage msg), поэтому каждая реализация может выполнять некоторую логику как до, так и после передачи сообщения следующему обработчику в цепочке.

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

Идеи? Любые хорошие схемы трубопроводов, на которые я могу смотреть? Любые хорошие реализации конвейера, которые я могу использовать в качестве ссылки? Или я должен JFHCI?

Answer 1

Я использую дизайн, который вы выбрали довольно часто, не всегда с IoC.

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

Во-первых, вы можете в значительной степени прокомментировать свой код. Это часто - это запах и во многом зависит от реализации. Вы также можете комментировать, назначая свои конфигурации IoC определенным образом.

Во-вторых, вы можете создавать сгустки объектов. Например, если есть три объекта, которые, как правило, запускаются вместе, вы можете создать класс «AuthorizeAndAudit», который делегирует другим объектам (возможно, построенный с использованием IoC и «семейств плагинов» или независимо от того, что ваш контейнер вызывает их, если поддерживается). Это лучше связывает намерение объектов. У меня, как правило, есть коллекция IMessageHandler, которая также реализует IMessageHandler и делает foreach сама по себе.

В-третьих, вы можете выделить интерфейсы. Похоже, у вас может быть ситуация, когда вы разбиваете объекты только потому, что они содержат действия, которые происходят в разных частях цепочки. Вы можете создать один интерфейс (или метод для общего интерфейса) для аутентификации, один для аудита и т. Д. Ваши объекты могут реализовываться на или более этих интерфейсах. Поскольку порядок интерфейсов определен (вызов Auth then Audit и т. Д.), Ваши объекты могут решать несколько шагов в цепочке (в итоге вы получаете цепочку цепочек) без необходимости разбивать на отдельные классы. У вас может быть даже объект, похожий на трассировщик журналов, который находится на всех цепочках и журналах, когда вызывается каждый шаг.

Помимо того, что вы начинаете проникать во что-то более сложное, например рабочий процесс, и рабочий процесс Windows может быть хорошим местом для поиска.

Answer 2

Я часто пишу код, похожий на то, что вы описываете. Чтобы очистить код, я добавляю слой «синтаксического сахара», который объединяет объекты, которые будут выполнять работу приложения во время выполнения, а также четко выражает то, что делает конечный граф объектов.

Steve Freeman и я написал статью о методах, которые мы используем в Java, для создания этого слоя синтаксического сахара: http://www.jmock.org/oopsla2006.pdf. Я использовал те же самые методы на языках C# и других языках Algol и создал довольно сложные «встроенные языки для конкретных доменов», включая встроенные языки для описания моделей финансового рынка, распределенных системных архитектур, стеков протоколов связи, поведения спрайтов в играх и т. Д. на.