医院信息化与智能化系统(3)

这里只描述对应过程，和可能遇到的问题及解决办法以及对应的参考链接，并不会直接每一步详细配置
如果你想通过文字描述或代码画流程图，可以试试PlantUML，告诉GPT你的文件结构，让他给你对应的代码

预约挂号微服务模块搭建

1、构建父工程（yygh-parent）

在Maven的pom.xml中，<packaging>pom</packaging>指定了该项目的打包类型为 POM。这意味着这个项目是一个父项目或聚合项目，而不是一个可执行的JAR或WAR文件。

其作用是为了管理依赖版本以及公共依赖

通过Spring Initializr创建项目：添加依赖项

好处：

自动重启： 当你修改代码并保存文件时，DevTools 会自动重启应用，这样你不必手动重启服务，提高开发效率。
快速热部署： 在开发模式下，DevTools 允许快速查看代码更改的效果，无需每次都重新启动应用。
LiveReload： 与浏览器配合，实时刷新网页，方便前端开发。
增强配置元数据： 为你的配置类生成元数据，使得 IDE（如 IntelliJ IDEA）能够提供智能提示和代码补全功能。
类型安全的配置： 通过生成的元数据，确保配置项的类型和名称的正确性，避免常见的配置错误。

此处还会出现一个问题：创建好的springboot项目根本没有spring-boot-starter-parent

原因： 因为创建springboot工程的时候，使用的是阿里云提供的网址，初始化项目的时候，官网的采用的是继承的parent标签。而阿里云是直接通过引用依赖，所以看不到parent标签！(转自此处)

解决方案： 自行添加<parent>标签，记住，这里的版本一定要和你的spring-boot设置的版本一样

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.16</version>
</parent>

后续就是添加相关依赖，这里主要描述pom内标签的几个作用:

<parent> 标签在 Maven 项目中用于声明一个项目的父 POM（Project Object Model）。父 POM 提供了一组可以被子项目继承的配置和依赖，从而减少重复配置，简化多模块项目的管理。可以继承的包括:

依赖版本（通过 <dependencyManagement>）。
构建设置（通过 <build>
插件配置（通过 <pluginManagement>）
通用属性（通过 <properties>）

<dependencyManagement> 主要用于在父项目或父 POM 中定义依赖的版本和范围，但并不会将依赖自动引入子项目。子项目需要显式声明依赖项.
<dependencies> 标签用于直接声明项目中需要的依赖项。这些依赖会立即被添加到项目的构建路径中，并且在构建时自动下载和使用。

<properties> 标签，你可以定义一些全局的变量，如 Java 版本、字符编码、依赖的版本等，便于项目的统一配置和维护。

<build> 标签出现在 pom.xml 文件中，用于管理项目的构建配置包括：

项目编译、测试和打包的行为定义。
配置构建过程中的插件及其参数。
自定义项目输出的路径和文件名称等。

位于 <build> 标签下：

<pluginManagement>：用于为子项目或模块定义插件的默认配置。子项目要想使用这些插件，必须显式声明插件。它只管理插件，而不会在没有声明的情况下自动应用插件。
<plugins>：用于在当前项目或子项目中直接应用插件。这里声明的插件会自动应用，并参与项目的构建过程。
<plugin> ，用于定义和配置 Maven 插件。Maven 插件是一组可以在项目构建过程中执行的任务，例如编译、打包、测试等。通过插件，你可以扩展 Maven 的默认行为，或引入特定的功能。

2、搭建common父模块

在这里插入图片描述
在yygh-parent工程下创建子工程模块common，会遇到一个问题：找不到常规Maven模块创建,似乎只提供了Maven Archetype模版创建，其实是可以创建普通Maven模块的，在新建模块里。此处参考

添加依赖，对swagger依赖项进行说明

使用 Swagger 的功能:

生成 API 文档：通过注解生成自动化的 API 文档，无需手动编写。
在线测试：Swagger 提供可视化的接口文档页面，可以直接在页面上进行 API 请求测试。
代码生成：Swagger 可以根据文档生成多语言的客户端和服务端代码。

搭建common-util、service-util（common子模块）先统一安装对应依赖 (后续还有再补充)

3、搭建model、Service父模块

在这里插入图片描述

搭建过程如common，不再赘述。

4、Gitee使用

打开https://gitee.com/网址

点击创建仓库，选择是否开源、`仓库名称

复制gitee码云的Https连接类似于：https://gitee.com/xxxx/yygh_parent.git

创建本地仓库： 在Idea工具栏上方点击VCS -->创建Git仓库

建立远程仓库并上传代码步骤

第一步： 右键项目名称,在Git中点击管理远程，将之前复制的码云的URL粘贴，创建时，需要填写你码云的账号和密码。

这里要注意，注册账号时的用户名和这里的账号可能不一样，以https://gitee.com/xxxx/yygh_parent.git为准的话，账号就是xxxx，密码一样。

第二步： 右键项目名称，在Git中点击添加

第三步： Git ->提交目录，在打开的窗口中选择要上传到本地仓库的代码并添加注释后提交并推送到远程仓库中。

pull：首先从远程仓库获取最新的提交记录，再将远程仓库中的更新合并到本地当前分支。

commmit： 是将已添加到暂存区（staging area）的更改保存到本地仓库的历史记录中。提交的内容只在本地仓库中进行保存，并不会影响远程仓库。

push：是将本地仓库中的提交推送到远程仓库

在这里插入图片描述

5、医院设置需求

医院设置功能的主要作用是保存医院的基本信息，确保每个医院开通后可以参与后续的流程。

具体表结构:

字段名	描述	备注
`id`	编号	自增
`hosname`	医院名称
`hoscode`	医院编号（平台分配，全局唯一，API接口必填信息）
`api_url`	医院回调的基础URL（如：预约下单，调用该地址下单）
`sign_key`	双方API接口调用的签名Key，由平台生成
`contacts_name`	医院联系人姓名
`contacts_phone`	医院联系人手机
`status`	状态（锁定/解锁）	默认值：`0` ，`1`表示可用于连接
`create_time`	创建时间	默认值：`CURRENT_TIMESTAMP`
`update_time`	更新时间	默认值：`CURRENT_TIMESTAMP`，更新时修改
`is_deleted`	逻辑删除（1:已删除，0:未删除）	默认值：`0`

6、搭建医院模块service-hosp

第一步： 修改pom.xml，添加依赖

第二步： 添加配置文件application.properties设置数据库、Mapper等信息

其中配置mapper-locations是为了告诉 MyBatis-Plus 框架，在哪个路径下可以找到 XML 文件，这些文件定义了数据库操作的 SQL 语句。

第三步： 添加启动类，启动类模块统一在model模块创建

第四步: 添加Mapper接口，在Mapper接口继承BaseMapper时需要指定实体类(HospitalSet)，所以必须在pom.xml添加对model模块的依赖。最后并在Mapper文件夹下方创建xml文件夹，用于存储xml文件

        <dependency>
            <groupId>com.xxx</groupId>
            <artifactId>model</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

其中添加 mapper 接口是为了在 MyBatis 或 MyBatis-Plus 中定义与数据库的交互逻辑，它提供了将 Java 方法与 SQL 语句进行映射的机制。

第五步： 添加service接口及实现类

创建HospitalSetService接口(封装业务逻辑)，继承IService接口，它集成了一些通用的服务方法。[这里接口填泛型，填的是实体类HospitalSet]

实现该Service接口，并可以调用 Mapper 接口。

@Service
public class HospitalSetServiceImpl extends ServiceImpl<HospitalSetMapper, HospitalSet>implements HospitalSetService {
@Autowired
private HospitalSetMapper hospitalSetMapper;
}

ServiceImpl 是 MyBatis-Plus 提供的一个基础服务实现类，它已经封装好了常见的 CRUD（增删改查）操作，开发者只需继承这个类，就可以自动拥有这些基本功能，而无需每次都手动实现。

ServiceImpl 使用了两个泛型参数：

<M extends BaseMapper<T>, T> implements IService<T>

M（Mapper 类型）：表示对应的 Mapper 接口，通常继承自 BaseMapper。
T（实体类型）：表示对应的实体类，通常对应数据库中的某张表。

这里会不会有一个疑问：既然服务层实现类继承了serviceImpl，又继承了服务类接口，那为什么服务类接口还需要继承IService接口呢？

从 IService 继承的 CRUD 方法可以直接复用，避免在每个实现类中重复编写；可以在 Service 接口中定义额外的业务方法，使其不仅仅限于基本的 CRUD 操作；未来如果需要替换 ServiceImpl，只需要修改实现类，接口层不用动，保持系统的解耦。

第六步： 添加controller

这里介绍这两个注解：

@RestController:它的作用等同于 @Controller 和 @ResponseBody 的组合

@Controller：用于定义一个控制器类，用来接收和处理 HTTP 请求。
@ResponseBody：表示该方法的返回值直接作为 HTTP 响应体，而不是返回一个视图（如 JSP 页面）。通常用来返回 JSON、XML 等格式的数据。

@RequestMapping("/admin/hosp/hospitalSet") 表示这个控制器类处理所有以 /admin/hosp/hospitalSet 开头的请求路径。

这里我在运行配置类Main时，出现了一个报错：

java.lang.IllegalStateException: failed to req API:/nacos/v1/ns/instance after all servers([localhost:8848]) tried

这个错误表明 Spring Boot 应用在尝试连接 Nacos 服务时出现了 Connection refused 的错误。我的解决方法是，把关于nacos的依赖项先注释掉。

后续讨论如何在Controller中添加CRUD方法