Signaler une question sur l'architecture du gestionnaire

Question

J'essaie de disposer d'un service ReportHandler pour gérer la création de rapports. Les rapports peuvent avoir un nombre différent de paramètres pouvant être définis. Il existe actuellement dans le système plusieurs méthodes différentes pour créer des rapports (services de génération de rapports MS, rapports HTML, etc.) et la manière dont les données sont générées pour chaque rapport est différente. J'essaie de tout consolider dans ActiveReports. Je ne peux pas modifier le système ni les paramètres. Ainsi, dans certains cas, je vais essentiellement utiliser une clause where pour générer les résultats, et dans un autre cas, des paires clé / valeur que je dois utiliser pour générer les résultats. J'ai pensé à utiliser le modèle d'usine, mais en raison du nombre différent de filtres de requête, cela ne fonctionnera pas.

J'aimerais bien avoir un seul ReportHandler qui prenne en charge mes entrées variées et crée un rapport. À ce stade, je ne vois pas d'autre moyen que d'utiliser une grande instruction switch pour gérer chaque rapport en fonction du nom du rapport. Avez-vous des suggestions pour mieux résoudre ce problème?

Answer 1

D'après votre description, si vous recherchez un modèle qui correspond mieux à Factory, essayez Strategy:

.

modèle de stratégie

1. Votre contexte pourrait être une classe personnalisée qui encapsule et résume les différentes entrées de rapport (vous pouvez utiliser le modèle AbstractFactory pour cette partie)
2. Votre stratégie pourrait implémenter un nombre illimité de filtres de requête ou de logique supplémentaire. Et si vous avez besoin de changer le système à l'avenir, vous pouvez passer d'un outil de rapport à l'autre en créant simplement une nouvelle stratégie.

J'espère que ça aide!

Answer 2

Outre le modèle de stratégie, vous pouvez également créer un adaptateur pour chacune de vos solutions sous-jacentes. Ensuite, utilisez une stratégie pour les varier. J'ai construit similaire avec chaque solution de rapport étant pris en charge par ce que j'ai appelé les moteurs. En plus de la solution de rapport variable, nous avons une solution de stockage variable - la sortie peut être stockée dans un serveur SQL ou un système de fichiers. Je suggérerais d’utiliser un conteneur puis de l’initialiser avec le bon moteur, par exemple:

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

puis les délégués ReportContainer travaillent sur les moteurs dépendants ...

Answer 3

Nous avons eu un problème similaire et avons opté pour le concept de "connecteurs". qui sont des interfaces entre l’application du générateur de rapports principal et les différents moteurs de rapport. Ce faisant, nous avons pu créer un "serveur de rapports universel". application. Vous devriez le vérifier sur www.versareports.com.