简单理解Repository层、Service层、Controller层

        最近感觉项目越写越乱了，人多的项目是不是大多都会发展成这个样子……一开始预想的很好，架构设计也都是分离开的，但是随着原来越多的人加入到项目中，代码能力层次不齐，又没有一个很好的讲解，当项目功能越来越多项目越来越庞大的时候，很多文件里面的代码就越来越不具备可读性，一大堆的冗余不说，有时候光是读一个方法跟一段业务逻辑都要读上几个小时还要找来几个写下代码的人经过几次的拔头发才能捋清楚

        突然就想，针对手头项目开发、维护过程中最长用上的几个部分分层以最简单的理念讲一下什么东西应该写在什么地方。。。

        （写代码这个事情，真的不是只要代码能跑起来就算完了的(╯‵□′)╯︵┻━┻）

        有时候我们的程序很简单，只想接收用户的两个传入参数X和Y，然后将他们相加返回给用户就好了，所以我们可以很简单的只需要在控制器里返回X+Y。

        但大多数情况下，我们面对的开发需求不会有这么简单明显，我们往往需要分很多步骤来得到一个结果，而在得到这个结果的每一个步骤中所产生的的结果我们都需要把它记录下来。

        这时候我们就面临了——用户输入X，经过业务逻辑一番操作之后，返回得到Y，用户再次输入Z，让上一次操作得到的Y和当前的Z进行一番操作以后，再返回I。。。最后得到一个最终的ret。

        这么一来，我们的控制器中便有了用户输入X的方法，保存Y的方法，用户输入Z的方法，获取Y的方法，Y和Z组合的方法。。。

        当所有的工作都在控制器中完成的时候，我们会发现，这个控制器变得越来越臃肿，结构不清晰，难以维护，甚至影响阅读。

        于是我们引入了仓储层——Repository

        Repository在我的理解，就是把需要固化数据的部分从常规的业务逻辑中分离出来，让控制器方可以专注于业务功能的处理，当控制器需要保存Y的时候，它通知Repository，于是Y就被保存了，当控制器需要使用Y时，它询问Repository，于是就能直接得到Y了，具体存储的过程以及查询的过程，控制器不需要知道。

        这么一来，我们的控制器因为不需要再考虑数据的部分了，看起来就更干净一些了，仓储部分因为也一心只管着数据的增删改查，所以内容也可以非常清晰。

        后来我们把功能上线了，然后我们会发现，在实际的生产过程中，逻辑往往不是简单的，用户输入X我们就能生成Y然后存储起来的，有时候用户可能输入的是A，或者B。

        这时候我们就会想到，既然不希望用户输入X以外的内容，那我们在用户输入以后进行验证不就好了，既然不想保存除了Y以外的内容，一样的在保存之前进行一下验证不就好了嘛。

        于是我们在控制器中又增加了一大堆的验证信息，验证用户输入信息的合法性，验证存储数据的一致性等等。

        这个时候再回头看发现，原本经过我们分离以后的控制器部分，有一次变得臃肿起来了，就好像我原本自己开店，需要我做前台迎宾，还需要我负责做饭，等我找了个人帮我做饭，感觉可以专注于迎宾这个事情以后，我发现自己除了迎宾以外，还需要去上菜。

        于是我们引入了服务层——service

        在我的理解中，不需要控制器去关注的也不属于固化数据的部分，就可以在这个环节去完成。当控制器完成了业务操作需要保存Y的时候，控制器只需要告诉服务层需要保存了，然后控制器就甩手了，服务层开始接手去验证数据的有效性合法性一致性等等问题，验证通过了就通知仓储准备保存数据，验证不通过就告诉控制器不能保存。于是我们的控制层、服务层、仓储层就变成了各自只专注于自己的事务，相互独立，清晰明了的不同结构。

        所以，并不是控制器里不能写数据的存储，也不是仓储层里不能写复杂的业务逻辑，当各个部分只专注于自己的事务时，我们能更好的阅读代码，能更快的定位问题，能更小成本的做局部调整，而不用面对一大批项目代码挨个点开去逐行逐个去读去查询一个方法的具体实现逻辑。