大規模アプリケーションのデータアクセス戦略

Question

.NET 3.5sp1のVB6アプリケーションの書き換えに着手しようとしています。 VB6アプリは非常によく書かれており、データ層は完全にストアドプロシージャに基づいています。 Linq2SQL / Entity Framework / NHibernate / SubSonicのような自動化されたものを使用したいと思います。確かに、私はこれらのツールを使い捨てプロジェクト以外で使用したことはありません。

これらのすべての選択に伴う恐れがある潜在的な問題は速度です。たとえば、現在、単一の行（またはリスト全体）を取得するには、次のsprocを使用します。

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL
AS

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name

Linq2SQL / Entity Framework / NHibernate / SubSonicで単一の行を取得するには、これらのソリューションはリスト全体をクライアントに表示し、必要な行を見つける必要がありますか？

では、大規模なデータドメインを持つアプリケーションのデータアクセス戦略のコンセンサスは何ですか？

Answer 1

悪魔の擁護者を演じるつもりです。少なくともストアドプロシージャを使用することを検討することをお勧めします。これらは、書き直してデバッグする必要のないコードの塊を表しています。 Very Own [tm] Joel Spolskyのこの記事は、完全な書き換えを避けます。

「グリーンフィールド」プロジェクトを考えれば、必要なものを使用できます。O/ Rマッパーが適切な選択になる可能性があります。ただし、VB6アプリはよく書かれていると既に述べています。 sprocが適切に記述されている場合は、一部のアプリを無料で入手でき、既にデバッグされているだけでなく、データベーススキーマをリサイクルして、データ移行のほとんどの痛みを回避できます。

Fowlerのエンタープライズアプリケーションアーキテクチャのパターンは、メンテナンスの問題を引き起こすことなく、ストアドプロシージャとうまく機能するデータアクセス層を設計します。

これは、Oracle / Javaアプリで非常に一般的に行われます。多くのレガシーOracleアプリケーションには、PL / SQLに大量のストアドプロシージャコードがあります。これは、Oracle Formsのクライアント/サーバー時代の標準アーキテクチャでした。 Javaでsprocsのラッパーを記述し、ラッパーの上にユーザーインターフェイスを構築するのが一般的な方法です。

Subsonicがsprocsのラッパーを生成できると述べた他のポスターの1つ。

かつて、PL / SQL sprocsの概念実証Java / JDBCラッパーを生成するデータディクショナリハックを行う機会がありました-IIRCには1日ほどしかかかりませんでした。それほど難しくないことを考えると、これを行うために棚から降りることができるものにはあまり選択肢がないことを知って驚いています。ピンチでは、自分で書くのもそれほど難しくありません。

Answer 2

Linq-to-SQL、Entity Framework、NHibernateについて話すことはできませんが、SubSonicが大好きです。私の経験は圧倒的に前向きです。

これらのツールの一般的な動作方法は、マネージコードでパラメーター化されたクエリを構築し、そのアクセスをクラスにカプセル化し、それらのクラスをアプリに公開することです。完全に生成されたDALは揺れ動きます。

パラメータ化されたクエリを使用することにより、「リスト全体をクライアントに届けて必要な行を見つけなければならない」という懸念があります。処理されます。 where 句とその他のフィルタリングをサポートして、必要な行のみを取得します。 select * from foo と同等の操作を実行できますが、そのモードにとどまりません。

とは言っても、SubSonicは、そのままテーブル/ビューに直接アクセスするためにそのまま使用すると、行全体をダウンさせます。これは、一部のシナリオではマイナス面になる可能性があります。ただし、ストアドプロシージャを介したアクセスは問題ではありません。他の人と話すことはできませんが、SubSonicはすべてのプロシージャをカプセル化する SPs クラスを作成して、メソッドとして呼び出すことができます。適切な DataTable を返します。これは、必要に応じて手動で解析できます。プロシージャからDALクラスのリストを初期化する方法もあります。そのため、プロシージャがテーブル/ビューに直接一致するデータセットを返す場合、手動処理なしでよりクリーンな構文を使用できます。

（ちなみに、SubSonicは「すべての手続き」を癒してくれました。通常、私は通常、これまでのようにCRUD手続きにほとんど時間を費やさず、それらを使用して複雑なレポートを作成するだけです。ただし、走行距離は変わる可能性があり、実際は異なります。）

Answer 3

SubSonicを使用して既存のストアドプロシージャにアクセスするためのすべてのコードを生成することをお勧めします。これにより、新しいデータアクセスレイヤーによる回帰の可能性を減らすことができます。 SubSonicによって生成されるActiveRecordクラスを使用して、新しい機能にアクセスできます。これは、最も安全で最速のアプローチであると思われます。

ストアドプロシージャの操作にはあまり適していないため、NHibernateの推奨事項に同意しません。

Answer 4

エンティティフレームワークをormとして使用しようとしましたが、ドメイン駆動開発で使用しようとすると、複数の問題が発生しました。 Linq to Sqlにもいくつかの制限があり、Microsoftは次のリリースでサポートを停止する予定です。

Answer 5

クエリがストアドプロシージャ内にある場合、既に十分に最適化されている可能性があります。そして、おそらく、JOINS、サブクエリなどのためにSQL式をリベラルに使用しています。

ORMタイプの抽象化レイヤーを使用して、そのような効率と表現力を正確に複製することは、特にツールに完全に精通していない場合、挑戦になると思います。

アプリの残りの部分を直接取得した後は、いつでもクエリをリファクタリングできます。そして、ORMの世界は急速に変化しているため、そこに着くとオプションが確実に異なります。

Answer 6

SubSonicは、著者の1人であるRob Conneryによると、大規模なアプリケーションではなく、迅速なアプリケーション開発をサポートするために書かれています。 NHibernateを使用することをお勧めします。コミュニティから最も多くのサポートが得られるだけでなく、実際にテストされたフレームワークもあります。 NHibernateの設定については、www.dimecasts.netから適切な情報を入手できます。