LinqからSQLに生成される独立したビジネスクラスまたはエンティティクラス

Question

バックアップされたデータベースがSQL Serverであり、.NETフレームワーク3.5を使用しているプロジェクトを開始する必要があります。

データアクセスレイヤーにLINQ to SQLを使用することに決めました。ビジネスレイヤとプレゼンテーションレイヤに使用する個別のクラスを作成するか、LINQ to SQLによる自動生成エンティティクラスを使用しますか。

Answer 1

私は、Entity Frameworkのコードファーストを使用しますが、以下の概念は（非自明なプロジェクト用）と同じである：

私はいつも私の実際のビジネス層のうち、私のDALのクラスを維持します。そうすれば、DB変更がアプリケーションに及ぼす影響が少なくなります。 DALプロジェクト以外の場所でDALクラスを使用することはありません。

私の現在のプロジェクトは、DDDを利用し、任意のレイアウトは、次の（大規模簡略化）に似ています。

MainApp      
MainApp.Domain    
    |...IRepositories 
    |...AggregrateX 
    |...AggregrateY 
MainApp.Dal    
    |...Models 
    |...Repositories 

• MainAppに - ドメインを参照してください、しかし
• MainApp.DalをDALすることはできません - ドメインを参照してくださいではなく、 MainAppに

DALリポジトリ方法はAutoMapperを利用することができます：

public Customer Get(int customerId) 
{ 
    using (var context = GetContext()) 
    { 
     var entity = context.Customers.Where(x=> 
      x.CustomerId == customerId).Single(); 

     return Mapper.Map<DtoCustomer, Customer>(entity); 
    } 
} 

public void Save(Customer customer) 
{ 
    using (var context = GetContext()) 
    { 
     var entity = context.Customers.Where(x=> 
      x.CustomerId == customer.CustomerId).Single(); 

     Mapper.Map(customer, entity); 
     context.SaveChanges(); 
    } 
} 

これにより、私のビジネスクラスと私の実際のDAL/DTOオブジェクトを完全に分離することができます。理論的には、バックエンド全体をビジネスロジックに影響を与えずに変更することができます。私が示していないことは、ファサードを介して入力/表示モデルとの間でマッピングするときに、ドメイン/ビジネスオブジェクトがプレゼンテーションレイヤーで決して見られないようにすることです。

基本的には、何を使用しているのか、それがどのように保持されているのか、それがどのように永続化されているのかを気にしないすべてのビジネスロジックを含むドメインレイヤーと、人口と永続性を唯一の目的とするDALレイヤー私のドメイン/ビジネスクラスの

しかし、これは大規模プロジェクトでは本当に理にかなっています。私は単純な/小さなプロジェクトでDALクラスを使用します。

Answer 2

わたしたちが何をしたか教えてください。我々は、次世代製造アプリケーションにL2Sを使用しています。私たちは2.5億ドルの世界的な太陽光発電会社です。私たちは2組の実体を持っています。我々は我々の「バックエンド」で厳密に使用するL2Sエンティティを持っています。次に、クライアントアプリケーションで使用され、バックエンドに渡された、より軽量なアプリケーション/ドメインエンティティを使用します。

多くの場合、私たちはドメインエンティティをモデル化したビューを使用し、ビューをL2Sモデルに読み込み専用テーブルとして持ち込みます。これにより、「ドメイン」エンティティを持つことができ、L2Sを使用してそれぞれのビューにクエリを実行してこれらのエンティティを水和することができます。

非常にうまく動作します。