451      阿裏雲  技術社區[雲棲]

《精通Spring MVC 4》——2.2　對MVC的質疑及其最佳實踐

本節書摘來自異步社區《精通Spring MVC 4》一書中的第2章，第2.2節，作者：【美】Geoffroy Warin著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看

2.2　對MVC的質疑及其最佳實踐

盡管MVC依然是當前設計UI的首選方案，但是隨著它的流行，也有很多對它的批評。實際上，大多數的批評都指向了該模式的錯誤用法。

2.2.1　貧血的領域模型
Eric Evans編寫過一本很有影響力的書，名為《領域驅動設計》（Domain Driven Design，DDD）。在這本書中，定義了一組架構規則，能夠指導我們更好地將業務領域集成到代碼之中。

其中有一項核心的理念就是將麵向對象的範式應用到領域對象之中。如果違背這一原則的話，就會被稱之為貧血的領域模型（Anemic Domain Model）。
貧血的領域模型通常來講會具有如下的症狀：

模型是由簡單老式的Java對象（plain old Java object，POJO）所構成的，隻有getter和setter方法；
所有業務邏輯都是在服務層處理的；
對模型的校驗會在本模型外部進行，例如在控製器中。
根據業務領域的複雜性不同，這可能是一種較差的實踐方式。通常來講，DDD實踐需要付出額外的努力，將領域從應用邏輯中分離出來。

架構通常都是一種權衡，需要注意的是，設計Spring應用的典型方式往往會在這個過程中導致係統在可維護性上變得較為複雜。

避免領域貧血的途徑如下：

服務層適合進行應用級別的抽象（如事務處理），而不是業務邏輯；
領域對象應該始終處於合法的狀態。通過校驗器（validator）或JSR-303的校驗注解，讓校驗過程在表單對象中進行；
將輸入轉換成有意義的領域對象；
將數據層按照Repository的方式來實現，Repository中會包含領域查詢（例如參考Spring Data規範）；
將領域邏輯與底層的持久化框架解耦；
盡可能使用實際的對象，例如操作FirstName類而不是操作String。
DDD所涉及的內容遠不止上述的規則：實體（Entity）、值類型（value type）、通用語言（Ubiquitous Language）、限界上下文（Bounded Context）、洋蔥架構（Onion Architecture）以及防腐化層（anti corruption layer），我強烈建議你自行學習一下這些原則。就我們而言，在構建Web應用的過程中，會努力遵循上述的指導原則。隨著本書的推進，你會對這些關注點更加熟悉的。

2.2.2　從源碼中學習
如果熟悉Spring的話，那麼很可能你已經訪問過Spring的Web站點，即https://spring.io。它全部是由Spring構建的，而且很棒的一點在於它是開源的。

這個項目的名稱為sagan，它包含了很多有意思的特性：

基於Gradle的多模塊項目；
集成了安全；
集成了Github；
集成了Elasticsearch；
JavaScript前端應用。
這個項目的Github wiki頁麵非常詳盡，能夠幫助你非常容易地開始了解該項目。

最後更新：2017-05-27 15:31:27

  上一篇：  《精通Spring MVC 4》——2.3　Spring MVC 1-0-1

  下一篇：  《精通Spring MVC 4》——第2章　精通MVC架構 2.1MVC架構