1

.NET3.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で単一の行を取得するには、これらのソリューションでリスト全体をクライアントに表示し、必要な行を見つける必要がありますか？

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

4

6 に答える 6

6

私は悪魔の擁護者を演じて、少なくともストアド プロシージャに固執することを検討することをお勧めします。これらは、書き直してデバッグする必要のないコードのチャンクを表します。 Very Own [tm] Joel Spolsky のこの記事では、完全な書き直しを避けるための首尾一貫した議論を示しています。

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

Fowler のエンタープライズ アプリケーション アーキテクチャのパターンは、メンテナンスの問題を引き起こすことなく、ストアド プロシージャと適切に連携するデータ アクセス層を設計するための優れた指針を提供するはずです。

これは、Oracle/Java アプリで非常に一般的に行われます。多くの従来の Oracle アプリには、PL/SQL のストアド プロシージャ コードの大部分が含まれています。これは、Oracle Forms のクライアント サーバー時代には標準的なアーキテクチャでした。Java で sprocs のラッパーを作成し、そのラッパーの上にユーザー インターフェイスを構築するのが一般的です。

他の投稿者の 1 人は、Subsonic が sproc のラッパーを生成できると述べました。

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

于 2008-11-12T20:06:42.343 に答える
2

Linq-to-SQL、Entity Framework、NHibernate について話すことはできませんが、SubSonic は大好きです。それに関する私の経験は、圧倒的にポジティブでした。

一般に、これらのツールが機能する方法は、マネージド コードでパラメーター化されたクエリを作成し、そのアクセスをクラスにカプセル化してから、それらのクラスをアプリに公開することです。完全に生成された DAL のロック。

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

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

(ちなみに、SubSonic のおかげで、「すべての procs」から解放されました。現在、私は通常、以前のように CRUD procs を実行することにほとんど時間を費やしておらず、複雑なレポートのためにのみ CRUD procs を使用しています。しかし、あなたのマイレージは、実際には異なります。)

于 2008-11-12T19:24:37.797 に答える
1

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

于 2008-11-12T20:25:47.907 に答える
1

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

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

アプリの残りの部分をまっすぐにしたら、いつでもクエリをリファクタリングできます。また、ORM の世界は急速に変化しているため、そこにたどり着いたときには選択肢が確実に異なっているでしょう。

于 2008-11-12T20:55:50.733 に答える
1

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

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

于 2008-11-12T19:35:17.633 に答える
0

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

于 2008-11-12T19:31:00.577 に答える