Spring Boot中医生-患者关系与权限管理实践-java教程-PHP中文网

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 映射为角色
        );
    }
}

登录后复制

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

NovelAI

AI 辅助写作、讲故事，基于你自己的作品创造出类似人类的写作。

236

查看详情

用户登录后，其 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 实体交互。

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