文章目錄

• • Java進階 三層架構
  • • • 1、三層架構是什麼？
      • 2、為什麼要用三層架構？
      • 3、三層架構怎麼用？
      • 4、 執行個體測試

Java進階 三層架構

三層架構是我們沒有接觸過的新知識，那麼我們在學習它的時候，就應該和之前學習其他内容一樣，從以下四個方面去了解學習它：

1. 三層架構是什麼？
2. 為什麼要用三層架構？
3. 三層架構怎麼用？
4. 執行個體測試

1、三層架構是什麼？

首先我們要明白三層架構的内容有哪些。官方的解釋是三層架構就是為了符合“高内聚，低耦合”思想，把各個功能子產品劃分為表示層（UI）、業務邏輯層（BLL）和資料通路層（DAL）三層架構，各層之間采用接口互相通路，并通過對象模型的實體類（Model）作為資料傳遞的載體，不同的對象模型的實體類一般對應于資料庫的不同表，實體類的屬性與資料庫表的字段名一緻。

官方給的解釋其實也并不難了解，我們在開發一個完整的功能子產品的時候，肯定會有使用者界面，根據使用者的選擇實作不同的代碼邏輯，而邏輯處理往往大部分都是在和資料庫打交道，需要對資料進行增删改查。那麼為了讓代碼的實作更加的有條理、有邏輯，我們就把使用者界面、邏輯處理、與資料庫的互動分開實作，至于為什麼各層之間采用接口互相通路，下面說第三點的時候着重說明。

2、為什麼要用三層架構？

在真實的業務開發中，往往是需要團隊合作開發的，畢竟一個完整的實際項目，它的開發周期會很長，這就意味着裡面會有非常多的功能子產品，比如一個簡單的圖書管理系統，就有管理者對圖書的增删改查、對使用者的增删查改，使用者對圖書的增删查改等等。這樣的一個簡單項目由一個團隊來開發隻需要一到兩天即可，而我們卻用了整整兩周不止。

那麼既然需要團隊協同開發，自然離不開功能子產品的劃分了，這時候就需要使用三層架構的思想了，在三層架構中，各層互相獨立，完成自己該完成的任務，項目可以多人同時開發，開發人員可以隻關注整個結構中的其中某一層（自己負責的那一層即可）。舉一個簡單的例子，我們要在資料庫查找一個人，那麼首先需要一個方法去資料庫查找，需要查找的條件，比如id，那麼我們就初步建立了一個方法 findById(int id)，找到之後我們需要列印這個人的資訊，那方法就進一個完善，有了傳回值 User findById(int id)。這個方法是用來在資料庫進行查詢的，那萬一沒有這個人呢，或者找到這個人我需要把這個人進行一些列的包裝處理呢？這一些列的操作我們可以把它放在邏輯處理層來，在邏輯處理層建立一個方法，處理完了之後，傳回給使用者界面。

從另一個方面來說，三層架構有利于各層邏輯的複用，比如上面說到的圖書管理系統中管理者可以對圖書進行增删查改，我們将這些方法放在一個類中，再出現對使用者的增删查改時，我們就可以複用這些代碼，修改參數和傳回值類型即可。

這樣分層處理，也更有利于代碼的移植、維護，比如資料庫SQLServer 轉 Oracle資料庫時，我們隻需要修改一個層即可，因為與資料庫的互動都在資料通路層中。

3、三層架構怎麼用？

使用三層架構時，我們首先要先建立好不同的包，每一個包對應三層架構的一個層。下面我通過一個學生登入功能的案例給大家講解三層架構的用法。

1. 首先我們在資料庫中建立了 student表，結構如下：

   

2. 建立資料傳遞的載體實體類，一般我們将實體類放在domain/pojo/entity 這三者其中一個的包下，實體類的屬性需要與資料庫中的表一一對應。

   我在 src 目錄下建立了存放實體類的包：entity，然後在包下建立了Student類，它的屬性和資料表student的屬性一一對應，然後在實體類中給各個屬性建立了對應的get/set方法，建立了有參/無參構造方法以及toString()方法。

   

3. 建立工具包util，用于存放一些常用且不變的方法，比如IO流的讀寫，反反複複都是那些代碼，我們就将這些重複的代碼抽取出來将它封裝成一個工具類，在我們需要用到這個方法的時候，直接調用即可。在驗證登入這個案例裡面，我們将連接配接資料庫需要的代碼抽取出來，這是因為每一次對資料庫表進行增删改查通路的時候都需要連接配接資料庫，是以将它抽取成工具類友善使用。

   

4. 建立資料通路層dao，在資料通路層中将對資料庫表進行操作的方法寫在接口 StudentDao 中，然後通過實作類 StudentImpl 寫具體操作資料庫表的邏輯代碼。

   

   先将需要用到的方法都封裝好，不寫方法的實作，用到某一個方法，寫這個方法的具體實作。這裡我們要做的是登入驗證，是以我們封裝了登入方法 login ，接下來我們分析：驗證登入肯定需要學生先輸入使用者名和密碼，有了使用者名和密碼之後去資料庫表中查對應的資料，查到了就将這個學生的資訊列印出來。經過分析我們知道方法的參數就是 name 和 password ，傳回值就是這個學生 Student。

   方法的具體實作，就是通過sql語句對資料庫表進行操作，都是固定的模闆，通過 JDBCTemplate模闆 調用實作的方法即可。

   

5. 建立業務邏輯層service，業務邏輯層主要是對具體問題進行邏輯判斷與執行操作，接收到表現層 UI 的使用者指令後（使用者某一步操作），會連接配接資料通路層 DAL進行業務處理。通路層在三層構架中位于表示層與資料層中間位置，同時也是表示層與資料層的橋梁，實作三層之間的資料連接配接和指令傳達，可以對接收資料進行邏輯處理，實作資料的修改、擷取、删除等功能，并将處理結果回報到表示層 UI 中，實作軟體功能。

   在登入案例裡面，我們通過學生輸入的名字和密碼在資料庫表裡進行查找，如果沒有，我們就告訴學生輸入的姓名或者密碼錯誤；如果學生輸入的資訊為空，那麼我們就根本不用通路資料通路層的方法，直接提示使用者輸入錯誤。這一系列的邏輯判斷我們都寫在邏輯層service裡面。

   

   

6. 建立使用者表示層view，表示層又稱表現層 UI，位于三層構架的最上層，與使用者直接接觸，主要是 B/S 資訊系統中的 Web浏覽頁面，由于我們還沒有使用Web頁面，是以我們的使用者表示層，就是現在大家寫的主函數裡使用者輸入的資訊。

   

   可以看到，我們的使用者界面隻有一句核心代碼，就是調用業務邏輯層的 loginStu() 方法，其他的處理全都通過三層架構的方式分開存放，代碼的邏輯變得非常的清晰。

   注意：

   這裡解釋為什麼我們要先寫接口再寫實作類：使用接口是為了調用與實作解耦，帶來的好處是可以各幹各的。

   先從工序上說，你在寫上一層的時候，會用到下一層提供的邏輯，具體表現形式就是各種各樣的service類和裡面的方法。上一層開搞的時候，一定會知道的一個事是下一層會幹什麼事，比如“将傳入編号對應的人員資訊設定為離職”，但下一層的代碼不一定已經一行一行寫出來了。是以這會兒需要有個接口，讓寫上層代碼的人先能把代碼寫下去。有各種理由可以支援這種工序的合理性，比如一般來說，上一層的一行代碼會對應下一層的好多行代碼，那先讓寫上層代碼的人寫一遍，解決高端層面的bug，會提高很多效率。

   再從抽象角度說，不同業務子產品之間的共用，不一定是共用某段代碼，也可能是共用某段邏輯架構，這時候就需要抽象一個接口層出來，再通過不同的注入邏輯實作。比如子產品1是登記學生資訊，子產品2是新聞釋出，看上去風馬牛不相及。但分析下來如果兩個子產品都有共同點，順序都是1、驗證是否有權限 2、驗證輸入參數是否合法 3、将輸入參數轉化為業務資料 4、資料庫存取 5、寫log，那就可以寫一個service接口，裡面有上述5個函數，再分别寫兩個service實作。具體執行的時候，通過各種注入方法，直接new也好，用spring注入也好，實作不同的效果。

   這樣做的另一個目的是為了後期的維護。當軟體全部編好了，測試好了，然後給使用者裝好了，但是過一段時間，使用者用着不爽，他又讓做軟體的人改變一些功能，這樣軟體開發人員隻需要改實作類裡面的代碼，也就是隻用改一個包下代碼，不用這個包改一下，那個包裡的代碼還要改。因為項目大了，代碼就是成萬上億行，用了接口的話，就起了這個作用。

   另外，不用接口的話，假如修改了dao中的代碼，因為service引用了dao中的類，那麼也要改變service裡面的代碼，改完之後要重新編譯運作，當項目比較大的時候，編譯和運作很浪費時間的，而且會産生一些意外，本來隻要編譯dao中的代碼，現在不光要編譯dao中的代碼，還要編譯service。因為你不用接口，間接着action裡的代碼也要改，因為action中引用了service中的類，到最後，就變成了，牽一發而動全身本來在各個層之間用了接口隻需要改一處代碼的，這下可好，全要改，舉個不太恰當的例子：好比，我摔了一跤，小腿摔斷了，小腿斷了，因為沒用接口，間接着，大腿也斷了，接着，屁股開花了，接着，上身也感染了。最後gg了。可能不太恰當，但是有助于你了解。

   實在了解不了，你就記住這句真理：使用接口是為了調用與實作解耦，帶來的好處是可以各幹各的。

4、 執行個體測試

通過對上述三層架構的學習，下面大家在上面這個案例的基礎之上完成 學生的注冊功能，分析：

1. 注冊相當于往資料庫表中添加一條資料。
2. 注意用代碼判斷輸入的資訊時候有誤。