奥东......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角色。