Entity Framework asp.netアプリケーションのUOWとリポジトリ

Question

私は、リポジトリと作業単位パターンを使用して読み始めました。私は現在、Entity Framework asp.net Webフォームアプリケーションでそれを使用しようとしています。しかし、簡単な方法で説明できるかどうかわからない質問があります。

私は業務単位をカプセル化するために作業単位が使用されていると理解しています。実施例から私はUOWが今は上記方法と同様であるbusinessMethod2()があると、以下のよう

businessMethod1() 
{ 
    uow u = new uow(); //instantiate unit of work 
    repository1 rep1 = new repository1(uow); //instantiate repository1 
    repository2 rep2 = new repository2(uow); //instantiate repository1 
    rep1.dowork(); 
    rep2.dowork(); 
    u.save(); //save the changes made to the database. (effectively saving changes made  
       //in both repository classes 
} 

に使用さ見てきました。 businessMethod2()内のbusinessMethod1()をベストプラクティスとしたいとします。私は議論としてそれを渡す必要がありますので、作業単位を共有したいですか？つまり上記の方法を

businessMethod1(uow u) 
{ 
    bool isNew = false; 
    if (u == null) 
    { 
     u = new uow(); 
     isNew = true; 
    } 

    repository1 rep1 = new repository1(uow); //instantiate repository1 
    repository2 rep2 = new repository2(uow); //instantiate repository1 
    rep1.dowork(); 
    rep2.dowork(); 

    if (isNew) 
     u.save(); //save the changes made to the database.   
} 

に変更するこれは適切な方法ですか？

私はシングルトンを使うのが良い方法だと考えていました。すべてのページリクエストで、新しいインスタンスのインスタンスが作成され、すべてのビジネスメソッドで共有されます。新しいリクエストでは、別のインスタンスが作成されます。シングルトンを使用すると、私はそれを自分のビジネス方法に渡す必要はなく、同時にすべてのビジネス方法を共有することができます。

これには何らかの欠点がありますか？これを実装するより良い方法はありますか？

Answer 1

この問題を解決する1つの方法は、依存性注入を使用することです。通常、コンストラクタインジェクションは、依存関係を解決するためにエントリの1つのポイントに沿って使用されます。

public class MyBusinessService 
{ 

    public MyBusinessService(Repository1 repository1, Repository2, uow u) 
    { 
     // assign the params to fields 
    } 

    public void businessMethod1() 
    { 
    } 

    public void businessMethod1() 
    { 
    } 
} 

多くの人気のあるDIフレームワークがあります。あなたが思うものをあなたのために選ぶ。

Answer 2

これはUoWの使用方法です。 BusinessMethod1にUoWの使用法を置くと、それはトップレベルのビジネス抽象化（ビジネスファサード）であると言われています。それはおそらく他のビジネス操作によって使用されるべきではないでしょう。なぜなら、それは「トップレベル」を壊すからです。したがって、BusinessMethod1のロジックを別のBusinessMethod2に使用する必要がある場合は、ロジックを追加してUoWの存在を判断する正しい方法ではなく、懸念の分離を破ります。 BusinessMethodは、UoW作成ではなくアプリケーションロジックを処理する必要があります。最も簡単な解決策は、あなたのBusinessMethod1をリファクタリングしてUOWに依存せずに新しい方法などの共有機能を公開することです：

public void BusinessMethod1() 
{ 
    uow u = new uow(); 
    DoSomeWork(); 
    u.save(); 
} 

private void DoSomeWork() 
{ 
    repository1 rep1 = new repository1(uow); //instantiate repository1 
    repository2 rep2 = new repository2(uow); //instantiate repository1 
    rep1.dowork(); 
    rep2.dowork(); 
} 

確かにあなたの方法は、まだ懸念の分離に従わないので、これは非常に単純な例です - 彼らはありません両方ロジックとオブジェクトの作成。あなたはUoWとリポジトリ作成をどこかで処理し、作成したオブジェクトを内部に渡す必要があります。 @Erangaで述べたアプローチを使用できますが、method2がmethod1から何かを呼び出そうとしている場合は、このリファクタリングは引き続き適用されます。

このリファクタリング手法は、低レベルのビジネスサービスとビジネスファサードとしてもモデル化できますが、大きなプロジェクトでのみ必要となります。小規模なプロジェクトでは、コントローラがアプリケーションロジックを駆動し、単一の作業単位で呼び出すビジネスメソッドを知っているため、UoWとのインタラクションを「コントローラ」（おそらくWebフォームの背後にあるコード）に移動することもできます。