设备管理系统--课设项目.zip

## 设备管理系统的设计开发 ### 项目要求 Springboot+web+微信小程序设计实现  建议的体系结构:  项目要求:三人一组,最多 15 组采用该课题 ### 项目分析 主要角色：设备运维管理人员、维修人员、物业人员 主要对象：设备 对象设备的生命周期：新建--》安装--》保养/维修--》停用 #### 功能 1. 设备类，包括该类设备信息，包括常用名称、功能、场景。 2. 安装位置，安装地点、环境信息等 3. 设备组，选择设备类组，填写设备信息，如厂商名、购价、使用年限等，绑定默认保养计划 4. 设备，新建设备时，选择设备组，填写设备代码；安装设备时，选择安装位置、安装时间 5. 保养：保养计划，为每种设备组进行设置保养计划，可以针对不同安装位置的设备进行设置。保养计划也就是物业人员每隔多长时间进行检查。 6. 维修：由物业人员、管理人员提出维修任务，或者到达年限的设备会发送维修任务，维修人员收到后进行维修检查操作。 7. 停用：到达年限或者不可再用的设备，由管理人员设置不可用。 #### 环境 开发环境：Ubuntu 18.04+JDK 1.8+Maven 3.6+IntelliJ Idea 2018.3 运行环境：Ubuntu 18.04+JDK 1.8+Tomcat 9 使用技术: - Spring boot 2.2.2.REALSE：快速开发、开箱即用 - Mybatis 3.6：持久化框架 - Mybatis plus：简化数据库访问 - Spring MVC 5：MVC框架 - zxing：二维码生成 - lombok:注解开发 - swagger ui：Web API文档生成 - [easyExcel](https://alibaba-easyexcel.github.io/index.html):excel操作 数据库：H2(测试)+MySQL 8.0 ### 技术介绍 #### RESTful Roy Fielding博士在2000年他的博士论文中提出[REST](http://zh.wikipedia.org/wiki/REST)（Representational State Transfer，资源状态转移）风格的软件架构模式,是Web API 设计规范，用于 Web 数据接口的设计 RESTful架构是对MVC架构改进后所形成的一种架构，通过使用事先定义好的接口与不同的服务联系起来。在RESTful架构中，浏览器使用POST，DELETE，PUT和GET四种请求方式分别对指定的URL资源进行增删改查操作。因此，RESTful是通过URI实现对资源的管理及访问，具有扩展性强、结构清晰的特点。 RESTful架构将服务器分成前端服务器和后端服务器两部分，前端服务器为用户提供无模型的视图；后端服务器为前端服务器提供接口。浏览器向前端服务器请求视图，通过视图中包含的AJAX函数发起接口请求获取模型。 项目开发引入RESTful架构，利于团队并行开发。在RESTful架构中，将多数HTTP请求转移到前端服务器上，降低服务器的负荷，使视图获取后端模型失败也能呈现。但RESTful架构却不适用于所有的项目，当项目比较小时无需使用RESTful架构，项目变得更加复杂。 **主要原则** 1. 网络上的所有事物都被抽象为资源 2. 每个资源都有一个唯一的资源标识符 3. 同一个资源具有多种表现形式(xml,json等) 4. 对资源的各种操作不会改变资源标识符 5. 所有的操作都是无状态的 6. 符合REST原则的架构方式即可称为RESTful **特点** RESTFUL特点包括： 1. 每一个URI代表1种资源； 2. 客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源； 3. 通过操作资源的表现形式来操作资源； 4. 资源的表现形式是xml,json等； 5. 客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。 **举例** ``` /emps/ HTTP GET 查询所有的emp /emps/1 HTTP GET 查询id=1的emp /emps/1 HTTP DELETE 删除id=1的emp /emps/1 HTTP PUT 更新emp /emps/ HTTP POST 新增emp ``` #### 微服务 **架构**  1. 接入层 负载均衡作用，运维团队负责 2. 网关层 反向路由，安全验证，限流等 3. 业务服务层 基础服务和领域服务 4. 支撑服务层 5. 平台服务 6. 基础设施层 运维团队负责。（或者阿里云） **特点** 1. 一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可） 2. 独立的进程（java的tomcat，nodejs等） 3. 轻量级的通信（不是soap，是http协议） 4. 基于业务能力（类似用户服务，商品服务等等） 5. 独立部署（迭代速度快） 6. 无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择） **利** 1. 强模块边界 。（模块化的演化过程：类-->组件/类库（sdk）-->服务(service)，方式越来越灵活） 2. 可独立部署。 3. 技术多样性。 **弊** 1. 分布式复杂性。 2. 最终一致性。（各个服务的团队，数据也是分散式治理，会出现不一致的问题） 3. 运维复杂性。 4. 测试复杂性 ##### 分布式服务框架的发展 1. 第一代服务框架 代表：Dubbo(Java)、Orleans(.Net)等 特点：和语言绑定紧密 2. 第二代服务框架 代表：Spring Cloud等 现状：适合混合式开发（例如借助Steeltoe OSS可以让ASP.Net Core与Spring Cloud集成），正值当年 3. 第三代服务框架 代表：Service Mesh（服务网格） => 例如Service Fabric、lstio、Linkerd、Conduit等 现状：在快速发展中，更新迭代比较快 4. 未来（目测不久）主流的服务架构和技术栈  基础的云平台为微服务提供了资源能力（计算、存储和网络等），容器作为最小工作单元被Kubernetes调度和编排，Service Mesh（服务网格）管理微服务的服务通信，最后通过API Gateway向外暴露微服务的业务接口。 目前，很多大公司的项目组已经在采用这种技术架构了，服务网格采用的是Linkerd，容器编排采用的是K8S，Spring Cloud已经没用了。But，不代表Spring Cloud没有学习的意义，对于中小型项目团队，**Spring Cloud仍然是快速首选**。 #### Spring Boot Spring Boot 作为一套全新的框架，来源于 Spring 大家族，因此 Spring 所有具备的功能它都有，而且更容易使用；Spring Boot 以约定大于配置的核心思想，默认帮我们进行了很多设置，多数 Spring Boot 应用只需要很少的 Spring 配置。Spring Boot 开发了很多的应用集成包，支持绝大多数开源软件，让我们以很低的成本去集成其他主流开源软件。 **特性** - 使用 Spring 项目引导页面可以在几秒构建一个项目 - 方便对外输出各种形式的服务，如 REST API、WebSocket、Web、Streaming、Tasks - 非常简洁的安全策略集成 - 支持关系数据库和非关系数据库 - 支持运行期内嵌容器，如 Tomcat、Jetty - 强大的开发包，支持热启动 - 自动管理依赖 - 自带应用监控 - 支持各种 IED，如 IntelliJ IDEA 、NetBeans Spring Boot 的这些特性非常方便、快速构建独立的微服务。所以我们使用 Spring Boot 开发项目，会给我们传统开发带来非常大的便利度，可以说如果你使用过 Spring Boot 开发过项目，就不会再愿意以以前的方式去开发项目了。 **改进** - Spring Boot 使编码变简单，Spring Boot 提供了丰富的解决方案，快速集成各种解决方案提升开发效率。 - Spring Boot 使配置变简单，Spring Boot 提供了丰富的 Starters，集成主流开源产品往往只需要简单的配置�