Spring Boot中医生-患者关系与权限管理实践-小浪学习网

Spring Boot中医生-患者关系与权限管理实践

本文探讨在spring Boot应用中管理医生与患者关系及其权限控制的有效策略。针对多角色用户和复杂业务关系，文章详细比较了多种数据模型，并推荐了一种结合通用用户认证与特定角色数据分离的混合方案。通过清晰的实体设计、JPA注解应用及安全考量，旨在提供一个结构清晰、易于扩展且符合实际业务需求的解决方案。

业务场景与挑战

在构建医疗管理系统时，核心挑战在于如何高效、灵活地管理医生与患者之间的复杂关系，并确保不同角色用户的权限隔离。具体需求包括：

医生与患者的关系管理： 医生可以关联多名患者，患者也可以被多名医生管理，形成多对多（@ManyToMany）关系。
患者的药物信息管理： 患者可以添加并管理其服用的药物信息，药物与患者之间通常是多对多关系（一个药物可能被多个患者服用，一个患者服用多种药物）。
用户认证与权限控制： 系统需要支持用户登录（无论是医生还是患者），并根据其角色（医生或患者）赋予不同的操作权限，例如患者只能管理自己的药物信息，医生可以查看其关联患者的详细信息。

在设计数据模型时，常见的困惑在于：是为每个角色创建独立的实体并处理各自的认证流程，还是采用统一的用户表并结合角色字段来区分？这两种方案各有优缺点，尤其是在安全认证和数据结构灵活性方面。

传统方案评估

在实际开发中，通常会考虑两种基础的数据模型设计思路。

方案一：独立实体与多对多关系

这种方案为每个业务角色（如Doctor和Patient）创建独立的JPA实体。

优点： 实体结构清晰，每个实体只包含其特有的属性，避免了不必要的空字段。业务逻辑可以根据实体类型自然地进行划分。
缺点：
- 安全认证复杂性： 如果医生和患者都有独立的登录入口和认证逻辑，会导致认证模块的重复开发和管理复杂性。例如，可能需要为Doctor和Patient分别实现UserDetailsService。
- 用户共享挑战： 如果一个用户可能同时拥有医生和患者的双重身份，此方案难以优雅地处理。
- 关系管理： Doctor和Patient之间的@ManyToMany关系需要单独维护。

方案二：单一用户表与角色字段

此方案引入一个通用的User实体，其中包含一个roleType字段（如枚举类型DOCTOR, PATIENT）来区分用户类型。

优点：
- 简化安全认证： 所有用户都通过同一个User实体进行认证，极大简化了spring security的集成。
- 统一用户管理： 用户管理（注册、登录、密码重置）逻辑集中化。
- 双重身份可能性： 理论上可以通过为同一User赋予多个角色来支持双重身份（但实际业务中可能需要更复杂的逻辑）。
缺点：
- 数据冗余与空字段： User实体中可能包含所有角色特有的字段。例如，如果Medicine信息只与Patient相关，那么Doctor类型的User在medicineList字段上将是空的，导致数据模型不干净。
- 业务逻辑耦合： 在服务层或控制器层，需要频繁地根据roleType进行条件判断，将不同角色的业务逻辑混杂在一个类中，增加代码复杂度和维护难度。
- 实体关系复杂： 如果Doctor和Patient之间需要建立@ManyToMany关系，并且Medicine只关联Patient，那么在单一User实体中管理这些复杂关系会变得非常混乱。

推荐的数据模型与设计

综合考虑上述两种方案的优缺点，推荐一种混合模式：通用用户认证与特定角色数据分离。这种方案既能利用统一用户表简化认证，又能通过角色特有实体保持数据模型的清晰和业务逻辑的解耦。

核心思想

User 实体： 负责存储所有用户的通用信息（如ID、姓名、姓氏、登录凭证、角色类型等），主要用于身份认证和基本信息管理。
Doctor 和 Patient 实体： 存储各自角色特有的属性和关系。它们通过 @OneToOne 关系与 User 实体关联，并使用 @MapsId 注解共享主键，确保一个 User 记录只能对应一个 Doctor 或 Patient 记录（或两者之一）。

实体设计示例

// 1. User 实体：通用用户认证信息 import javax.persistence.*; import lombok.Getter; import lombok.Setter; import lombok.NoArgsConstructor; import lombok.AllArgsConstructor;  @Entity @Getter @Setter @NoArgsConstructor @AllArgsConstructor @Table(name = "app_users") // 避免与数据库保留字冲突 public class User {      @Id     @GeneratedValue(strategy = GenerationType.IDENTITY)     private Long id;     private String username; // 用于登录的用户名     private String password; // 加密后的密码     private String name;     private String surname;      @Enumerated(EnumType.STRING)     @Column(Nullable = false)     private UserType userType; // DOCTOR 或 PATIENT      // 可以添加其他通用字段，例如 email, phone 等 }  // UserType 枚举 public enum UserType {     DOCTOR,     PATIENT }  // 2. Doctor 实体：医生特有信息和关系 import javax.persistence.*; import lombok.Getter; import lombok.Setter; import java.util.HashSet; import java.util.Set;  @Entity @Getter @Setter public class Doctor {      @Id     private Long id; // 与 User 实体共享主键      @OneToOne(fetch = FetchType.LAZY)     @MapsId // 表示此实体的主键是其关联实体的主键     @JoinColumn(name = "id", nullable = false)     private User user; // 关联的 User 实体      // 医生特有属性，例如专业领域、执业证书编号等     private String specialization;      // 医生与患者的多对多关系     @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}) // 级联操作     @JoinTable(         name = "doctor_patient", // 关系表名         joinColumns = @JoinColumn(name = "doctor_id"), // 医生表在外键中的列名         inverseJoinColumns = @JoinColumn(name = "patient_id") // 患者表在外键中的列名     )     private Set<Patient> patients = new HashSet<>();      public void addPatient(Patient patient) {         this.patients.add(patient);         patient.getDoctors().add(this);     }      public void removePatient(Patient patient) {         this.patients.remove(patient);         patient.getDoctors().remove(this);     } }  // 3. Patient 实体：患者特有信息和关系 import javax.persistence.*; import lombok.Getter; import lombok.Setter; import java.util.ArrayList; import java.util.HashSet; import java.util.List; import java.util.Set;  @Entity @Getter @Setter public class Patient {      @Id     private Long id; // 与 User 实体共享主键      @OneToOne(fetch = FetchType.LAZY)     @MapsId // 表示此实体的主键是其关联实体的主键     @JoinColumn(name = "id", nullable = false)     private User user; // 关联的 User 实体      // 患者特有属性，例如病史、过敏信息等     private String medicalHistory;      // 患者与药物的多对多关系     @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})     @JoinTable(         name = "patient_medicine",         joinColumns = @JoinColumn(name = "patient_id"),         inverseJoinColumns = @JoinColumn(name = "medicine_id")     )     private Set<Medicine> medicines = new HashSet<>();      // 患者与医生的多对多关系（通过 Doctor 实体映射）     @ManyToMany(mappedBy = "patients", fetch = FetchType.LAZY)     private Set<Doctor> doctors = new HashSet<>();      public void addMedicine(Medicine medicine) {         this.medicines.add(medicine);         medicine.getPatients().add(this);     }      public void removeMedicine(Medicine medicine) {         this.medicines.remove(medicine);         medicine.getPatients().remove(this);     } }  // 4. Medicine 实体：药物信息 import javax.persistence.*; import lombok.Getter; import lombok.Setter; import java.util.HashSet; import java.util.Set;  @Entity @Getter @Setter public class Medicine {      @Id     @GeneratedValue(strategy = GenerationType.IDENTITY)     private Long id;     private String name;     private String description;      // 药物与患者的多对多关系（通过 Patient 实体映射）     @ManyToMany(mappedBy = "medicines", fetch = FetchType.LAZY)     private Set<Patient> patients = new HashSet<>(); }

JPA 注解详解

@OneToOne 和 @MapsId：
- @OneToOne 表示 Doctor 或 Patient 实体与 User 实体之间存在一对一关系。
- @MapsId 是一个非常关键的注解，它指示JPA使用关联实体（这里是User）的主键作为当前实体（Doctor或Patient）的主键。这意味着Doctor.id和Patient.id的值将直接取自它们关联的User.id。这有效地将Doctor或Patient的记录与一个特定的User记录紧密绑定，并确保了主键的一致性。
- @JoinColumn(name = “id”, nullable = false) 指定了外键列的名称，这里外键列名也叫id，并且不允许为空，强制关联。
@ManyToMany 和 @JoinTable：
- @ManyToMany 用于表示多对多关系，例如医生与患者、患者与药物。
- @JoinTable 用于定义关系表的名称以及关联双方在关系表中的外键列名。
  - name: 指定中间表的名称。
  - joinColumns: 定义当前实体（拥有@JoinTable的实体）在中间表中的外键列。
  - inverseJoinColumns: 定义关联实体在中间表中的外键列。
- mappedBy: 在多对多关系中，一方（通常是关系维护方）使用@JoinTable，另一方使用mappedBy来指定关系由哪一方维护，避免重复定义关系表。

安全与权限管理

采用上述混合模型后，Spring Security的实现将变得更加简洁和灵活。

基于 User 实体进行认证：

Spring Security的 UserDetailsService 只需要从 User 仓库中加载用户。
在 User 实体中可以包含 username 和 password 字段用于认证。
UserType 字段可以作为用户的角色信息，在 UserDetails 实现中将其转换为 GrantedAuthority。

// 示例：自定义 UserDetailsService import org.springframework.security.core.userdetails.UserDetails; import org.springframework.security.core.userdetails.UserDetailsService; import org.springframework.security.core.userdetails.UsernameNotFoundException; import org.springframework.stereotype.Service; import org.springframework.security.core.authority.SimpleGrantedAuthority; import java.util.Collections;  @Service public class CustomUserDetailsService implements UserDetailsService {      private final UserRepository userRepository; // 假设有一个 UserRepository      public CustomUserDetailsService(UserRepository userRepository) {         this.userRepository = userRepository;     }      @Override     public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {         User user = userRepository.findByUsername(username)                 .orElseThrow(() -> new UsernameNotFoundException("User not found with username: " + username));          return new org.springframework.security.core.userdetails.User(                 user.getUsername(),                 user.getPassword(),                 Collections.singletonList(new SimpleGrantedAuthority("ROLE_" + user.getUserType().name())) // 将 UserType 映射为角色         );     } }

根据用户类型进行权限控制：

用户登录后，其 UserType 信息已作为角色附加到 SecurityContext 中。
在控制器或服务层，可以通过 @PreAuthorize 注解或手动检查当前用户的角色来限制访问。
例如，一个控制器方法只允许医生访问：@PreAuthorize(“hasRole(‘ROLE_DOCTOR’)”)。
当需要访问医生或患者特有的数据时，可以先通过 SecurityContextHolder 获取当前登录用户的ID，然后根据其 UserType 从 Doctor 或 Patient 仓库中加载对应的实体。

// 示例：获取当前登录用户并加载其角色实体 import org.springframework.security.core.Authentication; import org.springframework.security.core.context.SecurityContextHolder; import org.springframework.security.core.userdetails.UserDetails;  @Service public class UserProfileService {      private final UserRepository userRepository;     private final DoctorRepository doctorRepository;     private final PatientRepository patientRepository;      // 构造器注入...      public Object getCurrentUserProfile() {         Authentication authentication = SecurityContextHolder.getContext().getAuthentication();         if (authentication == null || !(authentication.getPrincipal() instanceof UserDetails)) {             throw new IllegalStateException("User not authenticated.");         }          UserDetails userDetails = (UserDetails) authentication.getPrincipal();         User user = userRepository.findByUsername(userDetails.getUsername())                                   .orElseThrow(() -> new UsernameNotFoundException("User not found"));          if (user.getUserType() == UserType.DOCTOR) {             return doctorRepository.findById(user.getId())                                    .orElseThrow(() -> new RuntimeException("Doctor profile not found"));         } else if (user.getUserType() == UserType.PATIENT) {             return patientRepository.findById(user.getId())                                     .orElseThrow(() -> new RuntimeException("Patient profile not found"));         } else {             // 处理其他用户类型或抛出异常             return null;         }     } }

处理“医生同时也是患者”的场景：
- 当前模型在设计上支持一个User可以同时拥有Doctor和Patient的身份，因为Doctor和Patient实体的主键都映射自User。
- 若业务允许，可以在注册时为同一User创建Doctor和Patient记录。
- 在权限控制时，可以根据业务上下文，检查用户是否同时拥有ROLE_DOCTOR和ROLE_PATIENT，然后决定允许的操作。例如，当用户以医生身份操作时，加载Doctor实体；当以患者身份操作时，加载Patient实体。这为更复杂的业务场景提供了极大的灵活性。

服务层设计考量

基于上述实体结构，服务层可以清晰地进行职责划分：

UserService： 负责用户的注册、登录、密码修改等通用用户管理操作，主要与 User 实体交互。
DoctorService： 负责医生的业务逻辑，如管理医生信息、查看关联患者、分配患者等。它将与 Doctor 实体及其关联的 Patient 实体交互。
PatientService： 负责患者的业务逻辑，如管理患者信息、添加/查看药物、查看关联医生等。它将与 Patient 实体及其关联的 Medicine 和 Doctor 实体交互。

这种划分使得每个服务类职责单一，代码可读性高，易于维护和扩展。