Вопрос об архитектуре обработчика отчетов

Question

Я пытаюсь создать службу ReportHandler для создания отчетов. Отчеты могут иметь несколько различных значений параметров, которые могут быть установлены. В настоящее время в системе существует несколько различных способов создания отчетов (службы отчетов MS, отчеты html и т. Д.), И способ генерирования данных для каждого отчета различен. Я пытаюсь объединить все в ActiveReports. Я не могу изменить систему и изменить параметры, поэтому в некоторых случаях я по существу получаю предложение where для генерации результатов, а в другом случае я получу пары ключ / значение, которые я должен использовать для генерации результатов. Я думал об использовании фабричного шаблона, но из-за разного количества фильтров запросов это не сработает.

Я бы хотел иметь единственный ReportHandler, который бы принимал мои разнообразные входные данные и выплевывал отчет. На данный момент я не вижу другого способа, кроме как использовать большой оператор switch для обработки каждого отчета на основе reportName. Любые предложения, как я мог бы решить это лучше?

Answer 1

Из вашего описания, если вы ищете шаблон, который лучше, чем Factory, попробуйте Стратегию:

Шаблон стратегии

<Ол>

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

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

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

Answer 2

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

public class ReportContainer{
          public ReportContainer ( IReportEngine reportEngine, IStorageEngine storage, IDeliveryEngine delivery...)
}
}

/// In your service layer you resolve which engines to use
// Either with a bunch of if statements / Factory / config ... 

IReportEngine rptEngine = EngineFactory.GetEngine<IReportEngine>( pass in some values)

IStorageEngine stgEngine = EngineFactory.GetEngine<IStorageEngien>(pass in some values)

IDeliverEngine delEngine = EngineFactory.GetEngine<IDeliverEngine>(pass in some values)



ReportContainer currentContext = new ReportContainer (rptEngine, stgEngine,delEngine);

тогда ReportContainer делегирует работу зависимым механизмам ...

Answer 3

У нас возникла похожая проблема, и мы решили использовать понятие «соединители». это интерфейсы между основным приложением генератора отчетов и различными механизмами отчетов. Благодаря этому мы смогли создать «универсальный сервер отчетов». приложение. Вы должны проверить это на www.versareports.com.