首页 > 移动开发 > 移动端的客户端MVC设计模式思考

移动端的客户端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单独拿出来,是因为整个体系架构中,我们希望所有的耦合都是数据耦合,这样,就没有模块之间的强的依赖关系了。

个人经验,欢迎探讨。


本文固定链接: http://www.devba.com/index.php/archives/3965.html | 开发吧

报歉!评论已关闭.