導讀
查爾斯·狄更斯在《雙城記》中寫道：“這是一個最好的時代，也是一個最壞的時代。”
移動網際網路的快速發展，出現了許多新機遇，很多創業者伺機而動；随着行業競争加劇，網際網路紅利逐漸消失，很多創業公司九死一生。筆者在初創公司摸爬滾打數年，接觸了各式各樣的 Java 微服務架構，從中獲得了一些優秀的理念，但也發現了一些不合理的現象。現在，筆者總結了一些創業公司存在的 Java 服務端亂象，并嘗試性地給出了一些不成熟的建議。
常見的 Controller 基類如下：
常見的 Controller 基類主要包含注入服務、靜态常量和靜态函數等，便于所有的Controller 繼承它，并在函數中可以直接使用這些資源。
常見的 Service 基類如下：
常見的 Service 基類主要包括注入 DAO、注入服務、注入參數、靜态常量、服務函數、靜态函數等，便于所有的 Service 繼承它，并在函數中可以直接使用這些資源。
首先，了解一下裡氏替換原則：
裡氏代換原則（Liskov Substitution Principle，簡稱LSP）：所有引用基類（父類）的地方必須能透明地使用其子類的對象。
其次，了解一下基類的優點：
子類擁有父類的所有方法和屬性，進而減少了建立子類的工作量；
提高了代碼的重用性，子類擁有父類的所有功能；
提高了代碼的擴充性，子類可以添加自己的功能。
是以，我們可以得出以下結論：
Controller 基類和 Service 基類在整個項目中并沒有直接被使用，也就沒有可使用其子類替換基類的場景，是以不滿足裡氏替換原則；
Controller 基類和 Service 基類并沒有抽象接口函數或虛函數，即所有繼承基類的子類間沒有相關共性，直接導緻在項目中仍然使用的是子類；
Controller 基類和 Service 基類隻關注了重用性，即子類能夠輕松使用基類的注入DAO、注入服務、注入參數、靜态常量、服務函數、靜态函數等資源。但是，忽略了這些資源的必要性，即這些資源并不是子類所必須的，反而給子類帶來了加載時的性能損耗。
綜上所述，Controller 基類和 Service 基類隻是一個雜湊類，并不是一個真正意義上的基類，需要進行拆分。
由于 Service 基類比 Controller 基類更典型，本文以 Service 基類舉例說明如何來拆分“基類”。
根據“使用即引入、無用則删除”原則，在需要使用的實作類中注入需要使用的DAO、服務和參數。
對于靜态常量，可以把它們封裝到對應的常量類中，在需要時直接使用即可。
對于服務函數，可以把它們封裝到對應的服務類中。在别的服務類使用時，可以注入該服務類執行個體，然後通過執行個體調用服務函數。
對于靜态函數，可以把它們封裝到對應的工具類中，在需要時直接使用即可。
2.1.現象描述
我們會經常會在 Controller 類中看到這樣的代碼：
編寫人員給出的理由是：一個簡單的接口函數，這麼寫也能滿足需求，沒有必要去封裝成一個服務函數。
案例代碼如下：
通路結果如下：
為什麼參數systemName（系統名稱）沒有被注入值？《Spring Documentation》給出的解釋是：
Note that actual processing of the @Value annotation is performed by a BeanPostProcessor. BeanPostProcessor interfaces are scoped per-container. This is only relevant if you are using container hierarchies. If you define a BeanPostProcessor in one container, it will only do its work on the beans in that container. Beans that are defined in one container are not post-processed by a BeanPostProcessor in another container, even if both containers are part of the same hierarchy.
意思是說：@Value是通過BeanPostProcessor來處理的，而WebApplicationContex和ApplicationContext是單獨處理的，是以WebApplicationContex 不能使用父容器的屬性值。
是以，Controller 不滿足 Service 的需求，不要把業務代碼寫在 Controller 類中。
SpringMVC 服務端采用經典的三層架構，即表現層、業務層、持久層，分别采用@Controller、@Service、@Repository進行類注解。
表現層（Presentation）：又稱控制層（Controller），負責接收用戶端請求，并向用戶端響應結果，通常采用HTTP協定。
業務層（Business）：又稱服務層（Service），負責業務相關邏輯處理，按照功能分為服務、作業等。
持久層（Persistence）：又稱倉庫層（Repository），負責資料的持久化，用于業務層通路緩存和資料庫。
是以，把業務代碼寫入到Controller類中，是不符合SpringMVC服務端三層架構規範的。
把持久層代碼寫在 Service 中，從功能上來看并沒有什麼問題，這也是很多人欣然接受的原因。
業務層和持久層混雜在一起，不符合SpringMVC服務端三層架構規範；
在業務邏輯中組裝語句、主鍵等，增加了業務邏輯的複雜度；
在業務邏輯中直接使用第三方中間件，不便于第三方持久化中間件的替換；
同一對象的持久層代碼分散在各個業務邏輯中，背離了面對對象的程式設計思想；
在寫單元測試用例時，無法對持久層接口函數直接測試。
戳一下上面軟廣，支援開源君的日常推文！
這裡以資料庫持久化中間件 Hibernate 的直接查詢為例。
阿裡的 AliGenerator 是一款基于 MyBatis Generator 改造的 DAO 層代碼自動生成工具。利用 AliGenerator 生成的代碼，在執行複雜查詢的時候，需要在業務代碼中組裝查詢條件，使業務代碼顯得特别臃腫。
個人不喜歡用 DAO 層代碼生成插件，更喜歡用原汁原味的 MyBatis XML 映射，主要原因如下：
會在項目中導入一些不符合規範的代碼；
隻需要進行一個簡單查詢，也需要導入一整套複雜代碼；
進行複雜查詢時，拼裝條件的代碼複雜且不直覺，不如在XML中直接編寫SQL語句；
變更表格後需要重新生成代碼并進行覆寫，可能會不小心删除自定義函數。
當然，既然選擇了使用 DAO 層代碼生成插件，在享受便利的同時也應該接受插件的缺點。
把一個 Redis 對象相關操作接口封裝為一個 DAO 類，符合面對對象的程式設計思想，也符合 SpringMVC 服務端三層架構規範，更便于代碼的管理和維護。
上面的代碼，看上去是滿足 SpringMVC 服務端三層架構的，唯一的問題就是把資料庫模型類 UserDO 直接暴露給了外部接口。
存在問題：
間接暴露資料庫表格設計，給競争對手競品分析帶來友善；
如果資料庫查詢不做字段限制，會導緻接口資料龐大，浪費使用者的寶貴流量；
如果資料庫查詢不做字段限制，容易把敏感字段暴露給接口，導緻出現資料的安全問題；
如果資料庫模型類不能滿足接口需求，需要在資料庫模型類中添加别的字段，導緻資料庫模型類跟資料庫字段不比對問題；
如果沒有維護好接口文檔，通過閱讀代碼是無法分辨出資料庫模型類中哪些字段是接口使用的，導緻代碼的可維護性變差。
解決方案：
從管理制度上要求資料庫和接口的模型類完全獨立；
從項目結構上限制開發人員把資料庫模型類暴露給接口。
下面，将介紹如何更科學地搭建 Java 項目，有效地限制開發人員把資料庫模型類暴露給接口。
共用模型的項目搭建，把所有模型類放在一個模型項目（example-model）中，其它項目（example-repository、example-service、example-website）都依賴該模型項目，關系圖如下：
風險：表現層項目（example-webapp）可以調用業務層項目（example-service）中的任意服務函數，甚至于越過業務層直接調用持久層項目（example-repository）的DAO函數。
模型分離的項目搭建，單獨搭建API項目（example-api），抽象出對外接口及其模型VO類。業務層項目（example-service）實作了這些接口，并向表現層項目（example-webapp）提供服務。表現層項目（example-webapp）隻調用API項目（example-api）定義的服務接口。
風險：表現層項目（example-webapp）仍然可以調用業務層項目（example-service）提供的内部服務函數和持久層項目（example-repository）的DAO函數。為了避免這種情況，隻好管理制度上要求表現層項目（example-webapp）隻能調用API項目（example-api）定義的服務接口函數。
服務化的項目搭，就是把業務層項目（example-service）和持久層項目（example-repository）通過 Dubbo 項目（example-dubbo）打包成一個服務，向業務層項目（example-webapp）或其它業務項目（other-service）提供API項目（example-api）中定義的接口函數。
說明：Dubbo 項目（example-dubbo）隻釋出 API 項目（example-api）中定義的服務接口，保證了資料庫模型無法暴露。業務層項目（example-webapp）或其它業務項目（other-service）隻依賴了 API 項目（example-api），隻能調用該項目中定義的服務接口。
如果從SpringMVC服務端三層架構來說，這是不允許的，因為它會影響三層架構的獨立性。但是，如果從快速疊代開發來說，這是允許的，因為它并不會暴露資料庫模型類。是以，這是一條不太建議的建議。