來源：http://t.cn/EM8ROEb

開發人員在使用Spring應用時非常擅長談論依賴注入的好處。不幸的是，他們沒有真正的利用到它的好處，如單一職責原則，分離關注原則。如果我們一起來看看大部分Spring的Web應用程序，常見的錯誤的設計如下：

1.領域模型對象用來存儲應用的數據(當作DTO使用)，領域模型是貧血模型這樣的反模式。

2.業務邏輯位于管理域對象數據的服務層中。

3.服務層每個實體有一個服務。

問題是這樣很普遍，錯誤在哪里呢？

Spring的web應用程序之所以這樣是因為他們做事的方式一直都是這樣做的，老習慣難改，特別是如果他們是高級開發人員或軟件架構師，這些人捍衛這樣做的論據之一是：我們的應用程序遵循關注分離的原則，因為它已經被分為若干層，每個層都有自己的特定職責。

典型的SpringWeb應用程序具有以下幾層：

1.Web層負責處理用戶輸入，并返回正確的響應給用戶。 web層與服務層通信。

2.服務層作為一個事務邊界，它也負責授權和包含我們的應用程序的業務邏輯。服務層管理領域模型對象，并與其他服務和存儲層進行通信。

3.存儲庫/數據訪問層負責與所使用的數據存儲進行通信。

分離關注(Soc)是分離計算機程序為不同的部分，每個部分有一個關注聚焦，一個典型的Spring Web應用在一定程度上遵循這一原則，但現實是，該應用程序有一個整體的服務層，它有太多的責任。更具體地，服務層有兩個主要問題：

1.在服務層發現業務邏輯

業務邏輯被分散在各個服務層。如果我們需要檢查一個業務規則是如何實現的，我們必須先找到它。這可能并不容易。此外，如果相同的業務規則需要在多個服務類，問題是，規則需要從一個服務到另一個服務簡單地復制。這將導致維護的噩夢。

2.每個領域模型一個服務

這完全違反了單一職責原則，它被定義為如下：單一職責原則指出，每一個類都應該有一個責任，責任應該由類完全封裝。其所有的服務應該狹義與責任相一致。(不應將原屬于領域模型的行為方法等劃放在服務中實現，對象不但有屬性還有行為)

服務類有很多依賴，以及大量的循環依賴。更像網絡緊密耦合和單體服務。這使得很難理解，維護和重用。這聽起來有點苛刻，但一個Spring的web應用的服務層往往是最容易出問題的部分。幸運的是，所有的希望都不會丟失。

1. 我們必須將我們的應用程序的業務邏輯從服務層遷移到領域模型類中。

舉個例子：假設我是一個服務類，你是一個域模型對象。如果我讓你從屋頂上跳下來，你會喜歡我這樣的決定嗎？(跳下來會摔傷，自己沒有腦子或被洗腦，變成僵尸，只聽從執行，不思考自己的安全，這就是貧血模型的問題)

將業務邏輯從服務層遷移到域模型類有下面三個優勢：

(1)我們的代碼將以邏輯方式切割，服務層只要關注應用邏輯，而我們的領域模型關注業務邏輯。

(2)業務邏輯只存在一個地方，容易發現修改。

(3)服務層的源代碼是清潔的，不包含任何復制粘貼代碼

2. 將每個實體服務切割為單一目標的更小的服務。

比如，有一個單一服務類，提供對人員和用戶賬戶的CRUD操作，我們應該將它分為兩個獨立的服務類：

第一個是對人員的提供CRUD操作

第二個是提供與用戶賬戶相關的操作。

好處：每個服務類中有一個邏輯組職責。每個服務類的依賴較少，這意味著他們不再是緊耦合的源頭。他們是較小的和松耦合的組件。服務類更容易理解，維護和重用。

這兩個簡單的步驟將幫助我們使得我們的應用程序架構更干凈，有助于同行開發商提高生產力。

總結

以上是生活随笔為你收集整理的Spring Web 应用的最大败笔的全部內容，希望文章能夠幫你解決所遇到的問題。

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