移动端的客户端MVC设计模式思考

关于MVC 设计模式的思考，记录于此，与君共勉。

首先，我们大家都非常的熟悉MVC模式，Module,View,Control.绝大多数的人都是很理解他们的含义的，并且也都经常的使用这样的开发模型。

正式因为大家那么经常的使用，我才想到去思考MVC模型的本身。

第一个问题是我们为什么要MVC？是因为我们在设计过程和编码过程中，发现后台与前端之间交互过于频繁，导致耦合度非常高，并且根本不可能完全的解耦。那MVC模式提出了讲视图，控制以及模型分离开来，其中视图和模型都与控制层耦合。

但是，模型是死的，人是活的。这种严格的模型限制也限制住了我们发挥的空间，以及产品的性能。并且，对于经常会出现前端变更的系统来说，意味着不稳定的controller。这个时候，我们是否可以考虑让页面自己管理自己，当该页面的需要超出了当前的控制该页面的轻量级module的管理范围时，再将这个请求抛给controller，进行页面跳转或者其他数据获取操作，那这个时候模型可能会变成这样：

这个模型提供很强的对于前端变更的适应性。这个模型已经可以适应很多的移动端应用了。但是有的时候需求经常的变更，导致在这里的business Module也会跟着经常的变动或是被删除。可是这个Module我们当初开发了很长时间，有人力成本，很多东西还可以复用。这个时候我们会想到将对于本系统一些常用的Business module提取出来，单独作为一个大的模块。当一个新的业务需求到来时，我们需要做的就是拼这些常用的module在一起，然后加上一点点当前需求的特殊需要即可。到时候，及时这个需求需要被删除，也只是删除少部分的代码。总体的思想就是减轻与前端交互的易变业务逻辑的代码复杂度。模型见下图：

在这个视图中，Reference Unit就是那个被我们从Business Unit中提取出来的公共业务代码模块。而在Contronller下面我们划分了Core，作为底层的公共核心模块，其实是想约束上面易变模块的，以达到控制软件边界的效果。另外，讲Data单独拿出来，是因为整个体系架构中，我们希望所有的耦合都是数据耦合，这样，就没有模块之间的强的依赖关系了。

个人经验，欢迎探讨。