3層アーキテクチャのLINQ to SQL

Question

私は現在、3層アーキテクチャー（DAL、BLL、プレゼンテーション層）を使用しています。

LINQ to SQLを使用して3層アーキテクチャを実装する方法が不思議です。私はLINQがDALかBLLのどちらにあるべきかはわかりません。 LiNQはDALとBLLの融合のようです。

誰もが3層アーキテクチャでLINQを実装していますか？

Answer 1

私はLinq-to-SQL/XMLを使用しています。私はアプリケーションを3層と考えています。 Linq以前のアプリケーションの違いは、データアクセスレイヤーが非常に小さく軽量で、実際には非常に良いことです。

私のような方法でなければならなかった私の古いDALで

：新しいDALのメソッドを呼び出すと少しとするには

public virtual int Count(Expression<Func<T, bool>> where) { 
    // Plug in Linq-to-SQL DataContext here.   
} 

public virtual T Get(Expression<Func<T, bool>> where) { 
    // Plug in Linq-to-SQL DataContext here. 
} 

public virtual List<T> Get(Expression<Func<T, bool>> where, string orderByField, int offset, int count) { 
    // Plug in Linq-to-SQL DataContext here. 
} 

：私は今、次のメソッドの並べ替えを持って

public virtual int CountCustomersInCountry(string country) { 
    // Plug in raw SQL. 
} 

public virtual List<Customer> GetCustomersInCountry(string country) { 
    // Plug in raw SQL. 
} 

public virtual int CountCustomersForDepartment(string department) { 
    // Plug in raw SQL. 
} 

public virtual List<Customer> GetCustomersForDepartment(string department) { 
    // Plug in raw SQL. 
} 

etc. etc. ad-infinitum 

をDynamicLinqの助けを借りて私は以下を使用します：

int countryCount = Count(c => c.Country == country); 
List<Customer> customers = Get(c => c.Country == country, "inserted", 0, 25); 
int departmentCount = Count(c => c.Department == department); 
List<Customer> customers = Get(c => c.Department == department, "inserted", 0, 25); 

あなたが追加、更新、削除する前にすべてich Linq2SQLとの単一回線の呼び出しになる！私のDALは10個のメソッドで構成されていましたが、以前はDALが探していたオブジェクトごとに20〜30個のメソッドを簡単に取得できました。私は非常に多くのコードを保存するので、あなたの頭の周りを取得しようとすることを強くお勧めします。

Answer 2

LINQをどのように見ているかによって決まると思います。通常の計画では、基本的なデータ構造に密接に従っているので、DALに実際に座っていると思います。その後、BLLのそれを抽象化することができます。

Answer 3

LiNQが作成するオブジェクトは通常、ビジネス層オブジェクトとして記述されますが、一般的に推奨されるよりもデータレイヤーとの結合が高いことが必要です。しかし、LiNQで直接表現されているものよりも高いレベルの構造を持っている場合、追加のコントローラは、LiNQがより多くのデータレイヤになるようにビジネスレイヤとして操作できます。

実際にデータベースに表現されているオブジェクトの範囲と、達成したいカップリングのレベルに依存します。 LiNQはクエリ可能なものを重視しているため、アプリケーションに過度に浸透する可能性があります。

Answer 4

LINQは3層アーキテクチャには適していません。 2層アーキテクチャに最適です。

私は個人的に3段階で私の学位プロジェクトを行い、LINQを使うことに決めましたが、後で多くの問題のためにこのアイディアを落としました。大きな問題は「楽観的同時実行制御」

LINQのエンティティオブジェクトはDataContextの接続環境で動作するためです。したがって、更新および削除ロジック中に。エラーが発生します。

Answer 5

LINQ-to-SQLは、ほとんどがDALに関するものです。これはデータアクセス技術です。しかし、シンプルなアプリケーションでは、LINQで作成したオブジェクトをビジネスレイヤーに渡したり、UIにバインドすることを止めるものはありません。何故なの？

この場合、LINQ-to-SQLにかなり関わっていることに気づく必要があります。それがあなたのシナリオで大丈夫なら、それを使ってください！プロジェクトのニーズに応じて、自分で作る必要のある意思決定です。

システムが複雑になった場合、特にデータベーステーブルから作成されたLINQオブジェクトがビジネスオブジェクトと1：1で一致しない場合は、ビジネスレイヤを使用してLINQから実際のビジネスオブジェクトを "オブジェクト。 AutoMapperのようなツールの助けを借りて、左 - 右 - アサインの "猿"コードを書くこともできます:-)

一方、このような状況では、また、LINQ-to-SQLではなくADO.NET Entity Frameworkを見たいと思っています。 EFは、小さなアプリのためにおそらく過度に機能するこれらのより高度な機能を多く提供しますが、エンタープライズアプリにとっては絶対に重要な機能です。複数のデータベースベンダーをサポートすること、ビジネスオブジェクトをデータベースの別の物理的な表現にマッピングすることなどがあります。

マルク・

Answer 6

私は、DALのプロジェクトにエンティティを追加し、私は必要なアクセスのためのリポジトリを作成します。 LinqがBLLのSQLオブジェクトを実際に必要としないようにするには、二重マッピング技法を使用する必要があります。リポジトリパターンを使用すると、DALを簡単にモックできます。

Answer 7

私はlinqと3層を使って簡単な電話帳を書いています。あなたはそれをダウンロードすることができます。

これは次のサイトから入手できます。http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=7597&lngWId=10