开始进行ruoyi框架的学习,比起其他的前后端不分离的,这个起码看的清晰一些吧。
这一节主要是看了ruoyi的官方文档后,记录了以下不懂的概念,并且整理了ruoyi框架中的相关内容。
store是状态管理库,用于管理前端应用程序(在浏览器中运行的Web应用程序)的状态。前端应用程序通常由多个组件组成,这些组件之间可能共享数据和状态,因此为了统一管理和共享状态,使用状态管理库来创建一个全局的store,存储应用程序的状态数据。
"store"存储了应用程序的各种状态,例如用户登录状态、页面内容、选项状态等。组件可以从"store"中获取状态数据,并且可以通过派发(dispatch)操作来触发状态的变化。变化后的状态将被存储在"store"中,并且会自动更新相关的组件。
通过使用"store",前端开发人员可以更好地组织和管理应用程序的状态,避免了状态分散和数据流混乱的问题。它提供了一种可预测和可维护的方式来处理状态变化,并使得状态在应用程序中的传递和共享更加简单和高效。
servlet用于在Web服务器上处理客户端请求和生成响应。servlet是一种服务器端的Java程序,主要用于开发动态的Java程序。Servlet主要用于处理Web请求和生成动态Web内容。它可以接收来自Web浏览器的请求,执行相应的任务,并将生成的结果发送回浏览器。Spring框架的核心是基于Servlet的,Spring框架提供了一个称为DispatcherServlet的前端控制器,它是一个特殊的Servlet,用于处理所有的Web请求。DispatcherServlet负责将传入的请求路由到相应的处理程序(也称为控制器),并处理视图渲染、数据绑定等任务。因此,Spring框架在Servlet的基础上提供了更高级的抽象和功能,使得开发Web应用程序更加方便和灵活。
Spring Security
是一个能够为基于Spring
的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
可以实现的功能:
Authentication
认证,就是用户登录Authorization
授权,判断用户拥有什么权限,可以访问什么资源session
攻击等spring security和shiro的关系:
jetty和tomcat一样,都是为基于java的web容器,比如JSP和Servlet提供运行环境。但是相比于tomcat,jetty要更轻量级一些,而且jetty更加灵活,体现在jetty的可插拔性和可扩展性,jetty提供了很多接口,可以通过这些接口进行进一步开发。但是在大规模的企业级应用时,jetty需要实现大量的扩展,在这种情况tomcat是更优的选择。
EL:Expression Language表达式语言。其作用是用于在JSP页面中获取数据,从而让我们的JSP脱离java代码块和JSP表达式。例如:在浏览器中输出请求域中名称为message的内容。(感觉这个就很像之前前后端不分离的时候,在前端渲染数据)
Spring3 中引入了 Spring 表达式语言 — Spring EL,SpEL 是一种强大,简洁的装配 Bean 的方式,它可以通过运行期间执行的表达式将值装配到我们的属性或构造函数当中,更可以调用 JDK 中提供的静态常量,获取外部 Properties 文件中的的配置。Spring EL中用的是#{},举个例子:
Spring Security允许开发者在定义接口访问的方法上面添加注解,控制访问权限。
@PreAuthorize
注解用于配置接口要求用户拥有某些权限才可访问,它拥有如下方法:
方法 |
参数 |
描述 |
hasPermi |
String |
验证用户是否具备某权限 |
lacksPermi |
String |
验证用户是否不具备某权限,与 hasPermi逻辑相反 |
hasAnyPermi |
String |
验证用户是否具有以下任意一个权限 |
hasRole |
String |
判断用户是否拥有某个角色 |
lacksRole |
String |
验证用户是否不具备某角色,与 isRole逻辑相反 |
hasAnyRoles |
String |
验证用户是否具有以下任意一个角色,多个逗号分隔 |
其中@ss
代表的是PermissionService(是ruoyi自定的权限服务)服务,对每个接口拦截并调用PermissionService
的对应方法判断接口调用者的权限。
数据权限示例:
角色权限示例:
如果某个接口不需要验证权限就可以访问,那么直接对这个接口的请求放行就可以。
但是我没有使用@Anonymous注解,只是把pre注解注释掉了也可以访问呢。因为如果这两个注解都不加的话,就相当于默认放行了。
坏了,如果用@Anonymous注解,那么一定得把@PreAuthorize注释掉啊,不然还是会进行权限控制的。因为@pre的优先级要比@ano的高一些。
@Transactional注解只能应用到public可见度的方法上,可以被应用于接口定义和接口方法,方法会覆盖类上面声明的事务。
实现事务管理比较简单,在类或者方法上添加@Transactional注解就行。
1.在Spring中进行事务管理的时候,默认的事务规则是遇到运行时异常(RuntimeException)或者程序错误(Error)才会回滚。所以如果想对其他的异常进行检查并事务回滚,可以使用rollbackFor属性明确指定异常。
2.在业务层捕捉完异常之后,不能直接处理异常,要把它抛出去,然后在控制层统一管理。如果在业务层直接处理了异常,那么Spring不知道你的事务到底有没有成功执行,怎么会对异常进行处理并回滚呢。
正确做法示例:
在实际开发中,如果我们在业务模块中使用try...catch...对异常进行捕获和处理,很容易造成代码的重复和繁杂。所以我们在业务中只保留业务相关的代码,在可能发生异常的方法里把异常throw给控制器,然后由全局异常处理器对异常统一管理。
步骤:
全局异常controller类的代码如下:
使用@Validate来校验数据,如果数据异常则统一抛出异常,方便全局异常处理器统一处理。
如果对于同一个字段在不同的方法中有不同的校验逻辑,可以通过groups属性设置,根据操作类型不同进行不同情况的校验。
在接口方法上添加@RepeatSubmit
注解即可,注解参数说明:
参数 |
类型 |
默认值 |
描述 |
interval |
int |
5000 |
间隔时间(ms),小于此时间视为重复提交 |
message |
String |
不允许重复提交,请稍后再试 |
提示消息 |
ruoyi里面封装了AjaxResult这个实体类,还以为这个类是和前端有什么特别的关系。原来就是一个继承了HashMap的子类,里面封装了error和success两个方法,负责在后端返回数据失败/成功时返回对应的处理结果。
在controller类上添加@ControllerAdvice或者@RestControllerAdvice,这两个注解的作用是差不多的,都是为了实现自定义的全局异常管理,加了这个注解的类就是一个全局异常控制类。
当自定义类加@ControllerAdvice注解时,方法需要返回json数据时,每个方法还需要添加@ResponseBody注解。
当自定义类加@RestControllerAdvice注解时,方法自动返回json数据,每个方法无需再添加@ResponseBody注解。
如果添加了相关注解之后,仍然不能捕捉到业务层抛出的全局异常并进行相应处理,可能是因为SpringBoot启动类没有扫描到这个异常处理类。如:启动类在“com.galen.cloud.portal”包下,那么只有com.galen.cloud.portal包下的类会被扫描加载)。所以添加上对应的scanBasePackages 即可(我这边改为扫描所有匹配com.galen.*的包)。