Фабрика пользователей и репозиторий

Я нахожусь в процессе определения подхода к дизайну. Я хотел бы, чтобы ваши материалы

У меня есть 2 типа пользователей

  1. Корпоративные внутренние пользователи
  2. Пользователи клиентов

Принципиальные различия между ними технически

  1. Корпоративный: Не нужно сохранять пароли в системе, а только роли (аутентификация по AD)
  2. Пользователи клиентов: сохраните пароль в системе и получите связанный идентификатор клиента.

У меня есть таблица User, в которой есть такие столбцы

User Name  
Password  
Roles  
Customer ID

Если я абстрагирую процесс создания пользователя, используя шаблон абстрактной фабрики, я получу 2 типа пользовательских объектов.

Теперь, когда дело доходит до создания репозитория, как мне с этим справиться? Создаю ли я 2 разных репозитория для обработки отдельных объектов типа пользователя (сопоставление с одной и той же таблицей)


.net repository factory domain-driven-design
person Gopal    schedule 18.04.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Могут ли корпоративные пользователи быть клиентами? Если да, то ожидаете ли вы, что они будут использовать один и тот же идентификатор? Если это так, возможно, вам стоит рассмотреть реализацию шаблона Party-Role (он же Actor-Participant). .

Это позволит вам создать унифицированное решение для управления как внутренними ролями пользователей, так и различием корпоративных и клиентских функций.

чт.

person sfinnie    schedule 19.04.2011
comment
Нет. Корпоративный пользователь — это UserID, связанный с Клиентом, чтобы Клиент мог войти в систему. С клиентом может быть связано несколько идентификаторов пользователей. Профиль клиента — это вообще отдельная запись. - person Gopal; 19.04.2011

arrow_upward
1
arrow_downward

Вам следует подумать о добавлении столбца типа пользователя в вашу пользовательскую таблицу. Таким образом, вы можете отслеживать, какой тип пользователя представляет каждая запись. Это будет полезно при создании пользовательских сущностей в операции поиска/получения на уровне репозитория, а также при выполнении процедуры добавления или обновления. Я бы предложил только один «пользовательский» репозиторий. Вам не понадобятся два класса репозитория, если вы используете наследование и отслеживаете тип пользователя на уровне базы данных.

Надеюсь это поможет.

Наслаждаться!

person Doug    schedule 18.04.2011
comment
Как будет выглядеть hbm xml, если мы будем использовать nHibernate? Так как у каждого типа пользователя есть свой набор полей. У нас должно быть 2 разных файла hbm, один для CorporateUser, а другой для CustomerUser, отображающих соответствующие поля в одну и ту же таблицу? - person Gopal; 19.04.2011
comment
@GeorgeKT - у меня нет опыта работы с объектно-реальными картографами, и я предпочитаю реализовывать шаблон репозитория непосредственно для повышения производительности. Хорошее описание шаблона репозитория можно найти здесь msdn.microsoft.com/en -us/library/ff649690.aspx — Надеюсь, это поможет - person Doug; 20.04.2011
comment
если бы тип был введен, я думаю, фабрика последовала бы его примеру - person hanzolo; 06.02.2013

arrow_upward
1
arrow_downward

Может быть, я могу дать вам несколько советов. Я согласен с Дугом в том, что вы должны использовать только один UserRepository, который управляет классами User Aggregate.

Вот как я бы сделал это с (свободно) Nhibernate:

Пользовательский класс с полем перечисления UserType, сопоставленным с одним столбцом. См. эту статью, она очень хороша, и я несколько раз использовал решение Джимми Богарда (http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/). Тогда у вас есть класс UserType, который на самом деле просто представлен в базе данных как столбец в таблице User, НО у вас есть полный класс с Behavior и т. д.

Затем, чтобы устранить ваши различия в том, как каждый тип должен обрабатывать пароли и отношения с клиентами, вы можете использовать шаблон валидатора, чтобы подтвердить, что ваш экземпляр User действителен (на основе вашего UserType), прежде чем сохранять его в db. Посмотрите этот блог http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/ (опять Джимми... Нужно ли говорить, что вам следует подписаться на блог Джимми Богарда: )).

Затем у вас есть UserPersistanceValidator, который проверяет, является ли UserType внутренним, pwd не требуется и должна быть указана роль AD. Вы получаете картину...

Я надеюсь, что это поможет вам. Удачи!

person Magnus Backeus    schedule 20.04.2011
comment
Я получаю картину. Спасибо большое :) @Doug Спасибо и вам. - person Gopal; 20.04.2011