java業務邏輯？

Java 業務邏輯，不同時期有不同的認識，同一時期針對不同的項目也有不同的處理方式。由于我從業6年以來，一直從事Java相關的應用研發，技術棧是基于Spring MVC 和Spring Boot，就以此項目結構，簡單談談在特殊處理方式之外的共用邏輯。

眾所周知，Spring MVC/Spring Boot項目，其目錄結構大致分為數據實體層（entity）、DAO層（mapper）、Service層、Controller層，而針對非前后端分離的項目，還存在View層，主要是一些jsp或thymeleaf等相關的頁面，View層 此層與控制層結合比較緊密，需要二者結合起來協同工發。而針對Java純Java部分的分層結構，簡單描述如下：

數據庫實體層:也被稱為entity層，pojo層，model層。一般數據庫一張表對應一個實體類，類屬性同表字段一一對應。

DAO層：DAO層主要是做數據持久層的工作，負責與數據庫進行聯絡的一些任務都封裝在此，DAO層的設計首先是設計DAO的接口，然后在Spring的配置文件中定義此接口的實現類，然后就可在模塊中調用此接口來進行數據業務的處理，而不用關心此接口的具體實現類是哪個類，顯得結構非常清晰，DAO層的數據源配置，以及有關數據庫連接的參數都在Spring的配置文件中進行配置。

Service層：Service層主要負責業務模塊的邏輯應用設計。同樣是首先設計接口，再設計其實現的類，接著再Spring的配置文件中配置其實現的關聯。這樣我們就可以在應用中調用Service接口來進行業務處理。Service層的業務實現，具體要調用到已定義的DAO層的接口，封裝Service層的業務邏輯有利于通用的業務邏輯的獨立性和重復利用性，程序顯得非常簡潔。

Controller層:Controller層負責具體的業務模塊流程的控制，在此層里面要調用Serice層的接口來控制業務流程，控制的配置也同樣是在Spring的配置文件里面進行，針對具體的業務流程，會有不同的控制器，我們具體的設計過程中可以將流程進行抽象歸納，設計出可以重復利用的子單元流程模塊，這樣不僅使程序結構變得清晰，也大大減少了代碼量。

DAO層，Service層這兩個層次都可以單獨開發，互相的耦合度很低，完全可以獨立進行，這樣的一種模式在開發大項目的過程中尤其有優勢，Controller，View層因為耦合度比較高，因而要結合在一起開發，但是也可以看作一個整體獨立于前兩個層進行開發。這樣，在層與層之前我們只需要知道接口的定義，調用接口即可完成所需要的邏輯單元應用，一切顯得非常清晰簡單。

Service層是建立在DAO層之上的，建立了DAO層后才可以建立Service層，而Service層又是在Controller層之下的，因而Service層應該既調用DAO層的接口，又要提供接口給Controller層的類來進行調用，它剛好處于一個中間層的位置。每個模型都有一個Service接口，每個接口分別封裝各自的業務處理方法。而一般來說，會將業務邏輯寫在Service層，使控制器層代碼保持整潔、清爽。而Service層承擔核心的業務邏輯，會出現調用多個Dao層情況，也會出現Service層互相調用的情況，在一定設計范圍內，這些都是正常的。有時也會出現一些特殊的業務邏輯，會需要單獨設置業務層進行處理，比如緩存層、策略層等。

作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。