spring體系結構

每個開發人員必須了解兩件事：

架構設計是必要的。

花哨的體系結構圖沒有描述應用程序的真實體系結構。

真正的體系結構是從開發人員編寫的代碼中找到的，如果不設計應用程序的體系結構，最終將得到一個具有多個體系結構的應用程序。

這是否意味著開發人員應由建筑師統治？

不行 架構設計非常重要，不能只留給建筑師 ，這就是為什么每個想要不僅僅是一個類型編寫者的開發人員都必須擅長 于此 。

讓我們從兩個原則入手，這兩個原則將幫助我們為基于Spring的Web應用程序設計更好，更簡單的體系結構。

優秀建筑的兩大Struts

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

但是， 任務本身并沒有聽起來那么復雜 ：

軟件體系結構是軟件系統的高層結構，創建這種高層結構的準則以及該結構的文檔。

盡管經驗確實可以幫助我們創建更好的架構，但是架構設計的基本工具實際上非常簡單。 我們要做的就是遵循以下兩個原則：

1.關注點分離（SoC）原則

關注點分離（SoC）原則指定如下：

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

這意味著我們應該：

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

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

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

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

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

如果將大多數系統保持簡單而不是使其變得復雜，則它們的工作效果最佳。 因此，簡單性應該是設計的主要目標，并且應避免不必要的復雜性。

這個原則是理性的聲音。 它提醒我們，每個層都有價格，如果我們創建一個復雜的體系結構而具有太多的層，則價格會太高。

換句話說， 我們不應該設計這樣的架構 ：

來源： Geek and Poke：足跡 – 根據CC 3.0許可

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

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

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

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

什么樣的架構可以很好地為我們服務？

每個人都應該做到三層

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

• 它需要處理用戶的輸入并將正確的響應返回給用戶。
• 它需要一個異常處理機制來向用戶提供合理的錯誤消息。
• 它需要一種交易管理策略。
• 它需要同時處理身份驗證和授權。
• 它需要實現應用程序的業務邏輯。
• 它需要與使用的數據存儲和其他外部資源進行通信。

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

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

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

經典的Spring Web應用程序的高級體系結構如下所示：

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

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

現在我們知道了這些術語的含義，我們可以繼續設計每一層的接口。 讓我們一層一層地進行檢查：

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

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

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

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

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

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

經典Spring Web應用程序的“最終”架構如下所示：

還有許多未解決的問題

這篇博客文章描述了Spring Web應用程序的經典體系結構，但未提供對真正有趣的問題的任何答案，例如：

• 為什么X層負責關注點Y？
• 我們的應用程序應該包含三層還是少于三層？
• 我們應該如何設計每一層的內部結構？

這樣做的原因是簡單的：

我們必須學會走路才能跑步 。

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

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

spring體系結構

總結

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

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