关于程序设计之MVC思想和MCF(MLC)思想的异同及碰撞

mvc应该是在web端来说很常用且简单的一种设计思想了 ，mvc分别代表了

m model 模型（操作数据）

v view 视图（页面交互）

c controller 控制器（处理业务逻辑）

        这种思想我个人认为没有完全实现面向对象的思想，也就是在很多情况下没有做到代码最优化，好多时候（比如修改需求的阶段）可能无法做到代码的重用，同样一段代码可能需要粘贴好几个地方调用。当然好处也显而易见，简单易懂，上手快，开发阶段速度快。

        那mvc是如何工作的呢？？控制器层通过业务逻辑，进行数据交互。过程很简单，基本原则是每个表都单独建一个类，流程可以这样理解（举一个用户留言的例子），基本操作有以下几步

（1）验证用户是否登录（只有登录用户才能留言）

（2）验证文章是否存在、状态是否允许留言

（3）检查用户当天对该文章是否有留言（一个用户规定当天对同一个文章只能留言一次）

（4）检查用户当天所有留言总数是否大于20（一个用户最多每天只能留言20次）

（5）插入留言库

（6）更新缓存

（7）插入记录表

（8）给用户发短信或邮件

（9）统计留言信息来源（如app留言用户需要统计手机型号和下载市场等信息）

这几个步骤之间有的有依赖关系，有的没有。如果用mvc的思路来做的话，会有一个盛放了很多业务逻辑的控制器，不断的调用处理数据的model类。这样写的优势和劣势都很明显

优势：典型的面向过程的写法，前期代码开发快速

劣势：代码依赖性强，后期遇到大的功能修改的时候会非常痛苦。

        随着时间的推移，现有的业务逻辑要改变，现在不要求对用户每天针对同一篇文章的留言次数做限制，可以无限留言。因为需求比较简单，那现在只需要把做限制的代码给删除即可。但如果现在有个比较大的业务需求，有一些文章是比特殊的（比如很敏感），我们在留言的时候对它的留言数量是没有限制并且是不用给用户发短信或邮件的。这时候会有两种思路，一种是在原来的控制器中，加各种判断（强烈不建议，以为随着以后业务逻辑的复杂和变化，条件判断越来越多，代码会越来越难以维护）。第二种，是重新建立一个控制器，针对特殊文章让他们走一个专门的控制器，这时候的劣势就显现出来了，你需要复制大部分代码过来，明明是80%的代码是一模一样的，看来像是可以复用的，但怎么就用不了呢？这就是mvc的劣势，没办法很好的做到代码的复用，也就是没能完全实现面向对象（至少在这里没有实现吧！）

      那如果现在，有这样一个在控制器和model之间的中间层，专门用来做一些阶段性的工作，比如做包含了1 2 3 4 个操作的内容，这时候我们遇到大的需求改动的时候就不需要每次都把所有的业务逻辑修改一边了，只需要建立专门盛放阶段性任务的factory，然后通过控制器调用。这就是MCF.或者也可以把factory叫做Library.