一切都是最好的安排

前言接着上两篇（《通用Service》《通用树结构操作》）通用服务的功能，我们继续说下我们的第三篇，关于通用的属性服务，先来说说为什么会想着抽离这么个服务，想必工作时间久的开发人员肯定会遇到这种问题，随着业务的增长，会对原有业务表上增加各种字段，但是有的字段并不应该归属于主表上，而是应该放在其扩展属性表上，因为有些字段仅仅是主业务其中某一种特定业务才具有的（比如：在order表中，总是有一些并...

前言接上一篇文章中我们说了下怎么去做[《通用service》](https://blog.csdn.net/aiyaya_/article/details/79212852），来简化单表操作下的通用service层的逻辑，今天我们来接着讲解下通用的树表结构操作。思考首先我们先思考一下，通用的树结构操作都需要那些功能？ 对于树结构首先我们知道该表一定是一个自关联的，也就是需要一个关联自...

​前言目前网站上已经有很多关于如何去写restful风格的api的文章，主要说明下我接下来写的关于api写法的连载文章的目的，一个是主要把自己在这方面的心得分享给大家，二是希望大家也能给出更好的意见、建议，欢迎在看文章后讨论。本篇文章主要说下接口路径该怎么定义，一个URL地址的可读性对于调用者和维护者都是很重要的，当你规划好URL该怎么定义后，这也决定了java项目中你的contr...

前言 温馨提示：可以订阅我的微信公众号，在手机里看技术文档也很不错哦o(￣︶￣)o本篇文章主要说下接口的数据参数到底该如何接收，我们知道一个http请求最重要的意义就是将数据在服务器上进行传入与传出，本章主要讲的也就是传入。一次请求传递参数的方式主要有 URL路径中、请求头中、请求体中还有通过cookie等，下面我们分别对几种方式进行讲解。MediaType的选择MediaTyp

前言 温馨提示：可以订阅我的微信公众号，在手机里看技术文档也很不错哦o(￣︶￣)o！这是关于api基础写法的第三篇文章了，这里给下前两篇连接 《路径定义篇》 《参数接收篇》 ，对于本篇文章我们主要说下接口的数据返回值的问题。格式选择返回格式目前主流的应该只有XML、JSON两种吧，这里我们不做对比，我们使用JSON作为接口的返回格式。数据返回格式数据的返回格式其

跨域访问，简单来说就是 A 网站的 javascript 代码试图访问 B 网站，包括对后端数据的增删改查都会内引起。由于安全原因，浏览器统一遵循了一种策略，这个策略就是同源策略，同源策略也是浏览器最核心、最基本的安全功能。什么情况下会发生跨域？

前言在企业开发过程中，我们比较烦的也就是参数校验这一环节了，但是这一步又是不能省略掉的，我看过很多的企业开发者，他们对自己的接口参数校验都是很马虎的，以为校参这一步放在前端，后端校验就可以稍微省略很多了，其实是很错误的，我们打个比方，你的接口可能会被前端很多平台去调用，例如：ios、android、pc、web端， 如果某一端校验有检验遗漏的，就很可能导致后端接口因为参数传递的不合法导致500错误，

前言接下来这几篇文章中我们主要说说，在我们的项目中会使用哪些通用的功能，例如：通用Mapper（mybatis框架的）、通用service和分页功能等等，这些通用功能的使用会大大降低我们的开发时间，也会让我们的代码变得更加有规范更加合理，今天这篇文章我们说说怎么使用通用mapper。通用mapper简介通用mapper是一个国人编写的工具jar，它可以极其方便的做单表增删改查（使用

前言上一篇文章中我们说了下怎么去使用《通用Mapper》来实现对单表的增删改查功能，本篇我就带你学习下，如何使用PageHelper插件来实现对单表的分页功能，至此你就不需要再自己去写一大堆的mapper.xml代码去实现单表基础的功能了（其实我们绝大部分的业务都是基于单表操作的）。实现目标先来看一下我们约定的分页参数和响应结果的样子。 分页请求参数：localhost:

前言上两篇文章中我们说了下怎么去做《通用Mapper》和《通用分页》，来简化单表操作下的DAO层的逻辑，然而我们的目标仅仅是这样么？显然不是，本章为你讲解项目中通用的service的抽离，用于简化你的业务逻辑层，愿你能在其中得到启发和深入思考。思考首先我们先思考一下，对于SERVICE层有哪些是可以被公共出来的东西？ 好，我先来说几个： 1. 对于单张表的增、删、改、查（单条查

前言面向切面编程是spring里一种很不错的编程思想，简单来讲就是可以将一段功能代码在程序运行时，动态地将该段代码切入到目标方法前或后插入去执行，这种方式可以实现代码的可插拔性，之前我们在拦截器实战篇中说过的拦截器其实就是切面编程的一种实现。本篇文章我们将带你使用spring的@Aspect注解来实现controller层方法的请求参数、响应体的日志打印功能，这在企业开发中也是很有必要的哦

这篇文章是我们企业开发实战篇应用spring拦截器的第二篇文章，第一篇《解决跨域问题》，该篇文章我们主要讲解下如何使用拦截器+自定义注解来实现登录鉴权校验的功能，关于拦截器和自定义注解的基础语法下面也会稍带讲解，但不是本文重点，所以讲解的可能不会很细O(∩_∩)O。需求描述我们需要一个Java注解，使用这个注解标记在Controller的类或某个方法上时，就代表着该类下所有方法或某个注解标记的方法需

在前面的一些文章中我们有讲到，通过拦截器我们可以做很多的事情，包括接口的统一的 参数校验、 登录校验、权限校验等，也可以做一些HTTP响应体写入，比如我们另一篇文章所说的《解决跨域问题》，本篇我们也就是讲解下，使用拦截器统一校验一下，接口对外部开放时所需要的统一参数。下面我以我们实际开发中所遇到的问题，来举例说明。需求描述在对外开放接口的时候，我们的调用端是很多的，比如：APP/PC/WECHAT公

前言之前我们分享了对于spring项目的controller层，我们该如何简写我们的代码逻辑，所谓的简写就是 简化日志打印、参数校验、异常捕获和响应结果的封装这几个步骤，让我们把更多的时间留给我们更关注的业务逻辑，这里给一个之前的文章链接，读了过后可能你会更好的理解该篇文章的意义《Api写法第三篇》。 废话不多说了，我们看一下我们今天的主角儿，@ControllerAdvice注解，这个是spri

前言在之前的文章中我们有介绍过，如何更好、更简单的写好一个接口（接口返回值篇），今天的这篇文章我们主要介绍，怎么统一处理下接口的返回格式问题。问题分析我们先来分析下我们所面临的问题在哪里，然后接着给出解决方案。在写一个接口时，我们通常会先统一定义一下接口的返回格式是什么，然后在跟前端去对接，通常的返回格式大体两种(我们以保存用户为例)：1. 成功/失败响应格式不一致（此种方