每個開發(fā)人員必須了解兩件事：

架構(gòu)設(shè)計是必要的。

花哨的體系結(jié)構(gòu)圖沒有描述應(yīng)用程序的真實體系結(jié)構(gòu)。

真正的體系結(jié)構(gòu)是從開發(fā)人員編寫的代碼中找到的，如果不設(shè)計應(yīng)用程序的體系結(jié)構(gòu)，最終將得到一個具有多個體系結(jié)構(gòu)的應(yīng)用程序。

這是否意味著開發(fā)人員應(yīng)由建筑師統(tǒng)治？

不行 建筑設(shè)計是太重要了，不能留給建筑師 ，這就是為什么每一個開發(fā)商 ，誰愿意不僅僅是一個類型的作家， 一定要做好它 。

讓我們從兩個原則入手，這兩個原則將幫助我們?yōu)榛赟pring的Web應(yīng)用程序設(shè)計更好，更簡單的體系結(jié)構(gòu)。

優(yōu)秀建筑的兩大Struts

建筑設(shè)計可能感覺像是一項艱巨的任務(wù)。 這樣做的原因是，許多開發(fā)人員被教導(dǎo)要相信建筑設(shè)計必須由神秘知識的守護者來完成。 這些人稱為軟件架構(gòu)師。

但是， 任務(wù)本身并沒有聽起來那么復(fù)雜 ：

軟件體系結(jié)構(gòu)是軟件系統(tǒng)的高層結(jié)構(gòu)，是創(chuàng)建這種高層結(jié)構(gòu)的準則，也是該結(jié)構(gòu)的文檔。

盡管經(jīng)驗確實可以幫助我們創(chuàng)建更好的架構(gòu)，但是架構(gòu)設(shè)計的基本工具實際上非常簡單。 我們要做的就是遵循以下兩個原則：

1.關(guān)注點分離（SoC）原則

關(guān)注點分離（SoC）原則指定如下：

關(guān)注點分離（SoC）是一種用于將計算機程序分為不同部分的設(shè)計原理，這樣每個部分都可以解決一個單獨的關(guān)注點。

這意味著我們應(yīng)該：

確定我們需要注意的“問題”。

確定我們要在哪里處理它們。

換句話說，該原理將幫助我們確定所需的層以及每一層的職責。

2.保持簡單愚蠢（KISS）原則

保持簡單愚蠢（KISS）原則指出：

如果大多數(shù)系統(tǒng)保持簡單而不是變得復(fù)雜，則它們的工作效果最佳。 因此，簡單性應(yīng)該是設(shè)計的主要目標，并且應(yīng)避免不必要的復(fù)雜性。

這個原則是理性的聲音。 它提醒我們，每個層都有價格，如果我們創(chuàng)建一個復(fù)雜的體系結(jié)構(gòu)而具有太多的層，則價格會太高。

換句話說， 我們不應(yīng)該設(shè)計這樣的架構(gòu) ：

來源： Geek and Poke：足跡 – 根據(jù)CC 3.0許可

我認為約翰，朱迪，馬克和戴維犯有手淫罪 。 他們遵循關(guān)注點分離原則，但忘記了最小化其體系結(jié)構(gòu)的復(fù)雜性。 可悲的是，這是一個常見的錯誤，并且價格很高：

添加新功能比原先需要的時間長得多，因為我們必須通過每一層傳輸信息。

維護應(yīng)用程序是不可能的事，因為沒有人真正了解架構(gòu)，并且每次做出的臨時決定都會堆積起來，直到我們的代碼庫看起來像是一大堆東西，有十層。

這就提出了一個明顯的問題：

什么樣的架構(gòu)可以很好地為我們服務(wù)？

每個人都應(yīng)該做到三層

如果考慮Web應(yīng)用程序的職責，我們注意到Web應(yīng)用程序具有以下“問題”：

• 它需要處理用戶的輸入并將正確的響應(yīng)返回給用戶。
• 它需要一個異常處理機制來向用戶提供合理的錯誤消息。
• 它需要一個事務(wù)管理策略。
• 它需要同時處理身份驗證和授權(quán)。
• 它需要實現(xiàn)應(yīng)用程序的業(yè)務(wù)邏輯。
• 它需要與使用的數(shù)據(jù)存儲和其他外部資源進行通信。

我們可以通過僅使用“三層”來滿足所有這些問題。 這些層是：

• Web層是Web應(yīng)用程序的最上層。 它負責處理用戶的輸入并將正確的響應(yīng)返回給用戶。 Web層還必須處理其他層引發(fā)的異常。 因為Web層是我們應(yīng)用程序的切入點，所以它必須注意身份驗證并充當防范未授權(quán)用戶的第一道防線。
• 服務(wù)層位于Web層下方。 它充當事務(wù)邊界，同時包含應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)服務(wù)。 應(yīng)用程序服務(wù)提供服務(wù)層的公共API。 它們還充當交易邊界并負責授權(quán)。 基礎(chǔ)結(jié)構(gòu)服務(wù)包含“管道代碼”，該“管道代碼”與外部資源（例如文件系統(tǒng)，數(shù)據(jù)庫或電子郵件服務(wù)器）進行通信。 通常，不止一個應(yīng)用程序服務(wù)會使用這些方法。
• 存儲庫層是Web應(yīng)用程序的最低層。 它負責與使用的數(shù)據(jù)存儲進行通信。

屬于特定層的組件可以使用屬于同一層或其下一層的組件。

經(jīng)典的Spring Web應(yīng)用程序的高級體系結(jié)構(gòu)如下所示：

接下來要做的是設(shè)計每一層的接口，這是我們遇到諸如數(shù)據(jù)傳輸對象（DTO）和域模型之類的階段的階段。 這些術(shù)語描述如下：

• 數(shù)據(jù)傳輸對象是一個僅是簡單數(shù)據(jù)容器的對象，這些對象用于在不同進程之間以及應(yīng)用程序各層之間承載數(shù)據(jù)。
• 域模型由三個不同的對象組成：
  • 域服務(wù)是一種無狀態(tài)類，它提供與域概念相關(guān)但不是實體或值對象的“自然”部分的操作。

現(xiàn)在我們知道了這些術(shù)語的含義，我們可以繼續(xù)設(shè)計每一層的接口。 讓我們一層一層地進行檢查：

• Web層應(yīng)僅處理數(shù)據(jù)傳輸對象。
• 服務(wù)層將數(shù)據(jù)傳輸對象（和基本類型）作為方法參數(shù)。 它可以處理域模型對象，但只能將數(shù)據(jù)傳輸對象返回到Web層。
• 存儲庫層將實體（和基本類型）作為方法參數(shù)，并返回實體（和基本類型）。

這就提出了一個非常重要的問題：

我們真的需要數(shù)據(jù)傳輸對象嗎？ 為什么我們不能僅僅將實體和值對象返回到Web層？

這是一個壞主意有兩個原因：

域模型指定了我們應(yīng)用程序的內(nèi)部模型。 如果我們將此模型暴露給外界，則客戶將不得不知道如何使用它。 換句話說，我們的應(yīng)用程序的客戶將不得不照顧不屬于他們的東西。 如果使用DTO，則可以向應(yīng)用程序的客戶端隱藏此模型，并提供更簡單，更簡潔的API。

如果我們將領(lǐng)域模型暴露給外部世界，那么我們在不破壞依賴于它的其他內(nèi)容的情況下就無法更改它。 如果使用DTO，只要不對DTO進行任何更改，就可以更改域模型。

經(jīng)典Spring Web應(yīng)用程序的“最終”架構(gòu)如下所示：

還有許多未解決的問題

這篇博客文章描述了Spring Web應(yīng)用程序的經(jīng)典體系結(jié)構(gòu)，但未提供對真正有趣的問題的任何答案，例如：

• 為什么X層負責關(guān)注點Y？
• 我們的應(yīng)用程序應(yīng)該包含三層還是少于三層？
• 我們應(yīng)該如何設(shè)計每一層的內(nèi)部結(jié)構(gòu)？

這樣做的原因是簡單的：

我們必須學(xué)會走路才能跑步 。

本教程的下一篇博客文章將回答這些問題。

翻譯自: https://www.javacodegeeks.com/2014/10/understanding-spring-web-application-architecture-the-classic-way.html

總結(jié)

以上是生活随笔為你收集整理的了解Spring Web应用程序体系结构：经典方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。