其实SpringDataJPA很方便,虽然他是重量级ORM框架,但是在SQL定制上一点都不输于Mybatis。

用@Query注解能使用QueryDsl语法。将nativeQuery属性设置为true就能使用原生SQL手写,也就是Mybatis一样的效果。

实现方式也挺简单的,DAO层接口继承一下CrudRepository就可以进行开发。看国内用的少,应该是因为比较新吧。

这是目前最新的官方文档,里边很多操作可以学习https://docs.spring.io/spring-data/jpa/docs/2.1.3.RELEASE/reference/html/

 

那么SpringDataJPA在代码中如何进行优雅的动态查询呢 ?

如何通过各种条件组装不同的SQL呢 ?

在复杂SQL中为了避免全表扫描要用函数代替某关键字要如何使用呢?

 

使用SpringDataJPA后,DAO层接口一般会继承JpaRepository接口,它可以提供大量供开发者使用的重载查询方法。

比如带Sort的findAll()方法可以按照指定列排序,带Pageable 的findAll()方法可以轻松地实现分页+排序的功能。

但是对于动态查询、复杂SQL来说还是少了。普通的复杂SQL,子查询左右连接啥的,大不了用@Query注解手写。

但是要再加上动态就不一样了。三个参数就会有七种查询方式(1/2/3/12/13/23/123)。总不能写七个方法定制吧。

莫慌,这个时候, JpaSpecificationExecutor 该接口应该就是所需要的了。

 

来看看 JpaSpecificationExecutor  接口自带的方法:

T findOne(Specification<T> spec);
List<T> findAll(Specification<T> spec);
Page<T> findAll(Specification<T> spec, Pageable pageable);
List<T> findAll(Specification<T> spec, Sort sort);
long count(Specification<T> spec);

 

 

最核心的就是 Specification 这个入参。

若想使用 JpaSpecificationExecutor  该接口的方法,则需要创建出实现了 Specification 的对象。然后将其作为查询条件才行。

这是Specification接口:

 

关于 toPredicate() 的几个核心参数 :

  • CriteriaQuery
    接口:该接口定义了顶级查询功能,它包含着查询到各个部分,如:select、from、where、group by、order by 等,CriteriaQuery 对象必须在实体类或嵌入式类型上才起作用
  • CriteriaBuilder
    类:它是 CriteriaQuery 的工厂类,用于构建 JPA 安全查询,可通过 EntityManager.getCriteriaBuilder 而得
  • Root
    接口:该接口继承了 From接口,From 接口继承了 Path 接口,该代表 Criteria 查询的根对象,定义了查询的实体类型,类似于 SQL 中的 FROM 子句,可有多个查询根
  • Predicate
    接口:代表了简单或复杂的查询断言(语句),一个 Predicate 可认为由多个连接词构成

 

这是我在公司写的一个model,可以接收前台用户输入的参数,然后通过一个getSpecification() 方法获取一个Specification实现。

之后该Specification即可作为入参进行 findAll() 的查询。

用来举例应是足够了。

我是用了一个lambda来实现 , 没用过JDK1.8以上版本的可以使用 new Specification 也是一样的。

 

可以看到我的标题匹配使用了mysql的 locate 函数,为的就是避免like关键字的效率低下。

再加上between and获取两个参数的区间,最后还带了一个in,  关键是这几个值都是动态的!若不满足条件则不会进行拼接!

若是该model的值全为默认, 通过这个get方法获取的 Specification 默认就变成一个 WHERE 1=1 的子句。

否则则会根据传入的值返回相应的表达。可以算是比较优雅了。

 

最后,以上边代码的

举个栗子,具体说明一下,这个Predicate是怎么得来的,代表了什么逻辑。

root.get(“title”) 表示为我查询的表(TaoBaoItem)中一个名为 title的列。

cb.locate() 代表使用mysql的 locate函数,它可以找出字符串中一个子串的位置/下标。

 

LOCATE(substr,str) :返回子串 substr 在字符串 str 中第一次出现的位置。如果子串 substr 在 str 中不存在,返回值为 0: 

 

 

cb.gt() 表示 > 符号,gt应该清楚,到处都能用到。第一个参数我填入LOCATE函数,第二个写了个0。

这个Predicate若是以sql的形式表示出来,则是这样子的:

 

这么一举例大概就明白了⑧ , Specification 来定制 sql 确实是好用啊。

 

 

 

 

阅读全文

 

又到了我第二喜欢的玩反射时间了。真快乐啊。

如标题所说,我写了个权限控制。权限控制的精髓就是限制用户访问范围。一个系统,总得有后台、管理者这些绕不开的玩意儿。

还有用户所代表的各种不同角色,如游客、登陆者、管理员、代理商、作者、编辑,等等等等。他们这些角色在一个庞大的系统里能够操作的地方总归是不同的。

如果单单依赖前端的权限控制,难免会被人家利用抓包之类的手段获取其他角色能操作的区域信息来做一些危险操作。

后端的权限控制是必不可少的,当然,在java领域现在SpringSecurity、shiro之类的安全框架肯定是一个优选,我很久之前也写过关于SpringSecurity的配置,可见: Spring Security集成以及配置

但是我就是tm要自己写一个,哎嘿嘿,(⁄ ⁄•⁄ω⁄•⁄ ⁄)

 

咳咳,关于我写的这个权限控制,我自己感觉还是特别骚的。亲自试了两天,确实没什么问题。我需要它能够做它确实做到了。

下面详细解释一下。

这个注解,是关键。里面有一个内部枚举,与其息息相关。注解的唯一一个参数就是该枚举。

@Impower 注解代表需要控制

Level 枚举表示控制范围

 

实现的效果就是:在上(Controller层的)写入该@Impower 注解,例如: @Impower(level = Impower.Level.Admin) ,那么,即代表该类需要权限控制,并且只有 Admin 这个角色,或者比Admin角色权限更高的角色 ,才能够请求该类中的方法。

如果在方法上加入该@Impower 注解,如果@Impower同时存在类上,外部请求该方法时,则会无视类注解,按照方法上该注解来进行判定权限是否能够访问。

Level 枚举内部的权限可自己随意定义,只要保证其权限范围顺序从左到右、从上到下线性递减即可。

注:系统的用户必须有一个属性是以Impower . Level 作为其类型。才能够进行权限控制。

 

前后端均可使用,前台可通过thymeleaf、freemark等模板来对用户显示进行控制,若是前后端分离的项目也没事,请求后台的时候做一下check()判定就好了。

并且想修改非常方便,这已经很极限的做到了降低耦合。想要增加不同的权限也好、修改某些方法可访问的权限也好、前台对权限的控制也好。有变更只需要更改很小的地方。

 

 

这儿是具体进行权限判定、从而决定是否放行的拦截器,关于SpringBoot的拦截器配置,若有不清楚的地方可看我之前写过的文章:

SpringBoot使用WebMvcConfigurerAdapter+HandlerInterceptorAdapter实现拦截

 

这里我对基本只会验证是否登录的拦截器做了拓展,获取了该请求所请求的类、方法上的注解,从而通过Session中的已登录对象来进行判定权限是否能够访问。

会使用Level  中的 check() 方法来进行判定该登陆角色的权限是否能够通过。

若通过判定,则成功访问该页面(能够正常请求响应),若判定失败,则请求失败,但是response状态码仍然会是200,只不过返回的内容是空罢了。

 

又写了一些骚东西,别的不嗦,我这玩意写出来还真挺好用的。实际体感顺滑流畅,代码优雅,功能简洁却强悍。

但是后端的权限控制可不止这么点哦,最好与JWT(JSON Web Token)进行同步使用,我本来也想自个写个Token验证之类的玩玩,妈耶想起来是有点麻烦,还是算了,我还是挺懒得。

阅读全文

虽然网上说 WebMvcConfigurerAdapter 已经过时了,但是我看我的 SpringBoot 里用的还是好好的。

而且这个确实也比较容易理解,比较简单。可以很轻易的实现拦截、过滤功能。

如下是我写的一个登陆拦截的例子,只有在 session 域中 adminUser 该 key 下有值的话才会跳转到能够登陆的页面

我这拦截的是所有路径,对登录页和登陆的登陆验证ajax请求做了开放。即除登陆也页以外所有页面都需要登录才能进入,不然就跳转到登录页。

我代码注释还是写的很清晰的。应该算便于理解

 

 

阅读全文

弹框宽高自适应,核心代码

 

阅读全文

 

今天在公司做了个功能,需要点击某【快速设置】的不同选择,然后根据选中不同其底下功能的: 单选、复选、下拉列表按钮也会动态的进行变更,以便用户操作。

在使用 JQuery 时,自然就用了我平时最常使用的 attr() 方法,本来也没什么问题,点击事件无误,页面该显示的数据都显示了。

但是当我点击别的选项时,或者修改了一些输入框、单选框之类的东西时。再次点击快速设置的按钮则不能初始化,这让我感到很惊奇。

 

一番查询。

原因是 JQuery 在 1.6 版本之后修改了部分代码,在这些情况下应该使用 prop,1.6 之前的应该是没问题的

1.添加属性名称该属性就会生效应该使用prop();
2.是有true,false两个属性使用prop();
3.其他则使用attr();

 

 

附上几个常见的 JQuery 对页面选项进行修改的操作

 

阅读全文
EA PLAYER &

历史记录 [ 注意:部分数据仅限于当前浏览器 ]清空

      00:00/00:00