接下來是對整體分層的分析，這樣才知道每次的調用順序和每個模塊之間做了什么，要承擔什么任務。盡管給了一些說明，但是看得不習慣，還是自己上手操作比較的實際，印象深刻。每個不同的任何機構都有自己一套的內部代碼規范和命名法則和層次結構的定義，但是基本的定義差別應該不是太大，下面進行一個簡單的分析(每個模塊進行簡單的分析，umps的內容比較的多，主要對這個模塊)：

模塊整體的構造：

clien

common 不做介紹

dao

rpc-api

rpc-service

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

但凡會一點開發的都知道基本的套路，先過一些過濾器，攔截器，然后到我們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"/>

• 1
• 2
• 3

繼續，接口，是接口的話當然就要去找它的實現類了，接下里就到了另一個模塊: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"/>

• 1
• 2
• 3

---

以上，只是一個簡單的模塊熟悉。還有spring和很多框架的結合使用，配置文件和對應的實現方法和作用，本次不多敘述。有寫錯的地方還望指出不足之處，經驗資歷尚淺，還望包涵。原項目地址

https://github.com/shuzheng/zheng

總結

以上是生活随笔為你收集整理的zheng项目系统简单的分析记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。