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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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