2015-11-23 2 views
0

Как всегда, я всегда ищу шаблоны для написания лучших программ. Недавно я провел некоторое время с пользовательскими Repositories и DTO. Все это хорошо, но у меня есть сценарий, где у меня есть три DTO's:Образец для возврата объекта, созданного несколькими репозиториями

  1. Токен
  2. пользователя
  3. Bio

И три хранилищами (отображенный на DTO-х)

  1. TokenRepository
  2. UserRepository
  3. BioRepository

Теперь, если пользователь "A" делает запрос, который затем вызывает GetUserByCredentials(User user);

Я хочу, чтобы обработать объект - может быть UserFacade? У которого есть свойства всех трех таблиц/Obj.

Итак, в чем же заключается лучший подход или образец?

Следует отметить, что между нет никаких связей.

Я чувствую, что в конечном итоге это сохранит все мои репозитории/DTO's в чистоте.

// EDIT

Просто для уточнения базы данных содержит отношения. Я не вернусь tbl_User как объект, построенного EF - я карта это в DTO без использования Code First/Auto Mapper и т.д.

Для примера (старый метод):

public User GetUser(string email, string password) 
{ 
    var user = context.tbl_User 
     .Where(u => u.Email == email && u.Password == password) 
     .Select(y => new User 
      { 
       UserID = y.UserID, 
       Email = y.Email, 
       Password = y.Password, 
       Token = y.tbl_Token 
         .Where(x => x.UserID == y.UserID) 
         .Select(z => z.TokenName).FirstOrDefault(), 
       ProfilePic = y.tbl_Bio.Where(t => t.UserID == y.UserID).Select(p => p.Avatar).FirstOrDefault(), 
       RoleID = y.RoleID 

      }).FirstOrDefault(); 

    return user; 
} 

В идеале I» хочется раздеть токен и ProfilePic как эти свойства будут уже существовать в там собственных классов (DTO в)

Я надеюсь, что я не думаю о шаблонах слишком много ха-ха

Спасибо за ваше время!

С уважением,

+0

Если нет никакой связи между ними, как бы вы знали, что запрос ога других хранилищ при выполнении вызова 'GetUserByCredentials (пользователь пользователя);' – 3dd

+0

Извинения, отношения в терминах DTO. Я добавлю фрагмент кода. Спасибо за ваше время. –

+0

Непонятно, что вы просите. Вы просто спрашиваете, следует ли вам/как вам создать класс, который будет в основном извлекать пользователя, затем извлекать биографию пользователя, затем извлекать токен пользователя и создавать новый составной класс? т. е. ваш бизнес-уровень считает, что у пользователя есть биография и токен, но ваш уровень данных относится к ним отдельно? –

ответ

0

Я обычно делают использование хранилищ, чтобы работать на моем Aggregate Roots.

Martin Fowler определен совокупный корень, как

кластера объектов предметной области, которые можно рассматривать как единое целое

В этом случае User будет ваш совокупный корень и Token и Bio бы свойства User.

Таким образом, когда вам нужно внести изменения в любой Bio или Token вы будете делать это через UserRepository

+0

Итак, просто чтобы уточнить, нет другой абстракции поверх UserRepository? Вы используете Repo как корень агрегата? –

+0

Мой сервисный уровень использует репозитории и делает хореографию между репозиториями. Агрегированный корень - это объект «Пользователь», репозиторий работает с доступом к данным для полного заполнителя. – 3dd

+0

Фантастический, спасибо за четкий, сжатый ответ/комментарии! –

Смежные вопросы