DALリポジトリパターン結合の使用dapper

Question

リポジトリパターンと私が見つけたすべての例を実装するには、非常に単純です（結合を無視する）か、エンティティフレームワークを使用します。ユーザーが複数のアカウントを持つことができ、アカウントは複数のユーザーを持つことができます

tblUser {id, fname, lname, email, password, dateAdded} 
tblAccount {id, name, isActive, dateAdded} 
tblAccountUser {userId, accountId, isActive, dateAdded} 

を次のように

私のDBテーブルがあります。 tblUserAccountには、ユーザーがそのアカウントに対してアクティブであるかどうか、およびユーザーが追加されたかどうかを示すブール値があります。

my pocosはリレーションの追加プロパティを持つテーブルに直接マップします。この部分を行うより良い方法はありますか？私はリポジトリがGetUsersWithAccounts（userId）のような関係でリターンを返す良い方法を考えることができませんでした。

tblUser { 
    guid id, 
    string fname, 
    string lname, 
    string email, 
    string password, 
    date dateAdded, 
    IList<tblAccount> accounts 
} 

tblAccount { 
    guid id, 
    string name, 
    bool isActive, 
    date dateAdded, 
    IList<tblUser> users 
} 

//should i have a tblAccountUser poco with something like 
//{tblUser user, tblAccount account, bool isActive, date dateAdded} 

私は、次のリポジトリを持っている：

UserRepository { 
    Add()... 
    ... 
    tblUser GetById(guid userId) {} 
    IEnumberable<tblUser> GetAll() {} 

    //was unsure if Account repo should retrieve a user's accounts or if the user repo should. 
    //using uow.User.GetAccounts(user.id) seems natural but please feel free to let me know what you think 
    IEnumberable<tblAccount> GetAccounts(guid userId){} 

    //this is the one i was really unsure about 
    //this would return tblUser obj with its tblUser.Accounts filled. 
    IEnumberable<tblUser> GetAllWithAccounts() 
} 

AccountRepository{ 
    Add() 
    ... 
    AddUser(guid userId) //only adds relation to tblAccountUser Makes sense? 

} 

//Should i have a repository for the Account <-> User relations? 

質問はあらゆる場所にあり、合計する：

1. 私のレポからPOCOSを返すどのように私は関係を返す必要があります。上記の私のポコスに示されているか、より良い方法がありますか？
2. 私のリレーションテーブルには独自のポコが必要ですか？その場合は、isActiveやユーザー/アカウント固有の設定などの追加データがある場合のみです。
3. 私のリポジトリでは、関係についてはどのレポが特定の要求に対処するのか不明です。
4. アカウントとユーザーの関係について別のレポが必要ですか？

批判、リンク、おかげさまで大歓迎です。

編集：

その他の注意：記載しておく必要があります。ユーザー/アカウントを取得する理由は、ユーザーまたはアカウントの値を有効化/無効化および変更できるグリッド内にあるためです。

Answer 1

A 1 & 3 UserRepositoryメソッドがtblUserオブジェクトを返すときに、アカウントを設定する必要はありません。すべての非コレクションプロパティは、UserRepositoryによって処理される必要があります。 Getter of Accountプロパティでは、AccountRepositoryのメソッドを呼び出して、ゲッターが呼び出されたときに初めてユーザーのすべてのアカウントを取得するデータベース呼び出しを行います。

A 2関連テーブルには独自のポココが必要ありません。

4個別にアカウントを処理する別のリポジトリを作成します。

Answer 2

おそらく答えの一部はストレスを軽減することです。リポジトリパターンの重要な部分は、ADOクラスではなくpocosを返すデータベース呼び出しをラップするクラスがあり、ユニットテストを可能にすることです。化粧品の部分は、同じクラスのinsert/update/deleteメソッドを "select"メソッドでグループ化することで、データベースを扱っているのを忘れることになります。あなたが忘れたいのはなぜ別の質問です。

レポクラスを取得したら、そのインターフェイスを抽出します。概略的には、1つのリポジトリが1つのクエリに対応し、1つのフラットな結果セットに対応する。内には、結合の概念はありませんデータベースの結合は、アプリケーションコード内のコレクションに対応している可能性があります。ユーザーのインスタンスには、リストまたは辞書またはIEnumerableのアカウントが含まれ、ユーザーの集まりを持つアカウントのインスタンスは停止しません。しかし、ユーザーとアカウントはリポジトリではありません。リポジトリから返されるPOCOである可能性があります。より一般的には、それらはアプリケーションの別のレイヤーで定義され、データレイヤーから返されたPOCOをカプセル化します。これは一貫性の明白な問題を引き起こします。これはあなたが解決するために残されています:-)リポジトリパターンはあなたをここで助けません。ユーザーがユーザー画面でアカウントを選択した場合、UserオブジェクトはAccountUserに挿入するメソッドを、リポジトリーのどこかで呼び出すことがあります。 Account画面でUsersを選択すると、Accountオブジェクトは同じメソッドを呼び出すことがあります。メソッドは、UserRepo、またはAccountRepoまたはSomeOtherRepoAltogetherにあります。

Dapperを使用してEntity Frameworkをエミュレートしようとすると間違いがあります。一度あなたのリポジトリを書き留めてから、決してそれらに触れることはできないと想像してはいけません。 Dapperは自分のデータベースが大好きな方々のためのもので、頻繁に話しています。 Reposは互いに重なることがあります。