MVC在UI-Mgr-Task的思考

1  MVC在实际工作中的应用

         目前我们更多的是侧重在技术细节上面的思考，对于系统或者模块架构设计，以及在局部中所应该考虑的设计方法或者模式上面的思考还是比较欠缺的。系统整体架构我们一般所熟知有三层架构、MVC、事件驱动框架。现在大多趋向于使用MVC架构的设计。

         对于不懂设计模式的人，其实在实际的工作过程中已经在自然不自然的使用着某些模式了，只是不清楚使用的是何种模式，当然也不清楚这样的模式的复用性以及好处。在这里我们会介绍一些最为常见的设计模式，同时也会结合例子说明，这样可以使大家能更好的理解和掌握。

         MVC就是Model 模型层、View试图层和Controller控制层。三层架构是：视图层、控制层、业务逻辑层+ 数据访问层。这样的分层法，在层次结构上和清晰，在很大程度了减少了模块之间的耦合度。但是由于这种放在的复杂性，对于小项目不是很适合。MVC中的模型层就是三层架构中的业务逻辑层和数据访问层。

模型对数据和功能进行封装，并执行某些功能任务，模型只关心功能任务上，对于如何展示给用户，模型并不关心。模型需要向外提供功能行接口，和一些状态查询和设置接口。同时我们还有一点需要注意的事在模型的状态改变后需要通知视图，以便视图能及时的展示模型的状态。

视图就是用于向用户展示模型的状态信息，对于同一模型，可以有不同的视图来展示。在模型中我们也有提到这个，在模型的状态改变之后需要向所有关联的视图发送通知去更新视图。在这个地方，我们可以很好的联系到观察者模型。

控制器，需要接收请求，并将请求转化为识别的操作后，交于对应的模型进行处理或者交给视图进行展示。

         在使用MVC进行软件系统设计时的基本实现过程：

1.      控制器创建模型

2.      控制器创建一个或者多个视图，并将它们和模型关联起来

3.      控制器负责改变模型的状态

4.      当模型状态改变时，模型通知所关联的视图进行更新。

如果用UML来表示MVC设计模式，则如图1所示：

 

         对MVC的实际应用，其中UI、Mgr和UI应该算是在客户端产品中经常碰到的一个极其类似MVC模型的问题。还有

1.1 UI-Mgr-Task的思考

         在CS系统中我们经常会碰到的一个功能就是UI-Mgr-Task之间的设计了。首先我们来分别对这三个部分进行分析，以得到适合这个问题的模式。简单的阐述一下这三个部分功能：

l  UI功能：展示Task的状态信息，就是MVC的V部分了。

l  Mgr功能：接收来着UI的请求，这个更像是MVC中C部分。

l  Task功能：完成任务，并将进度和结果报告给Mgr或UI，就是MVC中的M部分。

这个问题可以有三种模型进行表示：直接模型、交织模型和垂直模型。

1.1.1 直接模型

                                                              

                      图1 直接模型

         这种我相信是最原始的，也是最简单的。UI中直接和Task交互，而不需要Mgr的介入。由于这种模型是同步阻塞行的，所以使用的范围比较小。后来将Task的执行放到线程中，这样就可以很好做好的异步性。但是由于UI和Task直接交互，因此他们之间的耦合度是可想而知的。这种模型比较适合在小项目中使用。为了让系统有更好的灵活性和拓展性，也为了能让开发速度更快，有比较将这两部分进行隔离。我们通常的做法是将Task进行抽象，同时在UI和Task之间通过Mgr来关联。有人会问Mgr的介入是不是增加的复杂性，我想说是的。毕竟我们需要考虑的元素多起来了，那么他们之间的协作也会增加。就像是一个部门，原本部门刚建设时，人员并不是很多，Boss可以之间将任务交给某个员工进行，而现在林子大了，Boss直接将任务交于某些员工负责的情况越来越难了，通常情况下都是交给专门的负责人进行，然后由负责人发配到具体的某位员工了。Mgr就是相当于上面说的负责人了。你现在可以想想你的直接领导都干什么事来着了。我们在这里可以将UI看着是产品负责人，而Mgr是项目负责人，你就是一个Task了。他们这三者之间的关系可以依据Task的通知方式分为交织和垂直模型来表示。

1.1.2 交织模型

         如图2所示，这种模型更像经典的MVC模型了。Task的状态改变直接通知UI进行更新。在实际的设计中，我们并不是简单的通过Event的方式通知UI，然后让UI去获取一次Task的状态进行的。而是一般通过回调的方式，将状态信息传递给UI进行更新的。在这个模型中Mgr只是负责将请求传递给Task，以及Task的管理。和垂直模型的区别和比较会在总结进行分析。

                                                                                    图2 循环模型

        

1.1.3 垂直模型

         如图3所示，我们看到Task并没有和UI之间有直接的联系，而是完全通过Mgr完成通知的。Mgr就好像是中介来着，UI看不到Task，Task也不知道UI。

图3 垂直模型

1.1.4 总结

每种模型都有优缺点，和试用的场景和范围。

直接模型：

l  优点：简单。

l  缺点：小项目，无需考虑扩展性。

交织模型：

l  优点：扩展性好，系统层次分明，相比垂直模型，在向UI通知上更加的快捷。

l  缺点：正是由于Task直接向UI通知，所以不可避免的需要UI方面协调通知接口。

金山的softmgr使用的是这种模型。

垂直模型：

l  优点：和交织模型相比较，有点就是UI和Task完成分隔开了。他们直接没有任何的联系，完全通过Mgr进行转发。

l  缺点：这个还是在Notify上面，由于使用Mgr来转发，那就会设计UI和Mgr的协商，以及Mgr和Task之间的协商了，多一层协商过程，这个主要是在Notfiy的接口设计上的问题。

这个例子可以查阅客户端产品中安全检测相关代码。

应该采用何种Notify方式是个很让人困惑的问题：如果需要Mgr及时知道Task的状态的话，可以采用垂直模型，我认为还是采用交织模型比较好。