javascript
Spring Web应用程序的最大缺陷
在其應用程序中使用Spring Framework的開發人員很好地談論了依賴注入的好處。 不幸的是，他們并不是很好地利用它的好處，例如單一負責的原則和在應用程序中關注點的分離 。 如果我們看一下任何基于Spring的Web應用程序，很可能會通過使用以下常見且同樣錯誤的設計原則來實現該應用程序：
問題是：如果這是如此普遍，那怎么可能是錯誤的呢？ 讓我們找出答案。
舊習難改
Spring Web應用程序之所以這樣看，是因為這是一成不變的方式，舊習慣很難消除，特別是如果它們是由高級開發人員或軟件架構師實施的。 問題是這些人非常擅長捍衛自己的觀點。 他們最喜歡的論點之一是，我們的應用程序遵循關注點分離原則，因為它已分為幾層，每一層都有特定的職責。
典型的Spring Web應用程序具有以下幾層：
- Web層負責處理用戶的輸入并將正確的響應返回給用戶。 Web層僅與服務層通信。
- 充當事務邊界的服務層 。 它還負責授權，并包含我們應用程序的業務邏輯。 服務層管理域模型對象，并與其他服務和存儲庫層進行通信。
- 存儲庫/數據訪問層 ，負責與使用的數據存儲進行通信。
關注點分離原則定義如下：
關注點分離（Soc）是一種用于將計算機程序分為不同部分的設計原理，這樣每個部分都可以解決一個單獨的關注點。 盡管確實有一個典型的Spring Web應用程序在一定程度上遵循了這一原理，但現實情況是該應用程序具有一個整體的服務層，它承擔了太多的責任。 更具體地說，服務層有兩個主要問題：
首先，從服務層找到應用程序的業務邏輯。
這是一個問題，因為業務邏輯分散在服務層周圍。 如果我們需要檢查特定業務規則的實施方式，則必須首先找到它。 這可能并不容易。 另外，如果多個服務類別中需要相同的業務規則，則很可能會將規則簡單地從一個服務復制到另一個服務。 這導致了維護的噩夢。
其次，服務層在每個域模型類中都有一個服務類。
這違反了如下定義的單一責任原則：單一責任原則規定每個類都應具有單一責任，并且該責任應完全由該類封裝。 它的所有服務都應嚴格地與這一責任保持一致。
服務類具有很多依賴關系和很多循環依賴關系 。 典型的Spring Web應用程序的服務層并不由松散耦合的服務組成，這些服務僅具有一種責任。 它更像是緊密耦合的整體服務網絡。 這使得難以理解，維護和重用。 這聽起來可能有點苛刻，但是服務層通常是Spring Web應用程序中最有問題的部分。 對我們來說幸運的是，所有希望都沒有丟失。
掙脫
當前的情況很糟，但并非完全沒有希望。 讓我們找出如何擺脫舊習慣。
首先，我們必須將應用程序的業務邏輯從服務層移到域模型類。
如果考慮以下示例，應該使我們明白這一點的理由：
假設我是服務類，而您是域模型對象。 如果有人告訴您從屋頂上跳下來，您是否愿意對我的決定擁有否決權？
將業務邏輯從服務層移到域模型類將為我們帶來三個好處：
其次，我們必須將特定于實體的服務劃分為僅用于單一目的的較小服務。
例如，如果我們的應用程序具有單個服務類，該服務類為人員和與用戶帳戶相關的操作提供CRUD操作，則應將其分為兩個單獨的服務類：
- 第一項服務為人員提供CRUD操作。
- 第二服務提供與用戶帳戶有關的操作。
這給了我們三大優勢：
這兩個簡單的步驟將幫助我們清理應用程序的體系結構，并提高開發人員的工作效率和滿意度。
現在，我們可能想知道這是否真的必要？如果需要，何時解決這些問題至關重要？
有時生活是黑白的
我經常聽到一個論點，指出我們不應該過多關注“體系結構”，因為我們的應用程序既小又簡單。 盡管這種說法有一定道理，但我們必須記住， 從小做起的項目可以成長為更大的項目 。
如果我們在發生這種情況時沒有考慮到這一點，那么我們就被搞砸了。
在未知的水域中航行可能聽起來是個壞主意，但我們必須記住，泰坦尼克號被沉沒的冰山撞到時正沿著熟悉的路線航行。 現在我們的應用程序可能正在發生同樣的事情。
當事情失控時，我們必須有勇氣喊叫停止 。
PS：如果您準備服用紅色藥丸，建議您閱讀“ 哎呀！ Olivier Gierke的架構在哪里去了（或觀看他關于同一主題的SpringOne2GX演示 ）。 但是請注意，兔子洞比您想象的要深得多。
翻譯自: https://www.javacodegeeks.com/2013/06/the-biggest-flaw-of-spring-web-applications.html
總結
以上是生活随笔為你收集整理的Spring Web应用程序的最大缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用Apache CXF开发RESTfu
- 下一篇： Spring Security应用程序中