エンティティフレームワークとWPFアプリケーション設計ガイダンス

Question

エンティティフレームワークレイヤガイダンス

私はWPFビジネスアプリケーションの設計段階にあります。このアプリケーションの第1段階はWPF/Desktopアプリケーションです。後の反復は、ブラウザベースのミニバージョンを含むことができる。

すべてのアプリケーション（デスクトップまたはブラウザ）が使用するドメインモデル& dbcontextを含むdllまたは2を作成することを想定しています。

私の意向は、EFで乗るか死ぬことです。私は柔軟性のためにDI /リポジトリパターンなどを使用することについて心配していません。このプロジェクトを使用する利点は、このプロジェクトのための私の意見の複雑さを上回るものではありません。私の計画は、モデルと派生したdbcontextを使用することです。

私は、特定のタイプのメソッドコードをどこに配置するかについての入力を探しています。

の例では、うまくいけば、私の質問は、より明確になります：従業員

エンティティ：これら二つの内部PermissionToken

だが、私は次の2つのエンティティ..

エンティティがあるとしましょうエンティティManyToMany関係を持っているため、関係の別のエンティティが作成されます。 EmployeesPermissionTokens

明確にするために、PermissionTokenエンティティの主キーは、アクセス権を表す列挙型です。..アプリケーションで

は、現在のユーザーが、従業員の管理や従業員に権限を付与したいと言うことができます。アプリで

、私は確かとしてこれをコーディングすることができます：

var e = dbcontext.Employees.Find(1); 
var pt = new PermissionToken 
{ 
    PermissionID=PermissionTypeEnum.DELETEUSER"; 
    ... 
} 

e.PermissionTokens.Add(pt) 

しかし、1行のコードは、これらのアクションを実行することができるようにする方法でそのコードをラップする方が便利だろうと私には思えますどんなアプリケーションからでもそうすることを選択します。そのような方法はどこにあるのでしょうか？

私はEFエンティティへの静的メソッドを追加する方法について考えた：

従業員クラスで：

public static void GrantPermission(PermissionToken token) 
{ 
    e.PermissionTokens.Add(token); 
} 

はアプリがする能力になり、本当に便利になるのか、さらに行きますもちろん

Permissions.GrantToEmployee(EmployeeID employeeId, PermissionTypeEnum 
permissionId); 

方法は、EmployeeオブジェクトとPermissionObjをつかむためにDbContextにアクセスできるようにしなければならないことを意味します。このような行を書きますその仕事をするためにIDによって行動する。私は、私の考えではModelクラスにすべきではないdbcontextコードでいっぱいになったエンティティを長期間感じているので、私のエンティティがDbContextを知っていることを知っていることを避けたいと思っています。

だから、このような方法はどこに行きますか？

これらの種類のことを行うために、このメソッドはDbContextにアクセスする必要があるため、これらの種類のコードを派生したDbContextに配置するように指示します。

これは意味がありますか、何か不足していますか？私はコードの冗談を書いて3ヶ月後に私が間違った道を歩み始めたことを知りたくありません。これらのタイプのメソッドはどこに存在すべきですか？おそらく純粋な答えがあるのは分かっていますが、私はきれいで現実味のあるソリューションを探しています。

Answer 1

まず、リポジトリの背後で抽象的なEFを抽象化しないようにすることを決定します。

EFコンテキストでは、データアクセスのニーズを処理するUnit Of Workパターンをサポートするクラスがあります。リポジトリにまとめないでください。

ただし、コントローラまたはビューモデルから直接コンテキストを呼び出す必要はありません。

実際にはDbContextを拡張することはできますが、サービスを使用してコントローラ/ビューモデルとdbcontextを仲介することをお勧めします。

あなたのコントローラーであなたのユーザーの要求を処理している場合（ユーザーがボタンをクリックしたなど）、コントローラーは、「Use Case」がボタンの背後にあるものをアーカイブするサービスを呼び出す必要があります。

あなたのケースでは、これはPermissionServiceであり、PermissionServiceは許可に関するすべての操作のためのストレージです。

public class PermissionService 
{ 

    PermissionService(DbContext context) 
    { 
    } 

    public bool AddPermission(Employee e, PermissionType type) { } 
    public bool RemovePermission(Employee e, PermissionType type) {} 
} 

あなたのサービスにはDbContextへのアクセスが必要です。

ここでDIを使用し、DbContextをDIコンテナに登録することは理にかなっています。

したがって、コンテキストはすべてのサービスに注入されます。これはかなりストレートです、私はここで余分な複雑さは見ません。

ただし、これをしたくない場合は、サービス内のDbコンテキストを新しくすることができます。もちろん、これはテストのために模擬するのが難しい/不可能です。