Il s'agit d'une question de conception assez longue (pas trop compliquée), alors s'il vous plaît gardez-moi. J'essaie de mettre en place un système de gestion des personnes/rôles avec les POJO et JPA. Je suis assez nouveau à ORM et c'est surtout un problème de cartographie. J'ai cela fonctionne comme POJOs et je suis à l'aise avec l'API au niveau de l'appelant, mais je voudrais maintenant le mapper à une base de données en utilisant JPA ou Hibernate dans un environnement Seam. Mon implémentation est basée sur les modèles Décorateur (GoF) et Objet de rôle de personne (Baumer/Riehle et al.). Tous les rôles sont codés en dur et l'ajout de nouveaux rôles au moment de l'exécution n'est pas pris en charge car il nécessiterait des modifications de code pour étendre le comportement. J'utiliserais des groupes d'utilisateurs pour implémenter la sécurité et les permissions.Mappage d'héritage avec JPA/Hibernate
Il existe une interface Person avec des méthodes de gestion de rôle telles que addRole(), removeRole(), hasRole(), getRole(), getRoles(), entre autres choses. L'implémentation concrète est fournie par une classe PersonImpl.
Il existe un rôle de classe abstraite qui implémente également l'interface Person (pour l'équivalence de substitution du décorateur) et une classe RoleImpl qui l'étend. La classe Role contient une référence à une instance de personne, l'utilisant pour gérer les appels de méthode/propriété sur l'interface de personne, ce qui signifie que toutes les sous-classes de Role peuvent gérer l'interface Person. Le constructeur de rôle prend l'objet person en paramètre.
Ce sont les interfaces/classes:
public interface Person {
public String getFirstName();
public void setFirstName(String firstName);
.
.
.
public boolean isEnabled();
public void setEnabled(boolean enabled);
public Set<Role> getRoles();
public Role addRole(Class<? extends Role> roleType);
public void removeRole(Class<? extends Role> roleType);
public boolean hasRole(Class<? extends Role> roleType);
public Role getRole(Class<? extends Role> roleType);
public enum Gender {MALE, FEMALE, UNKNOWN};
}
public class PersonImpl implements Person {
.
.
.
}
public abstract class Role implements Person {
protected PersonImpl person;
@Transient
protected abstract String getRoleName();
protected Role() {}
public Role(PersonImpl person) {
this.person = person;
}
public String getFirstName() {
return person.getFirstName();
}
public void setFirstName(String firstName) {
person.setFirstName(firstName);
}
public Set<Role> getRoles() {
return person.getRoles();
}
public Role addRole(Class<? extends Role> roleType) {
return person.addRole(roleType);
}
.
.
.
}
public abstract class RoleImpl extends Role {
private String roleName;
protected RoleImpl() {}
public RoleImpl(PersonImpl person) {
super(person);
}
.
.
.
}
public class Employee extends RoleImpl {
private Date joiningDate;
private Date leavingDate;
private double salary;
public Employee(PersonImpl person) {
super(person);
}
.
.
.
}
Ce diagramme montre les rapports de classe:
(Si vous ne pouvez pas voir la ligne du diagramme, voir ici via yUML)
J'utiliserais ces classes comme suit:
Person p = new Person("Doe", "John", Person.MALE, ...);
// assuming Employee extends Role
Employee e = (Employee)p.addRole(Employee.class);
Depuis la classe de rôle implémente également l'interface de personne, je peux aussi faire:
// assuming Parent extends Role
Parent parent = new Parent((PersonImpl)p);
e.addRole(Parent.class);
e.getDateOfBirth(); // handled by the decorated person class
// assuming Manager extends Employee extends Role
Manager m = (Manager)p.getRole(Manager);
if (m.hasRole(Employee.class) {
// true since Manager derives from Employee
}
Les questions que je sont:
(a) Est-ce la mise en œuvre inutilement complexe et si oui quelle serait être une approche plus simple? Notez que cela va dans une application métier non triviale et pas un projet kiddy, et je pense que le rôle de sous-classe est important pour tirer parti des comportements dans des cas tels que Employé, Gestionnaire, etc.
(b) Comment mapper ceci? dans JPA/Hibernate?
(c) Peut-il être mappé pour que je puisse également profiter de Seam Identity Management? (D) Si j'utilise une stratégie de mappage table par sous-classe (InheritanceType.JOINED), je mappe PersonImpl en tant que tables PERSON et RoleImpl en tant que tables ROLES, et mappe chaque sous-classe de RoleImpl (comme Employee et Parent) à leurs propres tables comme EMPLOYEES et PARENTS.
J'aurais alors une relation @ManyToMany entre PERSONS et ROLES (sur la collection de rôles dans PersonImpl), avec la table de jointure PERSON_ROLES.Maintenant le problème est que les tables EMPLOYEES et PARENTS, etc. ont seulement la référence ROLE_ID, puisque la stratégie de mapping d'héritage les considère évidemment comme des extensions de ROLES (ROLES) alors que j'en ai besoin comme addenda à PERSON_ROLES, et exige la clé USER_ID + ROLE_ID à résoudre correctement, ou au moins le USER_ID. Je préférerais une base de données normalisée avec une dépendance sur les jointures supplémentaires qu'une base de données dénormalisée qui sera difficile à maintenir et qui regroupera probablement une tonne de champs inutilisés et non pertinents, c'est pourquoi je pense que la table par sous-classe est le chemin à parcourir.
Ou est une hiérarchie de table par classe (InheritanceType.SINGLE_TABLE) avec une colonne de discriminant OK (du point de vue de la maintenance de la base de données) dans ce scénario? Notez que certains rôles sont susceptibles d'avoir des dizaines de propriétés/champs. (E) Y a-t-il une meilleure alternative à cette conception?
Apprécierait beaucoup des idées/suggestions.
Si chaque objet de rôle s'applique à un objet individuel, comme votre code l'indique, alors pourquoi existe-t-il une relation @ManyToMany entre PERSONNES et ROLES? N'est-ce pas @OneToMany? –
Une personne peut avoir plusieurs rôles. Chaque rôle peut avoir plusieurs personnes. Je pense que le point d'Arthur @OneToMany d'un côté et @ManyToOne de l'autre peut avoir un certain mérite. Je dois vérifier ... –