zheng项目系统简单的分析记录

---

接下来是对整体分层的分析，这样才知道每次的调用顺序和每个模块之间做了什么，要承担什么任务。尽管给了一些说明，但是看得不习惯，还是自己上手操作比较的实际，印象深刻。每个不同的任何机构都有自己一套的内部代码规范和命名法则和层次结构的定义，但是基本的定义差别应该不是太大，下面进行一个简单的分析(每个模块进行简单的分析，umps的内容比较的多，主要对这个模块)：

模块整体的构造：

1. clien
2. common 不做介绍
3. dao
4. rpc-api
5. rpc-service
6. server
   

   也不是给的文档完全不看啊，看还是多多少少看一些的，不然当对来说会费尽一点（大牛可以完全忽略这些）

dao子模块的分析

这个模块相对来说比较的简单，也是我们新建一个模块的时候首先建立的一个子模块，这个模块主要是创建dao的，在这个dao层下面一般有最基本的实体和dao的接口，包涵基本的crud。其中当然也有framemarker的生成类，这个就不做过多的赘述了。这个同时我也有个疑问目前还没搞懂，为什么要生成example类，平时我是真的没用到过，很少去接触jpa的东西。

server

这个模块怎么说呢，给我最大直观的感受就是，这是一个没有实现类的Java Web工程。
1. webapp，很明显。
2. 这个模块的resources配置文件相对来说是比较多的，每个文件的作用这个这次不多探究。
3. 这个模块里面是主要做控制层的，你看嘛，controller层写里面好好的，主要负责参数的传递接收。
4. 当然了，这个模块用到了swaggerUi，其实就类似一个postman，对后端人员来说开发测试相对比较方便，地址：ip：port/swagger-ui.html

1. 但凡会一点开发的都知道基本的套路，先过一些过滤器，拦截器，然后到我们controller，做一些基本的数据处理，然后调用我们的service，好的此时我们就要用到我们的rpc-api模块的东西了

rpc-api

这个模块，简单总结一句话，全是接口（忽略mock（你要强调服务降级的话，那就加上吧），我大后端开发这么繁忙，还有时间给你前端写mock？自己mock去，呵呵）。为什么单独把这个模块的东西独立出来，就是把这接口暴露出来，用我们的dubbo，可以去看看server模块配置文件的dubbo-consumer的配置文件。

 
    <dubbo:reference id="upmsUserService" interface="com.zheng.upms.rpc.api.UpmsUserService" mock="true"/>

继续，接口，是接口的话当然就要去找它的实现类了，接下里就到了另一个模块:rpc-service

rpc-service

这个模块主要是两个包
1. dao.mapper
这个包里面很简单，就是存放我们的mapper.xml文件的，当然你也可以放在别的地方。
2. rpc
这里主要是service.impl,很明显了，impl，实现类。每个实现类都注入了许多的mapper（其实我更喜欢叫做dao，我是喜欢用，dao，daoImpl这种命名方式的），service里面来处理各种业务了，业务里面我们要用到不同的mapper,也就是用到我们dao模块的接口了。这个地方要注意一下，前后对应的东西，就是这里spring配置里面有一个dubbo-provide的配置文件，看见了吗？提供者，前面消费者，贴代码

 
    <bean id="upmsUserService" class="com.zheng.upms.rpc.service.impl.UpmsUserServiceImpl"/>
    <dubbo:service interface="com.zheng.upms.rpc.api.UpmsUserService" ref="upmsUserService" timeout="10000"/>

---

以上，只是一个简单的模块熟悉。还有spring和很多框架的结合使用，配置文件和对应的实现方法和作用，本次不多叙述。有写错的地方还望指出不足之处，经验资历尚浅，还望包涵。原项目地址

https://github.com/shuzheng/zheng