建模不同的用户
我需要一些专家的建议。我需要为我的 Web 应用程序建模不同的用户类型，但不确定如何最好地建模。基本上该应用程序的用户是治疗师。本质上是应用程序的用户。那么我是创建一个治疗师表/域对象和一个治疗师DAO，还是保留一个通用用户表/userDAO 并使用角色类型/名称？当所有查询都针对治疗师表时，使用通用用户表和始终引用用户表的 DAO 方法似乎很奇怪。例如，返回治疗师提供的所有治疗类型的方法将是 findTherapyTypes(治疗师，治疗师Id)。但是，如果我使用用户表和用户域对象，该方法将是 findTherapyTypes(User, userId) ，这似乎不正确。如果我使用通用用户域对象，那么它将有一个似乎不正确的治疗类型列表，因为将来可能会出现不同的用户类型（例如患者），在这种情况下，治疗类型列表将始终为空，因为它不会申请。
将来可能会有其他用户类型，例如患者或客户，他们根据治疗师接受的治疗留下反馈？
我将使用 Hibernate，所以正在考虑为用户使用继承映射，不同的用户类型有一个治疗师类扩展一个基本的 User 类并实现一个具有常见属性（如名字、姓氏等）的用户界面。
任何反馈将不胜感激:) ：）
谢谢 标记
I need some expert advice. I need to model different user types for my web application and am not sure how to best model this. Basically the users for the application are therapists. Essentially there are the users of the application. So do I create a therapist table/domain object and a therapistDAO, or do I keep a generic user table/userDAO instead and use role types/names instead? It seems strange having a generic user table and DAO methods always referring to the userTable, when all queries will be against the therapist table. For example, a method to return all therapy types offered by a therapist will be findTherapyTypes(therapist, therapistId). However, if I use user tables and User domain object the method would be the findTherapyTypes(User, userId) which doesnt seem right. If I use a generic User domain object, then it will have a List of therapytypes which doesnt seem correct as it could in the future a different user type lets say Patient, and in this case the List of therapytyppes would always be null as it wouldnt apply.
In the future there might be other user types, e.g. Patient or Customer those who leave feedback based on treatments received by therapists?
I will be using Hibernate so was thinking of using inheritance mapping for the user different user types having a therapist class extend a base User class and implement a User interface with common properties such as firstname, surname etc.
Any feedback would be much appreciated :) :)
thanks
Mark
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您应该花一些时间分析您想要涵盖的用例。用文字描述它们（正如您在帖子中开始的那样）。
不要一开始就认为治疗师、顾客和患者都是用户。尝试找出您需要的所有信息以及它们的生命周期。应用程序应该如何处理它们？指定用例后，应该清楚哪些是用户，哪些只是模型中的简单实体，而不是参与者。
假设在这一切之后，你最终会得到超过一种类型的用户，假设治疗师和患者，迫使他们坚持在一个表中，并有一列决定他们的类型对我来说似乎不自然。治疗师可能需要参考所有对患者没有意义的集合（反之亦然）。
我的建议是（如果您最终有超过一种类型的用户）创建一个用户表（包含所有常见字段和集合）、一个治疗师表和一个患者表。使用 Hibernate 的继承映射（http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html），您的设计应该保持干净且易于扩展。我推荐每个子类的表策略，但这可能只是个人偏好。
I think you should spend a bit of time analyzing the use cases that you want to cover. Describe them in words (as you've started in your post).
Don't start with the idea that Therapists and Customers and Patients are all Users. Try to find out what information you need for all of them and what is their lifecycle. What is the application supposed to do with them? After you've specified your use cases, it should then be clear which of them are Users and which are just simple entities in your model, but not actors.
Assuming that after all this you will end up with more then 1 type of users, assuming Therapists and Patients, forcing them to be persisted in one single table and having a column deciding their type seems un-natural to me. Therapists will probably need to refer all sort of collections that don't make sense for a Patient (and the other way around).
My suggestion is (if you end up with more then 1 type of user) to create a User table (with all common fields and collections), a Therapists table and a Patients one. Use Hibernate's inheritance mapping (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html) and your design should remain clean and easy to extend. I'd recommend the Table per subclass strategy, but that's probably only a personal preference.