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模式已死。

[該貼被admin於2010-04-09 14:22修改過]