現在のレポート提供の制限（SSRS、Crystal Reports）によって挫折し、ユーザーは主にExcelに精通した財務/ビジネス関係者であるため、Excel SpreadsheetGearやAspose.Cellsのようなコンポーネントを使用して、WinFormsアプリケーションに統合します。拡張可能なレポートエンジンを作成するためのポインタが必要
両方のライブラリは、スプレッドシートビューアのWinFormsコンポーネントを提供するため、生成されたスプレッドシートレポートは、パラメータを保存した後にフォームでユーザーに表示され、保存することができます。
私はこれを別のwinformsプロジェクトでやったことがありますが、それは明らかに簡単です。フォーム内にパラメータコントロールを置くだけで、データベースに接続し、スプレッドシートを生成することができます。
ただし、すべてのレポートでこれを実行すると、明らかに "定型文"のコードとフォームデザインが大幅に重複し、アプリケーションの保守性とアップグレード性が低下します。
このように、レポートを生成するコード/ロジックのみを提供するプラグイン（DLL）としてレポートを作成し、最終ワークシートオブジェクトを呼び出し元に返すことを検討しています（「レポートプレビュー」フォーム） 。
それにいくつかの考えを与えた後、私は、呼び出し元とアドイン間の責任は以下のように共有することだと思う：
レポートDLL /発信者を提供するインを追加します（マスターUI）リストユーザーがこのレポートのために渡す必要があるパラメータの名前と、その可能な値（たとえば、コンボボックスのリスト）を指定します。
フォーム上にマスターUIを作成するのは、マスターUIまでです。コントロールの型は、パラメータのデータ型（文字列はTextBoxなど）に基づいて推論されます。
マスターUIは、アプリケーション固有の設定（接続文字列、アプリケーションのユーザー名）とともに、埋め込まれたパラメータをレポート生成メソッドにレポートDLLに渡します。
レポートDLLはレポートを生成し、生成されたワークシート/レポートオブジェクトをマスターUIに戻してプレビューコントロールに表示します。技術的にはこれを実現するために
、私は私が私のレポートDLLのインターフェイスを作成する必要があると信じている、とマスターのUIから
List<ReportParameter> GetReportsParameters()
Report GenerateReport()
のようなメソッドを実装して、私はそれらにアクセスし、リフレクションを介してそれらを呼び出します。
これは良い戦略のように聞こえますが、今後の拡張性のために適切な余地を残していますか？ アドインアーキテクチャが将来的にはあまりにも静的であるため、モジュール性と柔軟性が制限されていない間に、適切なバランスを取っていきたいと考えています。
過去に似たようなことを達成したことがあれば、これを確実に共有するためのヒントがありますか？
ありがとうございます。
（私はC＃、.Net 4.0およびWinFormsで開発中です。データベースのバックエンドはSQL Server 2005です）。
また、MEF（Microsoft Extensibility Framework）やMAF（Microsoft Add-in Framerwork）などのMS技術が役立ちますか？それとも、彼らはこのために過労だと思われますか？ –