2016-12-19 50 views
1

Im tring для реализации шаблона репозитория и всех примеров, которые я нашел, очень просты (игнорируя объединения) или используя сущность framework.Объединение шаблона DAL с использованием dapper

таблицы Мои БД являются

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

Пользователь может иметь несколько учетных записей и учетная запись может иметь несколько пользователей. У tblUserAccount есть логическое значение, указывающее, активен ли пользователь для учетной записи и когда пользователь был добавлен.

my pocos map непосредственно к таблицам с дополнительным свойством для отношений. есть ли лучший способ сделать эту часть? Я не мог придумать лучшего способа для моего репозитория возвращать отношения на что-то вроде 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 из моих РЕПО, как я должен вернуть отношения. как я показал в моих pocos выше или есть лучший способ?
  2. Должны ли мои таблицы отношений получить свои собственные pocos? Если да, то только тогда, когда у них есть дополнительные данные, такие как isActive и пользовательские/учетные настройки.
  3. В моих репозиториях я не уверен, какой репо должен обрабатывать конкретные запросы, когда дело касается отношений.
  4. Должен ли я иметь другое репо для учетных/пользовательских отношений?

критика, ссылки, помощь всем приветствуется Спасибо.

Редактировать:

Дополнительное примечание: Следует упомянуть. Причина, по которой я хочу собрать пользователей/учетных записей, состоит в том, что они будут в сетке, где мы можем активировать/деактивировать и изменить значения для пользователя или их учетной записи.

ответ

1

A 1 & 3 Когда ваш метод UserRepository возвращает объект tblUser, ему не нужно заполнять учетные записи. Все свойства, отличные от коллекции, должны обрабатываться UserRepository. В атрибуте getter account, вызовите методы в AccountRepository, чтобы заставить вызов базы данных получить все учетные записи пользователя в первый раз, когда вызывается получатель.

A 2 Таблицы взаимосвязей не нуждаются в собственных pocos.

A 4 Создайте другой репозиторий для обработки учетных записей отдельно.

+0

A1 и 3 должны были сказать раньше, но использовали его для сетки, чтобы все пользователи должны были получать все учетные записи. производительность будет медленной с вызовами 10k +. Отличная идея, которую я мог бы использовать где-то в другом месте. A 2. Где бы я мог найти tblAccountUser.IsActive, чтобы узнать, активен ли пользователь для определенной учетной записи. A4. Есть один для учетных записей, вы имеете в виду один для tblAccountUsers? – ozz

+0

A 2 В AccountRepository. Вы можете либо фильтровать неактивные учетные записи, либо возвращать IsActive в качестве свойства объекта Account. A 4 Я имею в виду AccountRepository. Создайте такие методы, как GetAccountsByUserId – detale

+0

Я пробовал делать то, что вы предлагали фильтровать неактивно/активно, и показывать их по отдельности, и это было своего рода беспорядок, потому что мы должны иметь возможность искать по user.email и account.name, в зависимости от чего больше Соответствующий. IsActive - свойство как для учетной записи, так и для отношения учетной записи пользователя, что делает ее уникальной. Мне было предложено в другом месте создать poco для связи из-за присутствия дополнительных столбцов, а не только (AccountID, UserID). До сих пор он работал лучше. – ozz

0

Возможно, часть ответа заключается в снятии стресса. Важная часть шаблона репозитория заключается в том, что у вас есть класс, который обертывает ваши вызовы базы данных, который возвращает pocos, а не классы ADO, что позволяет вам тестировать единицу. Косметическая часть представляет собой группировку методов вставки/обновления/удаления в том же классе с помощью методов «select», позволяя забыть, что вы имеете дело с базой данных. Почему вы хотите забыть, это еще один вопрос.

Как только у вас есть класс репо, извлеките его интерфейс. Пример: 1 репозиторий соответствует 1 запросу, соответствует 1 плоскому результирующему набору.Нет понятия объединения в пределах репозитория. Соединения в вашей базе данных могут соответствовать коллекциям в вашем коде приложения: экземпляр пользователя будет содержать список или словарь или IEnumerable of Accounts, и это не останавливает экземпляр учетных записей, имеющих коллекцию пользователей. Но пользователь и учетная запись не являются хранилищами. Они могут быть POCOs, возвращаемые репозиториями. Как правило, они определяются на другом уровне вашего приложения и инкапсулируют POCO, возвращаемые слоем данных. Это вызывает очевидную проблему согласованности, которая остается для вас решить :-) Шаблон репозитория вам не поможет. Если ваши пользователи выбирают учетные записи на экране пользователя, ваш объект User может вызывать метод, который вставляет в AccountUser, где-то в каком-то репозитории. Если вы выберите «Пользователи на экране учетной записи», объект «Учетная запись» может вызвать тот же метод. Этот метод может быть в UserRepo, AccountRepo или SomeOtherRepoAltogether.

Было бы ошибкой попробовать использовать Dapper для эмуляции Entity Framework. Не думайте, что вы можете писать свои репозитории, а затем никогда не прикасаться к ним. Dapper для людей, которые любят свою базу данных и часто говорят с ним. Репо могут перекрывать друг друга.