現在、すべてのレポートはストアドプロシージャで記述されています。これをSQLプラットフォームから遠ざけ、ほとんどのロジックを.NETコードに集中させたいと考えています。理由には、ORMエンティティの使用、デバッグの容易さ、並列処理、ビジネスロジックとの統合の強化などがあります。
私たちが直面している問題は、レポートロジックを.NETコードに移動することにより、本番環境でスクリプトを実行するほど簡単にサポート修正プログラムを展開できないことです。バイナリをリリースするということは、ビジネス全体がアプリケーションの使用を停止する必要があることを意味します。これは、営業時間中はほとんど不可能です。
1つの解決策は、各レポートを新しいプロジェクトに分割し、そのDLLだけをリリースすることです。これに伴う問題は、500を超えるレポートがあることです。それを維持することは悪夢になります。
誰かが似たようなことを経験したことがありますか、またはこの問題に対する他の解決策がありますか？
ありがとう、デイブ
Reporting Services を使用しないのはなぜですか? このために作られています！ビジネスの関係者 (非開発者) をトレーニングして、レポートを作成して公開することもできます。ユーザーが活用できる機能がたくさんあります。認証・認可、購読、エクスポート（PDF、Excel、Word）など
私があなただったら、Reporting Services の再構築に投資しません。私はいつも、アプリケーションの一部として、または「コード」でレポートを書くことから離れています。
あなたが本当にこれをやりたいのなら（私は絶対にすべきではないと思います）、メインアプリケーションから呼び出すことができるレポートを（別のエンドポイントで）生成する別のサービスを開発します。更新が必要なときに「レポート要求」を格納するキューを中央に配置し、再起動後に要求を処理できるようにします。
他のオプションは、アセンブリを動的にロードすることです。filewatcher にフォルダーを監視させ、新しい dll があるとすぐにそれを動的にロードします。荷降ろしはより困難です。古いレポートをメモリから削除するのに忙しくない場合や、アンロードできる別のアプリドメインを作成する必要がある場合は、サービスを再起動できます。
多くのオプションがありますが、繰り返しになりますが、カスタム レポート フレームワークを構築してテストすることは時間を無駄にします。C# が本当に好きな場合でも、プレーン SQL を使用します。この方法では、開発者の代わりにレポートを作成するだけの BI 担当者を雇うことができます。
@bartの答えに大いに同意します。私の最初の反応は、これは不要な再発明のように思えるということです。
ただし、.net コードと宣言型コードの利便性が必要な場合は、Iron python のような DLR ベースの言語を使用してみませんか?
Iron python をデータベースに保存し、オンデマンドでロードしました。ひとたび jit されると、dlr ベースでないコードと何ら変わりはなく、修正を展開することは夢のようでした。