Report Handler Architektur Frage

Question

Ich versuche, einen ReportHandler Service haben die Berichterstellung zu behandeln. Die Berichte können mehrere, unterschiedliche Anzahl von Parametern, die eingestellt werden können. In dem System zur Zeit gibt es verschiedene Methoden zur Erstellung von Berichten (MS Reporting Service, HTML-Berichte, etc.) und die Art und Weise der Daten für jeden Bericht erzeugt werden, ist unterschiedlich. Ich versuche, alles in Activereports zu konsolidieren. Ich kann nicht das System ändern und die Parameter ändern, so dass in einigen Fällen werde ich im Wesentlichen ein, wo Klausel, um die Ergebnisse zu erzeugen, und in einem anderen Fall werde ich Schlüssel / Wert-Paare bekommen, dass ich die Ergebnisse zu erzeugen, verwenden muß. Ich dachte über die Fabrik Muster verwenden, sondern auch wegen der unterschiedlichen Anzahl von Abfragefiltern dies wird nicht funktionieren.

Ich würde gerne einen einzigen ReportHandler haben, die meine vielfältigen Eingänge nehmen und Bericht ausspucken. An diesem Punkt bin da ich keine andere Möglichkeit, als eine große switch-Anweisung zu verwenden, um jeden Bericht zu behandeln basierend auf dem Report. Irgendwelche Vorschläge, wie ich könnte das besser lösen?

Answer 1

Aus Ihrer Beschreibung, wenn Sie nach einem Muster suchen, die als Fabrik besser passen, versucht Strategie:

Strategy-Muster

1. Kontext könnte eine benutzerdefinierte Klasse sein, die die verschiedenen Berichts Eingänge kapselt und Abstracts (Sie Abstrakte Muster für diesen Teil verwenden könnte)
2. Strategie eine beliebige Anzahl von verschiedenen Abfragefiltern implementieren könnte oder zusätzliche Logik erforderlich. Und wenn Sie jemals das System in Zukunft ändern müssen, können Sie zwischen Report-Tool, indem Sie einfach eine neue Strategie zu schaffen.

Ich hoffe, das hilft!

Answer 2

Neben der Strategie-Muster, können Sie auch einen Adapter für jede Ihrer zugrunde liegenden Lösungen erstellen. Dann nutzen Strategie, sie zu verändern. Ich habe gebaut ähnlich mit jedem Bericht Lösung unterstützt wird, was ich Motoren genannt, neben die variablen Bericht Lösung haben wir variable Speicherlösung als auch - Ausgabe kann in SQL-Server oder Dateisystem gespeichert werden. Ich würde vorschlagen, einen Behälter verwenden, dann es mit dem richtigen Motor zu initialisieren, z.

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);

dann ReportContainer Delegierten zusammenarbeiten, um die abhängigen Motoren ...

Answer 3

Wir hatten ein ähnliches Problem und ging mit dem Konzept der „Anschlüsse“, die Schnittstellen zwischen dem Haupt Berichtgenerator Anwendung und den verschiedenen Berichts Motoren sind. Auf diese Weise konnten wir eine „Universal-Berichtsserver“ Anwendung erstellen. Sie sollten es auf www.versareports.com überprüfen.