LINQ to SQL を使用する個人プロジェクト (C#/ASP.NET) に取り組んでいます。ソリューションには、(これまでのところ) Webform プロジェクト、Namespace プロジェクト (ビジネス ロジック)、および Tests プロジェクトが含まれます。これまでのところ、私は非常に初期の段階にいます (明らかに設計段階です)。
ここに 3 層アーキテクチャのパラダイムはありますか? この場合、DAL はまったく役に立たないようです。ビジネス ロジックから直接 LINQ クエリを実行する必要があるように感じます。
また、常駐の DataContext を 1 つだけ保持してそれを渡すと、開いている接続が 1 つだけ必要になることも思い浮かびます。これには、変更を細かくではなく一度にコミットするという追加の利点があります。それについて何か考えはありますか？
このスレッドを見つけましたが、不完全な絵を描いているようです。このテーマに関する詳細な記事はありますか?
ドメイン駆動設計について少し読むことができます。
ドメイン駆動設計 (DDD) の実践により、取り組みたい問題ドメインを表現するリッチな「ドメイン モデル」が得られます。このドメイン モデルは、ビジネス エンティティをモデル化するクラス (および構造体) で構成されます。ドメイン モデルもリポジトリで構成されます。
リポジトリは、ドメイン モデル (およびアプリケーション) で使用するある種の抽象化です。リポジトリは、データストアの抽象化です。リポジトリを介してエンティティを取得でき、リポジトリを使用してエンティティを永続化できます。
あなたの場合、リポジトリは Linq To SQL を内部的に使用してデータベースと通信できます。ただし、リポジトリは接続とトランザクション (開始/コミット/ロールバック) を管理 (開く/閉じる) する必要はありません。なんで ？-> リポジトリには、それが使用されるコンテキストに関する知識や概念がないためです。新しい接続を開き、トランザクションを開始/コミットするのは、アプリケーションまたはサービス レイヤー (ドメイン モデル、つまりリポジトリを使用するレイヤー) です。(または、あなたの場合は、新しい DataContext を開きます)。その後、DataContext をリポジトリに渡すことができます。
(Eric Evans は DDD に関する素晴らしい本を持っていますが、ときどきクラックするのは難しいことです)。
LINQ-to-SQL は DAL と考えることができるため、「ビジネス ロジックから直接」使用することは必ずしも悪いことではありません。
http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspxには、いくつかの一般的な L2S アプローチがリストされています。
私たちのプロジェクトでは、データ コンテキストを渡したくなかったので、上記のリンクの #3 のようなパターンを使用しました (Ambient DataContext、以下を参照)。いくつか問題がありましたが、かなりうまく機能しました。少なくとも私たちの Web プロジェクトでは。
Ambient DataContext (現在これを使用)
アンビエント データ コンテキストの背後にある考え方は、DataContext の最初の呼び出しがあるとすぐに、特定のスレッドまたは httpcontext (asp.net 内) のコンテキストが作成されるということです。その後、手動で破棄しない限り、そのスレッドまたはリクエストに対して同じコンテキストが使用されます。これは、リクエスト/スレッド データ ストアにコンテキストを格納することによって行われます。このパターンへのアプローチは静的 DataContext に似ていますが、スレッドと要求ごとに分離が提供されます。これは Asp.Net では非常にうまく機能しますが、ここでも静的コンテキストの問題に悩まされています。
このパターンの問題:
* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work * Portability across thread is very hard * Unit of work pattern is not transparent enough
用語には注意が必要です。LINQ と言うときは Linq-to-sql を意味し、3 層と言うときは通常、3 台の個別のマシンを使用した展開シナリオについて話していることを意味します。それがあなたの言いたいことかどうかはわかりません。
linq-to-sql のような ORM ツールを使用する場合は、3 層アーキテクチャを使用することをお勧めします。DAL は、クエリ ロジックを格納する単なる場所になります。クエリは永続性の問題であり、ビジネス ロジックの問題ではないため、ビジネス レイヤーからクエリを除外することをお勧めします。
データ コンテキストを管理するための通常の手法は、要求ごとに 1 つのデータ コンテキストを持つことです。
このテーマに関する他の記事に関しては、任意の ORM ツールのアーキテクチャ ガイダンスを見ることができます。linq-to-sql も例外ではありません。NHibernate のアーキテクチャに関する記事を探してください。
この場合、LINQ to SQL ライブラリは DAL であり、ビジネス層 (DAL.GetObjectById(id) など) から従来の API 呼び出しを行う代わりに、DAL へのより表現力豊かな要求の柔軟性があります。
MSSQL 以外のデータ バッキングに接続する独自の LINQ プロバイダーなど、他のニーズがある場合は、独自の DAL を実装します。
さらに、DataContext に関しては、"1 つの常駐 DataContext" でシングルトン パターンを使用することはお勧めしません。DataContext オブジェクトは、アプリケーションにとって何を意味するかにかかわらず、単一の論理トランザクションを表す必要があります。( http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspxからの言い換え)