linq - LINQ To SQL entity objects as domain objects

Question

Clearly separation of concerns is a desirable trait in our code and the first obvious step most people take is to separate data access from presentation. In my situation, LINQ To SQL is being used within data access objects for the data access.

My question is, where should the use of the entity object stop? To clarify, I could pass the entity objects up to the domain layer but I feel as though an entity object is more than just a data object - it's like passing a bit of the DAL up to the next layer too.

Let's say I have a UserDAL class, should it expose an entity User object to the domain when a method GetByID() is called, or should it spit out a plain data object purely for storing the data and nothing more? (seems like wasteful duplication in this case)

What have you guys done in this same situation? Is there an alternative method to this?

Hope that wasn't too vague.

Thanks a lot,

Martin.

score 5 · Accepted Answer

DAL (LINQ2SQL を使用) から POCO の IQueryable を返すため、Linq エンティティオブジェクトが DAL を離れることはありません。これらの POCO は、サービスおよび UI レイヤーに返され、処理のためにデータを DAL に戻すためにも使用されます。Linq はこれを非常にうまく処理します。

 IQueryable<MyObjects.Product> products = from p in linqDataContext.Products 
                                          select new MyObjects.Product //POCO
                                          {
                                              ProductID = p.ProductID
                                          };
 return products;

score 3 · Accepted Answer

ほとんどのプロジェクトでは、ビジネスオブジェクトとしてLINQtoSQLエンティティを使用します。

LINQ to SQLデザイナを使用すると、生成するクラスとプロパティのアクセシビリティを制御できるため、消費者がビジネスルールに違反する可能性のあるものへのアクセスを制限し、（ビジネスルールを尊重する）適切なパブリック代替手段を提供できます。部分クラス。

この方法でビジネスロジックを実装する方法についての記事もMSDNにあります。

これにより、面倒な定型コードをたくさん書く必要がなくなり、Webサービスからエンティティを返したい場合は、エンティティをシリアル化することもできます。

ビジネスロジック用に別のレイヤーを作成するかどうかは、実際にはプロジェクトのサイズによって異なります（通常、プロジェクトが大きいほど、ビジネスロジックレイヤーとデータアクセスレイヤーの間でばらつきが大きくなります）。

LINQ to Entitiesは、2つの別個のモデル（ビジネスロジックの概念スキーマとデータアクセスのストレージスキーマ）を維持することにより、この難問に対するワンストップソリューションを提供しようとしていると思います。

score 1 · Accepted Answer

個人的には、自分のエンティティがレイヤー全体に広がるのは好きではありません。私の DAL は POCO を返します (もちろん、それは余分な作業を意味することがよくありますが、これははるかにクリーンであることがわかりました。おそらく、次の .NET バージョンではより簡単になるでしょう ;-))。

質問はそれほど単純ではなく、主題についてはさまざまな考え方があります (私はあなたと同じ質問をし続けます)。

たぶん、 MVC Storefront サンプルアプリを見てください。コンセプトの本質 (特にデータレイヤーで発生するマッピング) が気に入っています。

お役に立てれば。

score 1 · Accepted Answer

ここに同様の投稿がありますが、あなたの質問は、どのように行うべきかではなく、何をすべきかについてのものであることがわかります。

小さなアプリケーションでは、2 番目の POCO 実装は無駄であることがわかりました。より大きなアプリケーション (特に Web サービスを実装するアプリケーション) では、POCO オブジェクト (通常はデータ転送オブジェクト) が役立ちます。

アプリが後者のケースに該当する場合は、ADO.Net Data Servicesを確認することをお勧めします。

それが役立つことを願っています!

score 0 · Accepted Answer

私も実際にこれに苦労しました。プレーンなバニラ LINQ to SQL を使用して、DBML ツールをすぐに放棄しました。これは、エンティティを DAL にしっかりとバインドするためです。私はより高いレベルの持続性の無知を目指していましたが、マイクロソフトはそれを簡単にはしませんでした。

私が最終的にやったのは、DAL に私の POCO を継承させることで、持続性無視レイヤーを手書きすることでした。継承されたオブジェクトは、継承元の POCO の同じプロパティを公開していたので、永続性無視レイヤー内で、属性を使用してオブジェクトにマップできました。呼び出されたオブジェクトは、継承されたオブジェクトをその基本型にキャストするか、DAL にキャストしてもらうことができます。必要なキャストの量が減るので、私は後者のケースを好みました。確かに、これは主に読み取り専用の実装だったので、より複雑な更新シナリオでは再検討する必要がありました。

オブジェクトの継承とマッピングに加えて、各データソースのコンテキストとプロバイダーを手動で (コーディング後に) 維持する必要があるため、このための手動コーディングの量はかなり大きくなります。このプロジェクトが廃止された場合、私は間違いなくより堅牢なソリューションに移行します.

EF チームのデザインブログによると、エンティティフレームワークに期待して、持続性の無視はよく要求される機能です。それまでの間、EF ルートに進むことにした場合は、MSDN のEFPocoAdapterプロジェクトなど、事前に作成された永続化無視ツールをいつでも参照できます。

score 0 · Accepted Answer

デフォルトの MSLinqToSQLGenerator の代わりに、インターネットで見つけたものに基づいて構築されたカスタム LinqToSQL ジェネレーターを使用します。上位レイヤーをそのような Linq オブジェクトから独立させるために、それぞれを表すインターフェイスを作成し、これらのレイヤーでそのようなインターフェイスを使用します。例：


public interface IConcept {
    long Code { get; set; }
    string Name { get; set; }
    bool IsDefault { get; set; }
}


public partial class Concept : IConcept { }


[Table(Name="dbo.Concepts")]
public partial class Concept
{
    private long _Code;
    private string _Name;
    private bool _IsDefault;
    partial void OnCreated();
    public Concept() { OnCreated(); }
    [Column(Storage="_Code", DbType="BigInt NOT NULL IDENTITY", IsPrimaryKey=true)]
    public long Code
    {
             //***
    }
    [Column(Storage="_Name", DbType="VarChar(50) NOT NULL")]
    public string Name
    {
             //***
    }
    [Column(Storage="_IsDefault", DbType="Bit NOT NULL")]
    public bool IsDefault
    {
             //***
    }
}

もちろん、これ以外にもたくさんありますが、それがアイデアです。

score 0 · Accepted Answer

Linq to SQL は将来を見据えたテクノロジではないことに注意してください。リリースされましたが、遊ぶのは楽しいですが、マイクロソフトはそれをどこにも持っていません. 私はそれが永遠にサポートされることはないだろうと感じています。Microsoft の Entity Framework (EF) を見てみましょう。これには、Linq to SQL の優れた点がいくつか組み込まれています。

linq - LINQ To SQL entity objects as domain objects

7 に答える 7

Related

Reference