奥东......about MVC

引入

http://kb.cnblogs.com/page/502983/

主流MVC框架向command转型是有缘由的，除了command自身的优点以外，一个很是重要的缘由就是：因为缺乏合理的组织依据，controller的粒度很难拿捏

controller不一样于view与model，view与model都有各自自然的粒度组织依据，view的组织粒度直接承袭用户界面设计，model的组织粒度则是依据某种分析设计思想（如OOA/D）进行领域建模的结果，controller须要同时协调view与model，可是view与model的组织结构和粒度都是不对等的，这就使得controller面临一个“在多大视图范围内沟通与协调多少领域对象”的问题，因为找不出合理的组织依据，设计者在设计controller时每每感到无所适从。相比之下，command则彻底没有controller的困惑，由于command有一个自然的组织依据，这就是user action。

针对一个user action设计一个command，而后将二者映射在一块儿，是一件很是天然而简单的事情。不过，须要说明的是这并不意味着全部command的粒度是同样的，由于不一样的user action所表明的业务量是不一样的，所以也决定了command是有“大”有“小”的。遵循良好的设计原则，对某些较“大”的command进行分解，从中抽离出一些可复用的部分封装成一些较“小”的command是值得推荐的。不少MVC框架就定义了一些相关的接口和抽象类用于支持基于组合模式的命令拼装。

不变的地方：

无论是基于controller仍是基于command，MVC架构中界定的“协调view与model交互”的控制器职责是不会变的，都须要相应的组件和机制去承载与实现。在基于command的架构里，command承担了过去controller的部分职责，从某种意义上说command是一种细粒度的controller，可是command的特性是偏“被动”的。一方面，它对于view和model的控制力比controller弱化了不少， 好比，通常状况下command是不会直接操纵view的。另外一方面，它不知道本身与什么样的user action映射在了一块儿，也不知道本身会在何种状况下被触发执行。支撑command的运行须要额外的注册、绑定和触发机制，是这些机制加上command一块儿实现了controller的职责。因为如今多数基于command的MVC框架都实现并封装了这些重要的机制，因此从某种意义上说，是这些框架自身扮演了controller角色。