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

本節書摘來自異步社群《精通spring mvc 4》一書中的第2章，第2.2節，作者：【美】geoffroy warin著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

盡管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　從源碼中學習

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

基于gradle的多子產品項目；

內建了安全；

內建了github；

內建了elasticsearch；

javascript前端應用。

這個項目的github wiki頁面非常詳盡，能夠幫助你非常容易地開始了解該項目。