modelling different USERS

Question

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

Answer 1

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.