我正在确定一种设计方法。我想听听你的意见
我有两类用户
- 企业内部用户<
- 客户用户/gh>
它们在技术上的根本区别是
- Corporate:不需要在系统中保存密码，只需要保存角色(针对AD的身份验证)
- 客户用户:在系统中保存密码，并具有关联的客户ID。
我有一个User表，它的列如下
User Name
Password
Roles
Customer ID
如果我使用抽象工厂模式抽象用户创建过程，我得到两种类型的用户对象。
现在，当涉及到创建存储库时，我该如何处理它?我是否创建两个不同的存储库来处理单个用户类型对象(映射到同一个表)
企业用户也可以是客户吗?如果是这样，您希望它们使用相同的ID吗?如果是这样，您可能需要考虑实现党-角色模式(又名参与者-参与者)。
它将允许您使用统一的解决方案来处理内部用户角色和公司与客户的区别。
hth .
您应该考虑在用户表中添加一个用户类型列。这样就可以跟踪每条记录所代表的用户类型。当在存储库层的查找/获取操作上创建用户实体时，以及在执行添加或更新过程时，这将非常有用。我建议只有一个"用户"存储库。如果您使用继承并在数据库级别跟踪用户类型，则不需要两个存储库类。
希望对你有帮助。
享受吧!
也许我可以给你一些提示。我同意Doug的观点，你应该只使用一个UserRepository来管理User Aggregate类。
这是我如何使用(Fluent) Nhibernate:
具有映射到单列的UserType Enumeration字段的用户类。看看这篇文章，它非常好，我已经使用了几次Jimmy Bogard的解决方案(http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/)。然后你有一个UserType类，实际上只是表示为一个列在用户表数据库，但你有一个完整的类行为等。
然后，为了解决每个类型应该如何处理密码和客户关系的差异，您可以使用验证器模式来确认您的User实例是有效的(基于您的UserType)，然后将其保存到db。看看这个博客http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/(又是Jimmy…需要我说你应该订阅Jimmy Bogard的博客吗:))。
然后你有一个UserPersistanceValidator，检查UserType是否是内部的，不需要pwd, AD角色必须提供。你懂的…
我希望这对你有帮助。好运！