modélisation différents UTILISATEURS

Question

J'ai besoin de conseils d'experts. J'ai besoin de modéliser différents types d'utilisateurs pour mon application web et je ne suis pas sûr de la meilleure façon de modéliser cela. Fondamentalement, les utilisateurs de l'application sont des thérapeutes. Essentiellement, il y a les utilisateurs de l'application. Donc, est-ce que je crée un thérapeuteDAO de table/domaine de thérapeute, ou est-ce que je garde à la place une table d'utilisateur générique/userDAO et utilise plutôt des types de rôles/noms? Il semble étrange d'avoir une table d'utilisateur générique et des méthodes DAO faisant toujours référence à userTable, quand toutes les requêtes seront contre la table du thérapeute. Par exemple, une méthode pour retourner tous les types de thérapie offerts par un thérapeute sera findTherapyTypes (therapist, therapistId). Cependant, si j'utilise des tables utilisateur et un objet domaine utilisateur, la méthode serait findTherapyTypes (User, userId) qui ne semble pas correcte. Si j'utilise un objet domaine utilisateur générique, alors il aura une liste de types de thérapie qui ne semble pas correcte car il pourrait à l'avenir un autre type d'utilisateur laisse dire Patient, et dans ce cas la liste des thérapies serait toujours nulle car elle ne le serait pas appliquer.

À l'avenir, il pourrait y avoir d'autres types d'utilisateurs, par ex. Les patients ou les clients qui laissent des commentaires sur la base des traitements reçus par les thérapeutes?

Je vais utiliser Hibernate donc été pensée d'utiliser la cartographie d'héritage pour l'utilisateur différents types d'utilisateurs ayant étendez une classe de thérapeute une base de classe utilisateur et mettre en œuvre une interface utilisateur avec des propriétés communes telles que prenom, nom de famille, etc.

Tous les commentaires serait très apprécié :) :)

merci Mark

Answer 1

Je pense que vous devriez passer un peu de temps à analyser les cas d'utilisation que vous souhaitez couvrir. Décrivez-les en mots (comme vous avez commencé dans votre message). Ne partez pas de l'idée que les thérapeutes, les clients et les patients sont tous des utilisateurs. Essayez de trouver les informations dont vous avez besoin pour chacun d'entre eux et quel est leur cycle de vie. Qu'est-ce que l'application est censée faire avec eux? Une fois que vous avez spécifié vos cas d'utilisation, il doit alors être clair lesquels d'entre eux sont Utilisateurs et qui ne sont que des entités simples dans votre modèle, mais pas des acteurs. En supposant qu'après tout cela, vous finirez avec plus d'un type d'utilisateurs, en supposant que les thérapeutes et les patients, les forçant à persister dans une seule table et ayant une colonne décidant de leur type me semble peu naturel. Les thérapeutes devront probablement référer toutes sortes de collections qui n'ont pas de sens pour un patient (et inversement).

Ma suggestion est (si vous vous retrouvez avec plus d'un type d'utilisateur) de créer une table utilisateur (avec tous les champs et collections communs), une table de thérapeutes et une table de patients. Utilisez le mappage d'héritage de Hibernate (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html) et votre conception devrait rester propre et facile à étendre. Je recommande la stratégie Table par sous-classe, mais ce n'est probablement qu'une préférence personnelle.