使用spring框架構建應用的開發者很樂於談論依賴注入的好處。但遺憾的是，他們很多人並沒有在其應用中很好地利用其優勢，如單一職責原則和關注分離原則。如果仔細看看基於spring的web應用，你會發現很多都是使用如下這些常見且錯誤的設計原則來實現的：
可問題是：如果這種做法很普遍，那為什麼說是不對的呢？下面來闡述一下。
spring web應用之所以看起來是這個樣子原因在於這是人們長久以來的做法，舊習難改，特別是在高階開發者或是軟體架構師強制開發人員這樣做的時候。問題在於這些人非常擅於捍衛自己的觀點。他們喜歡的乙個論調就是應用應該遵循關注分離原則，因為它被劃分成了幾個層次，每個層次都有自己具體的職責。
乙個典型的spring web應用會有如下幾個層次：
關注分離原則的定義是這樣的：關注分離（soc）是一種將電腦程式劃分到不同部分的一種設計原則，這樣每一部分都會有單獨的關注點。雖然乙個典型的spring web應用也在一定程度上遵循了這個原則，不過實際情況卻是應用擁有乙個整體的服務層，它包含了太多的職責了。更具體一些，服務層主要有兩個問題：
首先，應用的業務邏輯來自於服務層。
這是個問題，因為業務邏輯散落在服務層。如果需要檢視某個業務規則是如何實現的，我們需要先找到它才行，這可不是那麼輕鬆的事情。此外，如果有多個服務類都需要相同的業務規則，那麼開發人員很可能會將這個業務規則從乙個服務複製到另乙個服務中，這會導致維護的夢魘。
其次，每個領域模型類在服務層中都有乙個服務類。
這違背了單一職責原則：單一職責原則表明每個類都應該只有乙個職責，這個職責應該完全被這個類所封裝。它的所有服務都應該與這個職責保持一致。
服務類存在大量的依賴和大量的迴圈依賴。乙個典型的spring web應用的服務層沒有包含只擁有乙個職責的松耦合的服務，它更像是乙個緊耦合的大量服務的集合。這使得它很難理解、維護與重用。看起來有點苛刻，不過服務層經常是spring web應用最容易出現問題的一環。幸好對我們來說還存在著希望。
目前的狀況並不好，不過也不是完全沒有希望的。下面我們來看看如何打破舊有的習慣。
首先，我們需要將應用的業務邏輯從服務層移動到領域模型類中。
為何要這麼做呢，看看下面這個例子：
假設我是個服務類，你是個領域模型物件。如果我告訴你從房頂跳下來，那麼你是否會拒絕呢？
將服務層的業務邏輯移動到領域模型類中有如下3個好處：
其次，我們需要將特定於實體的服務劃分為更小的服務，每個服務只有乙個目標。
這麼做有如下3個好處：
這兩個簡單的步驟可以幫助我們清理應用的架構，提公升開發者的生產力和幸福度。現在，我們想知道如果所有這些都是必要的，那麼該何時解決這些問題呢？
我經常聽到有人說我們不應該過多的關注於「架構」，因為我們的應用很小並且很簡單。雖然這個論調有一定的正確性，不過我們必須要記住一開始很小的專案最後會變得很大。如果不考慮這種情況，那麼一旦發生狀況，我們就會陷入到巨大的麻煩當中。在未知的水域中航行可不是個好做法，但我們必須要知道，鐵達尼號在撞到冰山沉沒時是在熟悉的航線中航行的。這種事情也會發生在我們的應用中。當事情變得無法控制時，我們必須要有勇氣說不。
如果你打算改變，那麼我推薦你閱讀一下olivier gierke所寫的「whoops! where did my architecture」（或是**他在springone2gx上關於這個專案的演講）。但請注意，習慣的力量還是很強大的。
Spring Web應用的最大瑕疵
使用spring框架構建應用的開發者很樂於談論依賴注入的好處。但遺憾的是，他們很多人並沒有在其應用中很好地利用其優勢，如單一職責原則和關注分離原則。如果仔細看看基於spring的web應用，你會發現很多都是使用如下這些常見且錯誤的設計原則來實現的 u0026 xd n 可問題是 如果這種做法很普遍，...
所知的Spring Web應用的最大瑕疵
比如說，如果應用有乙個服務類，它為與使用者帳戶相關的人與操作提供了crud操作，那麼我們就應該將其劃分到兩個單獨的服務類中 第1個服務提供人的crud操作。第2個服務提供與使用者帳戶相關的操作。這麼做有如下3個好處 每個服務類都有一套合理的職責。每個服務類的依賴會更少，這意味著他們不再是緊耦合的龐然...
Spring Web框架與Struts的區別
下面是從 struts 的角度來談談 spring 自帶的web 框架的使用。當然，我們在配置 web框架前，需要把 spring 配置好，這裡就不多說了。1.web 框架核心 servlet 在web.xml 中的配置。dispatcher org.springframework.web.serv...