在界面框架中，使用MVC的设计模式是最合适方式。为什么这样说呢？因为M是model的缩写，就是表示模型意思。模型就是算法，业务逻辑，商业表示。这个是经常会变的，比如像银行开发一个超市积分系统，对不同来店刷卡的人员给不同的积分，这个是随着不同的时间会变化，像中秋节时购买月饼就可以多增加积分，这个变化就表现在模型上。V就是view的缩写，也就是视图，对用户来说就是界面。界面在一定时间内是稳定的，但随着用户需求变化就会产生更多的界面。比如用户一开始可以看到数据列表显示就已经很满足了，当他们用过一段时间之后，就会想能否提供一个图形来描述数据呢？这就是提出对界面的要求，也就是多视图。也就是说，一份数据之后对应多个视图，多个视图从不同的角度去了解数据。有了模型，还有了视图，就已经可以实现数据经过业务逻辑处理之后在视图上显示出来，基本上就是完成了整个软件的需求。但是用户对软件的要求，不但能看到，还需要互动。比如看到曲线时，想放大一点看到细节，那么就需要控制了。控制部分就抽象为Controller，缩写就为C。到此，MVC三者的职责就非常清楚，M描述数据逻辑处理，V表示处理之后的数据显示，C接收用户控制，并且把不同的控制传递给M或V。它们之中，最特别的就是M与V是没有直接的联系，业务逻辑处理不会在意界面是怎么样的呈现的，它只是实现最优化算法，或者最复杂的业务逻辑；反之，界面也不需要关心数据是怎么样处理的，只管根据用户需要而显示，同时多个视图都来源于同一份数据，因此也保证多个视图的显示是一致的。

有了上面的概念之后，就要实践了，只有实践才可以对理论进行理解，并且理解得更深入。特别在软件开发工作上，没有编写代码，只看理论，就像站在岸上学游泳，永远学不会游泳的。因为人在水里与岸感觉差别很大，水的密度比空的密度不是一个数量级大，而差别特别大。因此，凭空想像是不会得到实际的感受。在编程方面，也是一样，如果不亲手写代码，是很难体会到想像与实现之间的差距。往往有人说，像这个功能不就几行代码，花两三天就可以做出产品了吗。其实他所说的产品只是一个针对目前情况实现的演示产品，而不是实际可用、可维护、可复用、可测试的产品。一个软件产品在他们眼里只是着重点是可用性，而不考虑可维护、可复用、可测试。可维护是一个重要的指标，如果不能维护，一个软件产品很难成功，因为一个软件产品使用周期是很长的，10年是算短的，在这10年内，不同用户加进来，以及竞争对手的出现，对软件产品进行升级就是成为常有的事情。怎么样让软件产品更新更快，还能对旧用户进行兼容，还不让越改就越多BUG出现，这是一个有难度的事情。如果代码不考虑可维护性，就更加成为不可能完成的任务。可复用性就是节省软件的开发成本，这个比较关键，因为软件的开发效率就决定产品的定价。也就是决定了招标时，你的产品是否被中标的关键因素，一般在价格方面都起到50%以上作用。可测试就是软件的质量了，以及软件是否可维护的一项指标。因为一个软件产品开发持续达到10年，每一个月更新了，还要兼容旧的产品、旧的用户，那么怎么样保证兼容旧的产品呢？只能针对旧的产品进行回归测试，这个回归测试，如果是人工的，显然不全面，也不着实际。因此，自动化的测试是必然的选择，也只有自动化测试才可以更全面地测试，确保产品方方面面都已经符合原来的规则。并且自动化测试比人工来说，也更有效率，足以降低成本。

MVC设计模式