私のWebプロジェクトには、急速に成長しているTelerikレポートのセットがあります。私のデータ提供戦略は、各レポートにSQLクエリを含む会社のテキストファイルがあることです。長い'xis in（y、z、a、b、c ....）'、または'（（x = 1）and（x <y））'のような複雑なフィルター基準を処理し、100回繰り返します、レポートのDataTableを取得するために使用する前に、テキストファイルクエリでテキスト置換を実行します。
すべてのレポートは、から派生したクラスでTelerik.Reporting.Reportあり、レポートのビジネスタイトルやレポートのプログラム名など、レポートのメタデータとして機能するプロパティが制限されています。レポートカテゴリ、レポートのSQLクエリファイルの名前、レポートの可能な代替表示ページ、レポートで無効にする一般的なフィルタパラメータのサブセットなどの属性のフィールドはありません。
ここで最初の候補ソリューションは魅力的ではありません。ファイル、web.config、またはデータベーステーブルのいずれかに「レポート設定」ストアを作成および維持します。このストアは実際のレポートから切り離されており、実際のレポートまたはストアで作業するには、頻繁で煩わしいコンテキストの交換が必要です。
私のより好ましいアイデアは、動的データメタデータスキームに似たものを使用することです。このスキームでは、エンティティクラスの属性が、エンティティのメタデータを保持する別のクラスに割り当てられます。また、拡張Telerik.Reporting.Reportして、レポートに添付する属性の辞書を追加し、そこからすべてのレポートを派生させることもできます。
私の現在の考えに対する批判、または他の選択肢に関する提案はありがたいです。