MVCリポジトリパターン：モデルクラスの作成

Question

Coneryのストアフロントを確認しますが、なぜ彼がLinqsの自動生成クラス（つまりOrderクラス）を使用したのか理解できず、部分クラスではない別のOrderクラスが定義されています。リポジトリパターンを使用する場合、クラスを手動で作成し、Datacontextを完全に無視する必要がありますか？

Answer 1

中間クラスを使用してフロントエンドをlinqクラスから分離しないと、データコンテキストでガベージコレクションを制御できません。通常、インスタンスのデータコンテキストタイプでは、使用が終了したらすぐに削除します。 linq to sqlコンテキストを使用してこれを行う方法を次に示します。

using (MyDataContext data = new MyDataContext())
{
    SomeThing thing = data.Things(t => t.ID == 1);
    return thing;
}
... the MyDataContext instance is gone

＆quot;使用＆quot;ブロックすると、最後の＆quot;}＆quot;でMYDataContextのインスタンスが破棄されます。ただし、これを行うとエラーが発生し、＆quot; thing＆quot;を使用しようとします。データコンテキストインスタンスがなくなったためです。データコンテキストを破棄しない場合、最終的にガベージコレクションが行われるまでデータコンテキストはぶら下がります。

linq to sqlコードを呼び出し元アプリから切り離すために中間クラスを導入する場合、データコンテキストインスタンスを削除して同じデータを（異なるオブジェクトでのみ）返すことができます：

using (MyDataContext data = new MyDataContext())
{
    SomeThing thing = data.Things(t => t.ID == 1);
    SometThingElse otherThing = ConvertSomethingToSomethingElse(thing);
    return otherThing;
}
... the MyDataContext instance is gone

役立つこと。

Answer 2

ロブはショーの1つでこの質問に答えています。

彼はPOCOクラスを使用して、すべてのデータアクセスクラスを認識します。たとえば、彼がLINQ-to-SQLをNHibernateに変更する場合、「マッピング」を変更する必要があります。フィルターを使用すると、ビジネスロジックを変更する必要がなくなります。

Answer 3

彼は最近のビデオの1つで、LINQ to SQLがマッピングを行う方法が好きではないと述べました。完全にやり過ぎだと思いますが、私は同意します。

リポジトリパターン自体に固執している限り、主要なデザインパターンを壊すことはないと思います。 2セットのクラスを持っているのは選択の問題だと思います。