首页 > 其他分享 >Spring关于bean的一些基本知识

Spring关于bean的一些基本知识

时间:2024-08-08 19:40:02浏览次数:14  
标签:顺序 spring 创建 基本知识 bean Spring 注解 注入

在spring这座大厦中,去除掉最底部的核心(core)组件,那么最重要的无疑是bean和bean工厂。

剩余是AOP、设计模式,更之上的就是各种组件:DATA,WEBMVC...

 

为了便于行文,这里把bean和bean工厂统称为bean。

bean英文的意思是豆子。为了符合它的实际作用,本人把bean翻译为“缓存对象实例”,但按照惯例,本文地方依然称为bean。

在本文中,bean主要指bean实例和bean工厂。

 

spring体系中的bean实际作用是创建和管理类实例,以便达成最核心的功能:提升创建效率,用空间换时间。

这也基本上是所有缓存的要义。

spring把bean玩出了花,基本上所有地方都会带上bean。

使用spring进行javaee开发,是无法绕过bean,也没有必要去绕过。

基于此,我们需要了解bean的一些基本知识,以便它能够为我们的应用开发服务。

注:由于我们现在已经基本不基于xml(或者非boot)的方式创建spring工程,所以以下内容不讨论古早的一些内容xml配置。

另外,本文的内容和例子是基于spring6.x+JDK17

 

 

如果仅仅是做应用开发,那么了解以下的知识,个人认为足矣:

1.bean工厂

通过这个,我们知道bean放在什么地方,可以用什么工具访问它们。

2.创建bean

掌握常见的几种创建/定义bean的方式,以便选择需要的途径,并在必要的时候可以读懂代码

3.注入bean

掌握几种注入bean的方式,从而更加灵活编码,并在必要的时候达成一些其它目的

4.生命周期

在必要的时候调整bean;在系统初始化后或者关闭前做一些必要的事情

5.作用范围与单例

除了单例bean,有时候想象不到其它作用范围还有什么用处;谨慎使用非单例

6.常见的注解

这些注解主要涵盖bean的定义、创建、作用范围和生命周期。基本上掌握了这个就能掌握bean的大部分知识。


1.bean工厂

如果您学过常见的设计模式,那么必然知道工厂是什么意思。 

没错,bean工厂就是那么设计的,只不过代码会稍微复杂一些些,但核心还是那样:利用java的map数据结构保存已经创建的对象实例,并有相关增删改查这些结构的

一些方法,以便程序可以访问这些数据结构中的bean。

以下是几个bean工厂的关键知识点:

1.1、没有必要创建多个bean工厂

spring没有强制阻止开发人员创建多个工厂,只不过在绝大部分的业务场景中,看不到创建多个工厂管理不同分类bean的必要性

如前,spring的核心价值在javaEE开发,或者某种程度上就是作为一个web应用开发框架。

当我们的大部分对象都是web有关的时候,那么把和web有关的bean放在一个工厂中,总体上好处多于坏处。

如果硬要自己再创建默认工厂之外的工厂也可以,典型的作用就是通过创建额外的应用上下文来创建一个新的bean工厂。

1.2、默认bean工厂

默认情况下,spring会创建一个org.springframework.beans.factory.support.DefaultListableBeanFactory工厂。

虽然前文说过bean工厂是按照工厂模式进行设计,但为了工业上可用,这个类还是提供了非常多的数据结构用于存储各种信息,并提供了

非常多的方法用于实现各种功能,其中一个典型的功能就是getBean。


1.3、应用上下文和bean工厂

在spring中(如果没有特别说明指的是springweb应用),bean工厂包含在应用上下文中。

这个上下文是org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext(如果是webFlux,应该不是这个)

这个上下文就会包含默认的那个bean工厂DefaultListableBeanFactory。

如下图(AnnotationConfigServletWebServerApplicationContext继承于GenericApplicationContext):

 

1.4、Aware接口

spring的Aware接口的目的在于注入一个bean对象,典型地主要是注入应用上下文或者bean工厂。

Aware接口有众多的继承者:


2.创建bean

spring有多种方式创建bean。注意这里指的是“创建”,或者说定义,不包含注入。

什么是创建?就是根据java类创建对应的实例,并把这个类实例放入到bean工厂中。

什么是注入,就是把bean实例作为另外一个实例的属性(属性赋值)。

总体上,可以把bean的创建分为两类:自动和手动。

  • 自动创建可以等同于通过注解创建
  • 手动创建,即通过编写代码创建

手动创建的方式相当罕见,基本上找不到这么做的业务场景或者理由。

当然,如果愿意找,也可以找到大把交我们如何手动创建的文章,以及使用到手动创建的例子。

只不过,我个人基本上不怎么赞成那么做,因为手动创建,基本上等同于否定bean存在的理由:帮用户管理实例、并顺便提升速度、适当减低内存使用。

如何通过注解创建bean,见后文“常见的注解"有关部分。

 

具体到bean的代码

顺便说下,关于代码规范的问题。 现在有部分公司的规范或者网络上部分所谓的规范提倡一个类或者一个方法不要超过多少行的。

看看spring的源码,不知道有多少没有严格遵循。 所以所谓不能太长应该只能是一个大概的标准,依然需要具体情况具体分析。

我个人反对把一个方法写得过短,因为现有的大部分高级语言在调用其他函数的时候,都需要压栈等一系列操作,而这意味着牺牲性能。

当然,我们也非常理解为什么有的组织会那么规定,主要是程序员的水平参差不齐,责任心有高有低,一刀切有时候是一种折衷的措施。

 

所以一个bean应该有多少行代码,不是有特定的限定,看具体情况和具体组织的要求。

3.注入bean

如前,注入bean,顾名思义,就是把bean实例作为一个组件(属性)塞进另外一个实例中,专业一点的说法就是赋值。

3.1注入方式

注入的方式并不多,常见的有:

  1. 注解注入-常见的注解见后文
  2. 方法注入-可以细分为构造注入和赋值方法注入(即所谓的setter注入)
  3. 工具类注入-即通过工具类获取bean,并设置有关实例的bean属性

 

总体而言,注解注入和工具类注入是最常见的方式。

通过注解注入是最推荐的方式,因为它简单,能够节约时间,也基本没有什么副作用。

工具类的注入,主要是为了解决非自动创建类实例的情况下,对bean的使用。

 

方法注入也不是一无是处,例如有以下3个主要好处:

  1. 可以享受方法注入的副作用--在方法中写一些其它代码,实现额外的目录
  2. 让代码不要充斥着bean注解
  3. 还有一个好处:便于迁移到非spring体系。

为了最后一个好处而放弃注解注入,无疑是十分荒唐的理由。但是有那么一些文章在鼓吹放弃autowired改为方法注入,不是很理解。

说白了,绝大部分项目开始启用spring之后,就不会想着迁移到其它体系中,所以这个理由是没有什么说服力的。

所以,我从来不鼓励使用方法注入,盖因为我所做的系统以应用开发巨多,也从来不会想着迁移到其它ioc框架。

 

理论上来说,遵循规则来设计代码是不错的。但要考虑到工程具体化问题,就不会那么严谨了,这和表设计不遵循第三范式类似的道理。

说白了,那样会浪费比较多的时间,而时间就意味着成本,虽然成本很多时候也不光是写代码造成的,甚至写代码有时候都不是造成成本

升高的主要原因。但是能省一点是一点。

 

当我们做项目的时候,项目总是存在生命周期(一般是5年左右,长的在10年左右),此外做项目意味着基本不需要考虑通用性,基于此,不会对项目的可迁移性

做特别的要求。另外说一句托大的话,做个业务系统,不会使用什么了不起的技术,现在绝大部分的中国IT企业不会想着那么干。

IT企业在资本家眼里就好比是建筑业、制造业一样,资本家在乎的是赚快钱,而不是创造一个伟大的企业。

所以,如果程序员知道如何适当设计service,那么就没有必要使用方法注入,大胆地使用Autowired来注入bean,只要不滥用即可。

虽然,不鼓励方法注入,但是基本的设计原则、设计模式、代码规范还是需要遵守的,从职业道德和本职需求出发,那应该是总体上最好的一个选择。

 

最后补充一点:在spring6.x中,构造函数注入是不需要Autowired,但赋值方法还是需要的。所以,网上现在巨多已经过时的知识,工程师们应该自己辨别。

示例:spring6.x构造函数注入,不用autowired

@Service
public class StudentService {
   private StudentDaoService stuDaoService;
   public StudentService(StudentDaoService stuDaoService) {
     this.stuDaoService = stuDaoService;
   }
   public Map<String,SchoolStudent> getAll(){
     return this.stuDaoService.get();
   }
}

3.2注入限定

一个类有多个实现的注入问题

注入的时候,默认情况下,bean工厂会根据类类型来查找,这就会产生一个问题:如果一个类(接口)有多个实现类(bean实例),那么应该怎么选择?

出现这种情况的时候的时候,可能会导致错误:Parameter 0 of method xxx required a single bean, but *** were found(方法注入)

或者是autowired注入的时候。

比较典型的情况在于我们采用多数据源的时候:Parameter 0 of method sqlSessionFactory in com.ruoyi.framework.config.db.MyBatisConfig required a single bean, but 3 were found

这是因为现在很多组件喜欢通过@Bean注解定义bean,这个注解可以通过方法注入方式注入bean。

由于某些原因,组件设计者不会在参数中使用qualifier之类的注解,所以一旦有多个实现类(bean)就会导致报错。

遇到这种情况有几种解决方式:

  • 定义bean的时候指定Primary注解从而定义一个主bean,这样bean工厂会选择主bean。这个是主要的解决方式,也是比较容易的方式。这种方式主要用于不可修改源头组件的情况。
  • 利用qualifier注解结合其它注解的name属性来指定需要注入的bean的名称,这多用于我们能决定bean名称的场景

3.3注入顺序

注入顺序在实际应用中很少用到,或者说主要是spring自己用到。

和顺序有关的注解包含:order,priority,后者是JSR250标准。

用了order,意味着你为一个接口定义了多个实现类(bean),并且需要注入一个对象集合。而order中的数字决定了诸如时候,bean在集合中的顺序,

序号越小越前,这是一种符合绝大分人习惯的约定。

可以随意地,方便地使用的注解,某些时候有助于实现一些相对灵活的功能,order注解就有这个作用。

spring通过这个注解,可以决定某些事件的发生顺序、aop执行顺序。

 

总而言之,order这样的注解主要是spring自用,用于注入一个指定顺序的集合,并靠集合元素的顺序来确定其它顺序。

而一般的业务开发中,我们比较少用到。当然如果要可以去模仿也是可以的。

// 接口
package study.example.school.service; public interface LearnService { public String getName(); public void learn(); }

//实现类1-LearnChineseServiceImpl
package study.example.school.service.impl; import org.springframework.core.annotation.Order; import org.springframework.stereotype.Service; import study.example.school.service.LearnService; @Order(1) @Service public class LearnChineseServiceImpl implements LearnService { @Override public String getName() { return "中文"; } @Override public void learn() { System.out.println("少读诗书陋汉唐"); } }
//实现类2-
LearnMathServiceImpl 
package study.example.school.service.impl; 
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Service;
import study.example.school.service.LearnService;
@Order(2) @Service
public class LearnMathServiceImpl implements LearnService {
@Override
public String getName() { return "数学"; }
@Override public void learn() { System.out.println("1+1=2;1-1=0"); }
}

//注入List<LearnService>的bean
@Service
public class StudentService {
private List<LearnService> learnServices;
@Autowired
public void setLeanServices(List<LearnService> learnServices) {
//这里可以加一些代码,例如 sysout打印参数,可以证明learnServices是按照order顺序排列的
this.learnServices = learnServices;
}
}

 

 

3.4循环引用

在spring6.x中,并不鼓励对象的循环应用。事实上,循环引用对于编码等方面是一些挑战,所以大部分的程序、组件并不鼓励循环应用,例如spring的bean、对象属性对自身类型的引用,

后者往往给序列化照成一些问题,而前者主要给编码造成问题。

spring有参数可以解决这个问题,通过系统参数spring.main.allow-circular-references= true

但是毫无疑问,循环引用的存在,给工程师照成了一些麻烦,并通常导致启动会慢一点点之类的问题。

所以,我们日常编码的时候,也尽量不要循环引用,如果不可避免,那么也无所谓,spring也能解决。

 

4.生命周期

大部分时候,我们并不会关注bean的生命周期,通常认为程序启动后bean就创建了,程序关闭时bean会随着工厂一起消失。

我们通常把bean当圆珠笔一样用,用的时候拿来写,不用了就放一边,不会特意关注放哪里,还在不在。

 

如果不是对资源的影响特别大,不会去考虑延迟加载等等一些事情。

 

但有两件事还是会稍微关注下:bean什么时候创建好/什么时候全部bean就绪;bean什么时候销毁/什么时候全部bean销毁

因为,我们常常会希望在某些bean就绪之后做一些初始化的操作,或者在bean销毁前释放特定的资源。

虽然有postConstruct/preDestroy这样的注解可以使用,但是当一个系统比较复杂的时候,我个人还是更喜欢基于spring的事件进行初始化或者。

例如基于ApplicationReadyEvent来进行集中的初始化,这样做能更好地控制执行顺序,其次更容易维护,不至于到处找和维护初始化代码。

当然,如果不用在于初始化顺序,用类似postContruct这样的注解做一些初始化也是可以的,毕竟现在的idea能够解决一部分维护问题。

同样地,通过ContextClosedEvent进行程序关闭前的一些操作。

 

表-和生命周期有关的一些接口、注解、事件

序号

名称

类型

作用

调用时机

注意事项

1

InstantiationAwareBeanPostProcessor

接口

可以做一些个性化初始化工作

有一些些作用

在bean初始化前后

bean的属性可能还没有初始化

2

BeanPostProcessor

接口

可以对bean实例做一些修改

其实作用不大

在bean创建前后(bean的属性已经完成)

不确认其中的两个方法是否接收的都是已经注入属性的bean,在测试用力中,是已经有属性值了。

3

ApplicationContextAwareProcessor

把实现了org.springframework.beans.factory.Aware接口的类中注入ConfigurableApplicationContext或者它的属性

只要有关类实现了Aware接口,那么在bean实例(有属性)创建后,调用

 

4

DestructionAwareBeanPostProcessor

接口

注销前做一些事情

在类注销前调用

 

5

postConstruct

注解

 

初始化之后

 

6

preDestroy

注解

 

销毁前

 

7

多个ware接口

接口

被ApplicationContextAwareProcessor处理,并注入一个上下文信息

大体是初始化后

 

8

org.springframework.context.ApplicationListener<E>

接口

应用事件,在特定情况下被触发。

例如可以在应用启动完毕,或者应用关闭前做一些操作

把需要做的事情统一起来,以便更好编码/管理等,而不是通过自动配置等一些复杂的方式来实现。

特定事件完成后

 

 

 


5.作用范围与单例

作用范围,英文SCOPE,和bean工厂一样,基本不会有什么人特别关注它。

在org.springframework.beans.factory.config.ConfigurableBeanFactory中定义了两个经典的作用域:singleton,prototype。

singleton(单项物、单个人)--国内通常翻译为单例,实际就是某个类只会在bean工厂中创建一个实例

prototype(原型、雏形)-不太清楚外国人用这个是什么意思,也许可以理解为”本样(用一个建一个)“,但国内意译为多例,因为实际效果就是注入一次,创建一个实例,注入10次就创建10个

后来还有一些乱七八糟的,类似多例的作用范围:request,session,application,global session

最后,spring还很贴心地提供了自定义作用范围的机制,虽然这个功能基本没人用,但还是要说spring的设计某些时候还是很贴心的:它尽可能地提供扩展性,想工程师所想。

 

然而,在绝大部分业务中,我们不会使用单例之外的作用范围,我个人也不鼓励使用类似多例的范围来管理某些bean。

为什么选择单例? 因为这样让设计更加简单,程序更不容易出错,也更容易维护。

其次,绝大部分的应用系统都是以处理业务数据为主,且不是基于互联网设计的,所以基本不用考虑性能的问题(极端性能),所以可以把很多数据一致性等的任务直接交给数据库,

较大地减轻了程序设计的难度。

 

使用单例的第一注意事项:不要定义类变量(除非这个变量仅仅是工具),数据总是通过参数来传递或者通过dao组件来处理。

基于这样的原则,万花丛中过,片叶不沾身,可以非常放心大胆地使用单例bean。

 

6.常见的注解

下表列出了spring和bean有关的常见注解:

序号

编码

名称

类别1

可独立使用

用于类

用于方法

用于属性

用于参数

来源

说明

1

@Component

组件

定义

 

 

 

 

 

2

@Repository

仓库

定义

 

 

 

 

Component特例,表示仓库、存储(数据)

3

@Controller

控制器

定义

 

 

 

 

Component特例,表示控制器(视图)

4

@Service

服务

定义

 

 

 

 

Component特例,表示业务

5

@Bean

组件实例

定义

是?

 

 

 

用于方法上定义一个Bean,通常需要和Configuration配合

特别注意:根据定义,Bean可以用于注解类型,但很少那么用。

6

@Configuration

配置

创建配置

 

 

 

 

表明当前类是配置,其次也会生成bean

7

@Import

导入配置

导入配置

 

 

 

 

通常和Configuration一起使用

8

@PropertySource

属性资源

创建属性

 

 

 

 

通常只能和Configuration一起使用

用于指定配置文件

9

@PropertySources

属性资源集

创建属性

 

 

 

 

通常只能和Configuration,PropertySources一起使用

用于指定配置文件

@PropertySources({

@PropertySource("classpath:application.properties"),  

    @PropertySource("classpath:custom.properties")  

})

10

@ConfigurationProperties

配置属性

创建属性

 

 

 

 

通常只能和Configuration一起使用

用于指定配置文件的一个部分

11

@Conditional

通用条件限定器

创建条件

 

 

 

根据条件生成bean,需要和Condition接口配合使用,后者提供条件的定义,当条件满足的时候,bean生成。

不能确认是否影响注入

12

@ConditionalOnMissingBean

不存在限定器

创建条件

 

 

 

基本同上,只是条件是不存在特定bean

13

@ConditionalOnxxxx

特定条件限定器

创建条件

 

 

 

同上

 

@DependsOn

依赖限定器

创建条件

 

 

 

确保当前Bean在其他Bean之后初始化,从而控制Bean的初始化顺序/加载顺序。

通常和生成bean的注解配合。

21

@Profile

配置限定器

创建条件

 

 

 

只有特定配置文件加载的时候才会生成或者注入bean。

需要和spring.profiles.active配合

通常和Configuration,Bean一起使用

22

@AutoConfigureAfter

后于自动配置识别

创建顺序

 

 

 

 

 

23

@AutoConfigureBefore

优先自动配置识别

创建顺序

 

 

 

 

 

24

@AutoConfigureBefore

 

创建顺序

 

 

 

 

 

25

@Scope

范围绑定标记

创建目标与范围

 

 

 

用于注解类上,

26

@Target

目标绑定标记

创建目标与范围

 

 

 

JAVA

用于注解类上,指定可用目标

27

@Lazy

延后指定

创建时机

 

 

 

延迟加载

只有被显示注入(用各种注解),或者使用Bean工厂的方法获取bean的时候会被创建。

 

28

@ComponentScan

组件扫描

创建扫描

 

 

 

 

 

29

@ComponentScans

组件集合扫描

创建扫描

 

 

 

 

 

30

@MapperScan

映射器扫描

创建扫描

 

 

 

Mybatis

 

31

@SpringBootApplication

应用启动

创建扫描

 

 

 

 

 

 

51

@Resource

资源

注入

 

JSR-250

Component特例,表示资源

52

@Resources

资源

注入

 

 

 

JSR-250

 

53

@Autowired

自动绑定

注入

 

如果用于方法,则会在初始化时候执行setter,会尝试自动注入来自于bean的参数

所以有时候也可以用执行一些初始化操作。不过个人不推荐。

理论上可以用于注入方法参数,但是不推荐。

特别注意:根据定义,Autowired可以用于注解类型,但很少那么用。

54

@Qualifier

名称限定器

注入限定

 

当一个接口有多个实现类(bean)的时候,用于指定特定的目标。可以通过bean名称来获取。

55

@Primary

优先限定器

注入限定

 

 

 

当一个接口有多个实现类(bean)的时候,用于指定主bean。

这样在需要自动注入的场景可以选择默认bean。

常常和Comonent,Bean一起使用

56

@Order

顺序指定

注入顺序

 

 

注入排列顺序.注意,不是创建顺序

所谓排列顺序,指的是被注入的顺序。

57

@Priority

顺序指定

注入顺序

 

JSR-250

注入顺序,非创建顺序

有点起到Primary的作用。主要用于注入单个的情况下起到作用

 

91

@PostConstruct

后置构建

弱相关-生命周期

 

 

 

java标准

在bean初始化之后执行

92

@PreDestroy

销毁前处理

弱相关-生命周期

 

 

 

java标准

在bean被销毁前执行

93

@Retention

持久性

弱相关-生命周期

 

 

 

 

元注解。用于指定其他注解的保留策略。保留策略决定了注解在何时何地是有效的

 

当然,这是所有bean相关注解的大部分,但不是所有,此外有些注解和版本有关系,所以如果在spring的某些过时版本看不到,也不要奇怪。

 

 

 

 

标签:顺序,spring,创建,基本知识,bean,Spring,注解,注入
From: https://www.cnblogs.com/lzfhope/p/18301755

相关文章

  • spring操作数据库
    xml版程序结构配置文件dbUtil-阿帕奇提供操作数据库的插件核心类:QueryRunner.query()查询.update()增删改<dependencies><!--spring--><dependency><groupId>org.springframework</groupId><artifactId>spri......
  • Spring Cloud微服务项目聚合Swagger文档
            在微服务架构中,每个服务通常都有自己独立的API文档。为了方便管理和查看所有服务的接口文档,我们需要将这些文档进行聚合。SpringCloud与Swagger的结合可以帮助我们实现这一目标。本文将介绍如何在SpringCloud微服务项目中聚合Swagger文档,以便于集中......
  • Springboot计算机毕业设计高校实验室管理系统(程序)
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表学生,教师,实验课程,课程打卡,实验报告,实验成绩,实验设备,耗材信息,耗材申请开题报告内容一、选题背景与意义1.选题背景随着高校教学科研水平的不断提升,实验......
  • Springboot计算机毕业设计高校实验室管理系统的设计与实现x1ir2
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表部门,教师,学生,实验室信息,学生预约,教师预约,耗材分类,耗材信息,耗材入库,学生领用,教师领用,学生借用,教师借用,学生归还,教师归还,购置计划开题报告内容一、......
  • Springboot计算机毕业设计高校女生的饮食营养管理系统(程序+源码+数据库+调试部署+开发
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表用户,个人食谱,特殊食谱,饮食类型,运动打卡,饮食登记开题报告内容一、研究背景与意义1.1研究背景随着社会经济的快速发展和人们生活水平的不断提高,人们对健康......
  • Springboot计算机毕业设计高校实验室仪器设备管理系统msvhp
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表用户,设备信息,设备分类,购置计划,报废申请,申请调拨,供应商,资产登记,采购入库,报废出库,调拨出库,公告信息开题报告内容一、选题背景与意义1.选题背景随着......
  • Springboot计算机毕业设计高校培养方案管理系统(程序+源码+数据库+调试部署+开发环境)
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表教务处,系部负责人,专业负责人,理论课程,教学安排,课程,教师信息,院系,年级,专业,班级,学生,实践课程开题报告内容一、研究背景与意义研究背景随着教育信息化......
  • Spring Boot集成Resilience4J实现限流/重试/隔离
    在现代分布式系统中,可靠性和弹性是至关重要的。Resilience4J是一个专注于提高应用程序弹性和容错能力的库,它提供了多种模式,包括限流(RateLimiter)、重试(Retry)和隔离(Bulkhead)。在这篇文章中,我们将探讨如何在SpringBoot中集成Resilience4J,并分别展示如何实现这三种模式。一、限......
  • Springboot整合Flowable入门-学习笔记
    目录1、定义流程(画图)2、Springboot部署流程3、Springboot删除所有流程4、Springboot根据流程部署ID查询流程定义ID5、Springboot启动(发起)流程6、Springboot查询任务6.1全部任务6.2我的任务(代办任务)7、springboot审批任务1、审批通过2、驳回8、Springboot流程......
  • Java毕业设计 基于Springboot+Vue的电影院剧院订票选座管理系统(源码+lw+部署文档+讲
    文末获取资源,收藏关注不迷路文章目录项目介绍功能需求技术介绍项目界面关键代码目录项目介绍随着经济的发展和信息技术的普及,国内许多企业都面临了重大的挑战。企业的管理流程、战略规划如果不能进行调整,极有可能面临淘汰的风险。特别是郑州大剧院,面对大量的会员和......