私は、すべてのデータアクセスにストアドプロシージャのみを使用している会社で働いています。そのため、新しいプロシージャを実行する必要があるコミットごとにローカルデータベースの同期を維持するのは非常に面倒です。私は過去にいくつかの基本的なORMを使用しましたが、この経験ははるかに優れており、よりクリーンです。今後の開発のために何らかのORMを使用することを検討していることを開発マネージャーとチームの残りに提案したいと思います（チームの残りはストアドプロシージャに精通しており、他のことは一度も使用していません）。現在のアーキテクチャは、.NET 1.1のように記述された.NET 3.5です。ActiveRecordの奇妙な実装を使用し、コードビハインドファイルでループされる型指定のないDataSetを返す「ゴッドクラス」を使用します。クラスは次のように機能します。
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...設計パターンの適用はほとんどありません。テストはまったくありません（単体テストの作成方法を知っている人は他にいません。テストは、Webサイトを手動でロードし、動き回ることによって行われます）。データベースを見ると、199個のテーブル、13個のビュー、926個のストアドプロシージャ、93個の関数があります。約30個程度のテーブルがバッチジョブまたは外部のものに使用され、残りはコアアプリケーションで使用されます。
このシナリオで別のアプローチを追求する価値さえありますか？既存のクラスを変更してORMを使用することはできないため、既存のコードをリファクタリングすることは許可されていないため、先に進むことだけを話しますが、代わりにブランドの新しいモジュールを追加する頻度はわかりません現在のモジュールに追加/修正するので、ORMが適切なアプローチであるかどうかはわかりません（ストアドプロシージャとDataSetにあまりにも多く投資しています）。それが正しい選択である場合、それを使用するケースをどのように提示すればよいですか？私の頭の一番上で考えられる唯一の利点は、よりきれいなコードを持っていることです（そうではないかもしれませんが、現在のアーキテクチャは ORMを念頭に置いて構築されているため、基本的に将来のモジュールにORMを審査しますが、古いモジュールは引き続きDataSetsを使用します）実行されたプロシージャスクリプトと実行する必要のあるスクリプトを覚える手間が少なくなります。など。しかし、それだけであり、どのように説得力があるかはわかりません。保守性も別の懸念事項ですが、私以外の誰も心配していないようです。