MVC模式:Model模型 View試圖 Control控制器,是目前主流模式,被當作伺服器軟體入門基本模式學習和掌握,主流架構Struts 1/2 JSF Wicket基本都順理成章支援MVC模式。
但是,随着時間推移,MVC模式也暴露出大量缺點,因為MVC模式本質上是一個結構型模式,結構模式相比行為模式而言,實際就是靜止的,相對固定的,而随着B/S和網際網路應用不斷普及,Web 2.0和社會化媒體 以及遊戲等大量頻繁互動應用普及,相對靜止的MVC模式已經不适合高度互動注重行為的應用了。
DDD領域模組化本身比較重視結構,它的實體 值對象和伺服器是也是一種結構劃分,但是沒有強調對象職責行為的重要性,而這是對象和資料庫唯一的差別,當然其上下文場景概念的提出,也可以認為展現了對角色和場景的重視,但遠遠不夠。
相反,對象設計:角色、責任和協作"(Object Design: Roles, Responsibilities, and Collaborations))一書提出職責驅動開發,将對象行為上升為重點,提出了對象其實是在扮演某種角色,而角色是有職責的,然後會在一定場景上下文環境中實施一定互動行為,這些已經在Jdon進行了充分讨論:
DCI,領域模型,領域事件的一些想法
異步架構思維:使用Akka實作領域模組化
該書總結了集中式控制器4大缺點,MVC的控制器實際就屬于這種集中式控制器風格:
1.Control logic can get overly complex. 控制器會變得複雜,很多人在Struts的Action控制器中寫業務代碼已經變得很常見,所有的操作都在action中,有的action都幾乎上千行了.
2.Controllers can become dependent on information holders' contents.控制器變得依賴資訊資料中心或資料庫了,控制器做很多事情,意味着領域對象就做很少事情,控制器最後不是隻會做什麼,決定戰略性的事情,也和怎麼做,如何實作等戰術問題耦合。
3.Objects can become coupled indirectly through the actions of their controller. 對象将間接地通過控制器的action耦合在一起,一個對象在控制器中查詢獲得,然後複制給另外一個對象,這兩個對象就耦合在一起。
4.The only interesting work is done in the controller.唯一有趣的工作是做控制器,Responsibilities職責被吸進控制器對象,隻将一些行為留給角色模型完成,重要的事情都集中在控制器中了。
MVC的控制器是Mediator模式一種,也屬于一種集中式控制器,它與觀察者模式重大差別是:Mediator模式封裝了通訊,而Observer分散通訊,從通訊角度來看,控制器也有其固有的缺陷,容易變成大而全高度耦合的集中器,這些都是為OO所不容。
DCI架構是最近才興起的新概念,它從一個全新角度來看待軟體,與職責驅動設計不謀而合,同時也是對DDD的發展和完善。
DCI是資料Data 場景Context 互動Interactions的簡稱,它重要貢獻是提出了場景這個概念,而這點是職責驅動開發一書沒有提及,該書隻是否定了MVC,揭露其問題,沒有提出替代方案,而DCI正是MVC的替代架構,DCI替代MVC 用場景替代控制器應該是大勢所趨,如下圖(圖來自原文英文The DCI Architecture: A New Vision of Object-Oriented Programming):
場景其實将MVC中Control和模型中一部分挖了出來,以角色場景方式進行重新組合。這是一種與MVC模式考慮角度完全不一樣的新角度,這種角度更符合OO。
最近,有人提出 場景Context是新的對象類型,場景不但可以替代SOA的Web服務,也可以替代MVC的控制器。
個人認為:未來新的分層架構可能變成這樣:
View --> Context ---> Domain Model ---> Component/Respository
MVC模式已死。