【附加题】由结对编程想到的——电梯调度的MVC设计模式

【附加题】由结对编程想到的——电梯调度的MVC设计模式

在结对编程过程中，我们希望为这个程序提供一个UI，最后，我们做出了界面部分，但是它却十分不符合MVC的设计思路，究其原因，我们认为有两点，一个是主观因素，即我们小组的能力，一个是客观因素，即现行的电梯调度测试程序在未经大规模改进后不能后很好的符合MVC的设计模式。

主观因素

首先，从最初分工上，我们组由于时间原因，最后留给UI开发的时间很少（1天。。），同时，三人中唯一了解MVC的殷同学正在苦逼的赶各种文档…..所以，最后做出的成品不是非常符合MVC的设计理念。

在UI设计过程中，我们发现：程序的各个模块都是NameSpace级别的（World，Scheduler，Passenger….），我们的UI是在World NameSpace下的，而World依赖于Passenger，我们想让乘客在发出乘梯请求后，给UI一个信号，但是却陷入了循环引用的僵局中….各种各样的问题层出不穷，无奈最终的结果不能很好的达成设计标准。

客观因素

客观因素是本次吐槽的重点。首先，明白了MVC，就必须分清楚整个程序，哪部分是Model，View，Controller，我们知道，MVC的设计模式多见诸网站架构中。首先用户的Web Request发送给控制器Controller，控制器捕获请求后传给相应的Model处理，Model完成业务逻辑后给View，回显用户结果。从这个过程中，我们可以看出，用户是面向界面请求的，然后返回的结果也是通过界面呈现的。然而，电梯测试程序中，请求是通过XML读入的，结果是通过界面呈现的，这样，程序就不是“一问一答”的典型MVC模式，在这种情况下，我们十分不解：实现MVC有何意义？！

 

同时，从整个程序的架构上，我们也发现：用户请求是直接传给电梯的

IRequest req = new PassengerReq(

               RequestType.DirectionReq, nowTicks, _SourceFloor, this.UpDown);

    RegElevatorStopNotify(elevs);

return req;

 

从MVC的角度出发，这样的请求应该是给一个Dispatcher之类的，然后再给电梯，但是这样做纯属画蛇添足。

在整个程序集上实现MVC是不现实的，我们又想在Scheduler内部实现MVC，具体即：对于测试程序送达的请求，由中控函数assignReq处理，它的作用是实现四台电梯的“负载均衡”：根据算法选择一台电梯响应用户应答，相当于Controller的角色：

而四台电梯，每一台都有单独的控制逻辑，是一个状态机，对于中控函数送达的请求，按照特定算法一个个的响应，相当于Model的角色，而View，就是界面了。这样，我们从这种角度出发，实现了不完整的MVC。

这次的尝试给了我们深刻的教训，我认为，MVC的最佳应用领域是“请求驱动式”的程序，而且这个请求的来源最好也是通过View上的某些按钮、链接触发的，MVC的最佳领域是WEB程序，对于只强调业务逻辑的程序，如电梯调度程序而言，还是不尝试为好。