Вопрос об архитектуре обработчика отчетов - PullRequest
Новая
       35

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

3 голосов
/ 10 октября 2008

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

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

Ответы [ 3 ]

3 голосов
/ 11 октября 2008

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

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 делегирует работу зависимым механизмам ...

3 голосов
/ 10 октября 2008

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

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

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

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

0 голосов
/ 14 сентября 2009

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

...