8

Rob のやり方に従って、Linq to SQL ウィザードによって生成されたクラスと、POCO であるこれらのクラスのコピーを用意しました。私のリポジトリでは、Linq to SQL モデルではなく、これらの POCO を返します。

return from c in DataContext.Customer
       c.ID == ID
       select new MyPocoModels.Customer { ID = c.ID, Name = c.Name }

これの利点は、POCO モデルを簡単にインスタンス化できるため、コードがよりテストしやすくなることだと理解しています。

私は現在、Linq から SQL、さらには Entity Framework に移行しており、EF ブックの半分ほど進んでいます。EF エンティティではなく、リポジトリから POCO を返すことで失うメリットがたくさんあるようです。

私はまだ単体テストを実際に受け入れていないので、これらの余分な POCO を作成し、それらにデータを入力するためのコードを書くのに多くの時間を無駄にしているように感じます。オブジェクトを追跡できないため、EF の多くの利点を失うことになります。

このすべての ORM/Repository について、比較的初心者にアドバイスがある人はいますか?

アンソニー

4

3 に答える 3

6

自動生成されたオブジェクト（たとえば、LINQ to SQL）が気に入らないもう1つの理由は、組み込みの「魔法」のためです。

通常、魔法は目に見えず、気付くことはありませんが、これらのオブジェクトの1つをシリアル化してから逆シリアル化しようとすると（たとえば、Webサービスを使用する場合）、データソースへの内部接続が切断され、特別なハッキングが必要になります。 「魔法を元に戻す」ために採用されます。

POCOを使用すると、このようなことを心配する必要がなく、データレイヤーとサービスレイヤーをより適切に分離できます。もちろん、欠点は、退屈なPOCO->魔法のオブジェクトと魔法のオブジェクト->POCO変換コードをたくさん書かなければならないことです。しかし、最終的には、特に大規模または複雑なプロジェクトの場合、通常はそれだけの価値があると思います。

于 2009-05-13T19:44:37.980 に答える
4

主な理由は、多くの人が、たとえば DDD のように、特定の考え方でモデルを開発することを好むためです。ステータスなどに (列挙型ではなく) 特定のパターン (Spec や State など) を使用したい場合や、インスタンス化に Factory を使用したい場合があります。

物事がより複雑になったときにテーブルをオブジェクトとして使用しようとすると、オブジェクト指向が壊れます。単純なサイトは問題なく動作しますが、大きなものになると見苦しくなります。

だから - いつものように - あなたのプロジェクトがどうなるかはあなた次第です。

于 2009-05-13T18:50:02.017 に答える
2

私の経験では、複雑なクエリを書き始めると、 .Include メソッドは役に立たず、次のいずれかになります。

a) 必要なデータを取得するために大量のクエリを作成する、または b) 匿名型を悪用して 1 つのクエリでデータをロードし、そのデータをエンティティに渡すためだけに大量のコードを作成する。

POCOは行くべき道です、IMHO。

于 2009-05-13T19:35:17.123 に答える