Пользовательская фабрика и репозиторий

Question

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

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

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

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

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

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

User Name  
Password  
Roles  
Customer ID  

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

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

Answer 1

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

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

Answer 2

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

Так я бы поступил с (Свободно) Nhibernate:

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

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

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

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

Answer 3

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

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

Наслаждайтесь!