用户工厂和存储库
我正在确定设计方法。我想听听您的意见
我有 2 种类型的用户
- 企业内部用户
- 客户用户
从技术上讲，它们之间的根本区别是
- 企业：不需要在系统中保存密码，而只需要角色（针对 AD 进行身份验证）
- 客户用户：将密码保存在系统中系统并具有关联的客户 ID。
我有一个表 User，其中包含如下列
User Name
Password
Roles
Customer ID
如果我使用抽象工厂模式抽象用户创建过程，我会得到两种类型的用户对象。
现在，当涉及到创建存储库时，我该如何处理呢？我是否创建 2 个不同的存储库来处理单个用户类型对象（映射到同一个表）
I'm in the process of determining an approach for design. I would like your inputs
I have 2 types of users
- Corporate Internal Users
- Customer Users
The fundamental differences between them technically is
- Corporate: Don't need to save passwords in the system but only roles (authentication against AD)
- Customer Users:Save password in the system and have an associated customer ID.
I have a table User which have the columns like so
User Name
Password
Roles
Customer ID
If I abstract the user creation process using an abstract factory pattern, I get the 2 types of user objects.
Now when it comes to creating a repository, how do I handle it? Do I create 2 different repositories to handle individual user type objects (mapping to same table)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
企业用户也可以是客户吗？如果是这样，您会希望他们使用相同的 ID 吗？如果是这样，您可能需要考虑实现 Party-Role 模式（又名 Actor-Participant） 。
它将为您提供统一的解决方案来处理内部用户角色以及公司与客户的区别。
嗯。
Can corporate users also be customers? If so, would you expect them to use the same ID? If so, you might want to look at implementing the Party-Role pattern (aka Actor-Participant).
It would allow you a unified solution for handling both internal user roles and corporate vs. customer distinction.
hth.
您应该考虑向用户表添加用户类型列。这样您就可以跟踪每条记录代表的用户类型。当您在存储库层中的查找/获取操作上创建用户实体以及执行添加或更新过程时，这将很有用。我建议只使用一个“用户”存储库。如果您使用继承并在数据库级别跟踪用户类型，则不需要两个存储库类。
希望这有帮助。
享受！
You should consider adding a user type column to your user table. This way you can track what type of user each record represents. This will be of use when creating user entitys on a find/get operation in your repository layer as well as when you are doing an add or update procedure. I would suggest only one "user" repository. You will not need two repository classes if you use inheritance and track the user type at the database level.
Hope this helps.
Enjoy!
也许我可以给你一些提示。我同意 Doug 的观点，即您应该只使用一个管理用户聚合类的 UserRepository。
这就是我使用（流畅的）Nhibernate 的方式：
具有映射到单个列的 UserType 枚举字段的用户类。请参阅这篇文章，它非常好，我已经多次使用吉米·博加德的解决方案（http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/）。然后你有一个 UserType 类，它实际上只是在数据库中表示为 User 表中的一列，但是你有一个包含行为等的完整类。
然后为了解决每种类型应如何处理密码和客户关系的差异，你可以使用验证器模式，用于在将用户实例保存到 db 之前确认您的用户实例是否有效（基于您的用户类型）。看看这个博客 http:// lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/ （吉米再次......我需要说你应该订阅吉米博加德的博客:)）。
然后你有一个 UserPersistanceValidator 来检查 UserType 是否是内部的，不需要密码并且必须提供 AD 角色。你明白了...
我希望这会对你有所帮助。祝你好运！
Maybe I can give you some hints. I agree with Doug that you should only use one UserRepository that manage User Aggregate classes.
This is how I would do it with (Fluent) Nhibernate:
User class with a UserType Enumeration field that is mapped to a single column. See this article, its very good and I've used Jimmy Bogard's solution several times (http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/). Then you have a UserType class that is actually just represented i database as a column in User table, BUT you have a full class with Behaviour etc.
Then to solve your differences in how each type should handle passwords and Customer relationship, you can use a validator pattern to confirm that your User instance is valid (based on your UserType) before saving it to db. Look at this blog http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/ (Jimmy again... Do I need to say that you should subscribe on Jimmy Bogard's blog :)).
Then you have a UserPersistanceValidator that check's if UserType is internal, no pwd is required and AD role must be supplied. You get the picture...
I hope this will help you. Good luck!