有很多读者留言希望松哥能好好聊聊 Spring Data Jpa! 其实这个话题松哥以前零零散散的介绍过，在我的书里也有介绍过，但是在公众号中还没和大伙聊过，因此本文就和大家来仔细聊聊 Spring Data 和 Jpa!

1. from 子句是查询语句的必选子句。

2. select 用来指定查询返回的结果实体或实体的某些属性。

3. from 子句声明查询源实体类，并指定标识符变量（相当于SQL表的别名）。

4. 如果不希望返回重复实体，可使用关键字 distinct 修饰。select、from 都是 JPQL 的关键字，通常全大写或全小写，建议不要大小写混用。

• 一个是 Jpa 的事务

• 一个是配置 dao 的位置

1. 若我们定义的接口继承了 Repository, 则该接口会被 IOC 容器识别为一个 Repository Bean，进而纳入到 IOC 容器中，进而可以在该接口中定义满足一定规范的方法。

2. Spring Data可以让我们只定义接口，只要遵循 Spring Data 的规范，就无需写实现类。

• 涉及条件查询时，条件的属性用条件关键字连接，要注意的是：条件属性以首字母大写

• 支持属性的级联查询. 若当前类有符合条件的属性, 则优先使用, 而不使用级联属性. 若需要使用级联属性, 则属性之间使用 _ 进行连接.

1. 先判断 userDepUuid （根据 POJO 规范，首字母变为小写）是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，继续第二步；

2. 从右往左截取第一个大写字母开头的字符串(此处为 Uuid)，然后检查剩下的字符串是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，则重复第二步，继续从右往左截取；最后假设 user 为查询实体的一个属性；

3. 接着处理剩下部分（DepUuid），先判断 user 所对应的类型是否有depUuid属性，如果有，则表示该方法最终是根据 “ Doc.user.depUuid” 的取值进行查询；否则继续按照步骤 2 的规则从右往左截取，最终表示根据 “Doc.user.dep.uuid” 的值进行查询。

4. 还有一些特殊的参数：例如分页或排序的参数：

• 利用下标索引传参，索引参数如下所示，索引值从1开始，查询中 ”?X” 个数需要与方法定义的参数个数相一致，并且顺序也要一致：

• 命名参数（推荐）：这种方式可以定义好参数名，赋值时采用@Param(“参数名”)，而不用管顺序：

1. 方法的返回值应该是 int，表示更新语句所影响的行数

2. 在调用的地方必须加事务，没有事务不能正常执行

3. 默认情况下, Spring Data 的每个方法上有事务, 但都是一个只读事务. 他们不能完成修改操作

1. Spring Data 提供了默认的事务处理方式，即所有的查询均声明为只读事务。

2. 对于自定义的方法，如需改变 Spring Data 提供的事务默认方式，可以在方法上添加 @Transactional 注解。

3. 进行多个 Repository 操作时，也应该使它们在同一个事务中处理，按照分层架构的思想，这部分属于业务逻辑层，因此，需要在Service 层实现对多个 Repository 的调用，并在相应的方法上声明事务。

　　本来是想写js面向对象笔记（二）关于封装的，但是在敲实例代码的时候，发现对作用域这个东西的概念有点模糊，翻阅了犀牛后，有点感觉了，就想着先记录下此时的感受。

　　之所以取名叫做词法作用域，是这个概念是js中相当基础也是极为重要的，很多想当然的错误或感觉怪异的问题都是和这个东西有关。所以，本文主要说下这个名词的概念以及讨论下他牵扯出来的有关变量、函数、闭包的问题。

　　习惯性先来段代码：

　　代码很简单，首先定义了一个全局变量x并赋了初值，然后写了个getValue的方法，之后我们用alert弹出x的值，但是结果是undefined，不是global value也不是local value，这个我们可能会感觉到奇怪。其实理解这个问题的关键就是要清楚x的作用域。

　　第一个var x中的x是全局变量，说到这里顺带说下，js解释器在执行任何代码之前会先创建一个全局对象（global object），全局变量就是相当于这个全局对象的一个属性。同理，对于getValue这个函数，就会生成一个叫做调用对象的东西，局部变量就是这个调用对象的属性，例子中第二个var x中的x就是局部变量。

　　说了以上的东西其实是为了将本文的主角——词法作用域。这个是何方神圣呢？要理解的话，其实我们可以对比传统面向对象的（如JAVA、C#）中的变量的作用域，我们知道C#中的变量作用域是块级的，即这个变量只能活动在定义他的一个直接外界内，如if子句内，for子句内定义的变量外界是无法读取的。而js中呢，变量却不是这样的，在同一个函数内定义的变量其它的成员是可以访问的。看个例子会清楚很多：

　　清楚了这一点后，就来理解下js中关于词法作用域的含义。当定义了一个函数后，当前的作用域就会被保存下来，并且成为函数内部状态的一部分，这个是很重要的一个概念。下面我们回到开篇的那个例子，当getValue函数被定义的时候，他的作用域被保存起来，还有被加到作用域链上，他的上端就是全局执行环境。当调用getValue方法的时候，js解释器首先会把作用域设置为定义函数的时候的那个作用域（即之前保存那个），接下来，他在作用域的前加上调用对象即getValue这个函数，再在他的上端加上全局对象。晕了没?还是看下我画的图把：

　　这样比较清楚了把，这个作用域链其实和原型链有点相似，也好似在很作用域内找不到就会向上去找。比方说开篇那个例子，找x的时候，（对了这里要先介绍下js的预定义机制，就是js解释器会先对var定义的变量进行初始化，应该说只是起了定义的作用当没赋值)，会先在本作用域内找，有预定义知可以找到x，但是没赋值，所以是undefined值。知道了这点我们来知道开篇那个代码其实是等价于下面这个的：

　　实际上js解释器做的事情应该是按以上这个例子执行的，所以从另一个角度说，将变量的定义放在开头这个约定是有意义并且有益处的。

　　清楚了以上关于词法作用域的概念后，我们就不难理解闭包的概念了，他只是用到了作用域链的不可向下性（我取的名词..），即下面的作用域可以访问上面的，但上面的不可以访问下面的。当然这只是构成闭包的一个条件，闭包更重要的还是外部函数持有内部函数的一个嵌套函数的引用，由于闭包不是本文主要要讨论的（ps：谈封装的时候会说到），所以只是简单看下例子：

　　词法作用域的讨论就先这样了，我想说得是这个概念还是相当重要的。当然本文的内容也只是我针对书本介绍的自我的一些看法和理解，有不得当的地方希望各位指出，好了，回去睡觉了~

有很多读者留言希望松哥能好好聊聊 Spring Data Jpa!其实这个话题松哥以前零零散散的介绍过，在我的书里也有介绍过，但是在公众号中还没和大伙聊过，因此本文就和大家来仔细聊聊 Spring Data 和 Jpa!

MIT 为直到提交事务时才更新数据库记录。

1. from 子句是查询语句的必选子句。
2. select 用来指定查询返回的结果实体或实体的某些属性。
3. from 子句声明查询源实体类，并指定标识符变量（相当于SQL表的别名）。
4. 如果不希望返回重复实体，可使用关键字 distinct 修饰。select、from 都是 JPQL 的关键字，通常全大写或全小写，建议不要大小写混用。

其他方法的与此类似，这里不再赘述。

在 Spring Boot 中，Spring Data Jpa 官方封装了太多东西了，导致很多人用的时候不知道底层到底是怎么配置的，本文就和大伙来看看在手工的Spring环境下，Spring Data Jpa要怎么配置，配置完成后，用法和 Spring Boot 中的用法是一致的。

首先创建一个普通的Maven工程，并添加如下依赖：

接下来创建一个 User 实体类，创建方式参考 Jpa中实体类的创建方式，这里不再赘述。

这里和 Jpa 相关的配置主要是三个，一个是entityManagerFactory，一个是Jpa的事务，还有一个是配置dao的位置，配置完成后，就可以在 org.sang.dao 包下创建相应的 Repository 了，如下：

getUserById表示根据id去查询User对象，只要我们的方法名称符合类似的规范，就不需要写SQL，具体的规范一会来说。好了，接下来，创建 Service 和 Controller 来调用这个方法，如下：

这样，就可以查询到id为1的用户了。

首先来看 Repository 的一个继承关系图：

可以看到，实现类不少。那么到底如何理解 Repository 呢？

1. 若我们定义的接口继承了 Repository, 则该接口会被 IOC 容器识别为一个 Repository Bean，进而纳入到 IOC 容器中，进而可以在该接口中定义满足一定规范的方法。
2. Spring Data可以让我们只定义接口，只要遵循 Spring Data 的规范，就无需写实现类。

基础的 Repository 提供了最基本的数据访问功能，其几个子接口则扩展了一些功能，它的几个常用的实现类如下：

• 涉及条件查询时，条件的属性用条件关键字连接，要注意的是：条件属性以首字母大写

例如：定义一个 Entity 实体类：

使用And条件连接时，条件的属性名称与个数要与参数的位置与个数一一对应，如下：

• 支持属性的级联查询. 若当前类有符合条件的属性, 则优先使用, 而不使用级联属性. 若需要使用级联属性, 则属性之间使用 _ 进行连接.

1. 查询所有年龄小于90岁的人

1. 查询所有姓赵的、并且id大于50的人

1. 查询所有姓名中包含"上"字的人

1. 查询所有姓赵的或者年龄大于90岁的

1. 查询所有角色为1的用户

支持的查询关键字如下图：

为什么写上方法名，JPA就知道你想干嘛了呢？假如创建如下的查询：findByUserDepUuid()，框架在解析该方法时，首先剔除 findBy，然后对剩下的属性进行解析，假设查询实体为Doc：

1. 先判断 userDepUuid （根据 POJO 规范，首字母变为小写）是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，继续第二步；
2. 从右往左截取第一个大写字母开头的字符串(此处为Uuid)，然后检查剩下的字符串是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，则重复第二步，继续从右往左截取；最后假设 user 为查询实体的一个属性；
3. 接着处理剩下部分（DepUuid），先判断 user 所对应的类型是否有depUuid属性，如果有，则表示该方法最终是根据 “ Doc.user.depUuid” 的取值进行查询；否则继续按照步骤 2 的规则从右往左截取，最终表示根据 “Doc.user.dep.uuid” 的值进行查询。
4. 可能会存在一种特殊情况，比如 Doc包含一个 user 的属性，也有一个 userDep 属性，此时会存在混淆。可以明确在属性之间加上 “_” 以显式表达意图，比如 “findByUser_DepUuid()” 或者 “findByUserDep_uuid()”
5. 还有一些特殊的参数：例如分页或排序的参数：

有的时候，这里提供的查询关键字并不能满足我们的查询需求，这个时候就可以使用 @Query 关键字，来自定义查询 SQL，例如查询Id最大的User：

如果查询有参数的话，参数有两种不同的传递方式，

1. 利用下标索引传参，索引参数如下所示，索引值从1开始，查询中 ”?X” 个数需要与方法定义的参数个数相一致，并且顺序也要一致：

1. 命名参数（推荐）：这种方式可以定义好参数名，赋值时采用@Param(“参数名”)，而不用管顺序：

查询时候，也可以是使用原生的SQL查询，如下：

涉及到数据修改操作，可以使用 @Modifying 注解，@Query 与 @Modifying 这两个 annotation一起声明，可定义个性化更新操作，例如涉及某些字段更新时最为常用，示例如下：

1. 方法的返回值应该是 int，表示更新语句所影响的行数
2. 在调用的地方必须加事务，没有事务不能正常执行
3. 默认情况下, Spring Data 的每个方法上有事务, 但都是一个只读事务. 他们不能完成修改操作

说到这里，再来顺便说说Spring Data 中的事务问题：

1. Spring Data 提供了默认的事务处理方式，即所有的查询均声明为只读事务。
2. 对于自定义的方法，如需改变 Spring Data 提供的事务默认方式，可以在方法上添加 @Transactional 注解。
3. 进行多个 Repository 操作时，也应该使它们在同一个事务中处理，按照分层架构的思想，这部分属于业务逻辑层，因此，需要在Service 层实现对多个 Repository 的调用，并在相应的方法上声明事务。

好了，关于Spring Data Jpa 本文就先说这么多，这一块，松哥有一些私藏多年的笔记和视频，如下图：