在界面框架中，使用MVC的设计模式是最合适方式。为什么这样说呢？由于M是model的缩写，就是表示模型意思。
模型就是算法，业务逻辑。商业表示。
这个是常常会变的，比方像银行开发一个超市积分系统，对不同来店刷卡的人员给不同的积分，这个是随着不同的时间会变化，像中秋节时购买月饼就能够多添加积分，这个变化就表如今模型上。
V就是view的缩写，也就是视图。对用户来说就是界面。
界面在一定时间内是稳定的。但随着用户需求变化就会产生很多其它的界面。比方用户一開始能够看到数据列表显示就已经非常满足了，当他们用过一段时间之后，就会想是否能提供一个图形来描写叙述数据呢？这就是提出对界面的要求，也就是多视图。
也就是说，一份数据之后相应多个视图，多个视图从不同的角度去了解数据。有了模型。还有了视图。就已经能够实现数据经过业务逻辑处理之后在视图上显示出来。基本上就是完毕了整个软件的需求。可是用户对软件的要求。不但能看到，还须要互动。比方看到曲线时。想放大一点看到细节，那么就须要控制了。控制部分就抽象为Controller。缩写就为C。到此，MVC三者的职责就非常清楚。M描写叙述数据逻辑处理。V表示处理之后的数据显示。C接收用户控制。而且把不同的控制传递给M或V。
它们之中，最特别的就是M与V是没有直接的联系，业务逻辑处理不会在意界面是怎么样的呈现的。它仅仅是实现最优化算法。或者最复杂的业务逻辑；反之。界面也不须要关心数据是怎么样处理的，仅仅管依据用户须要而显示。同一时候多个视图都来源于同一份数据，因此也保证多个视图的显示是一致的。
有了上面的概念之后，就要实践了，仅仅有实践才干够对理论进行理解，而且理解得更深入。特别在软件开发工作上，没有编写代码。仅仅看理论，就像站在岸上学游泳，永远学不会游泳的。由于人在水里与岸感觉区别非常大，水的密度比空的密度不是一个数量级大，而区别特别大。
因此，凭空想像是不会得到实际的感受。在编程方面。也是一样。假设不亲手写代码，是非常难体会到想像与实现之间的差距。往往有人说，像这个功能不就几行代码。花两三天就能够做出产品了吗。事实上他所说的产品仅仅是一个针对眼下情况实现的演示产品。而不是实际可用、可维护、可复用、可測试的产品。一个软件产品在他们眼里仅仅是着重点是可用性，而不考虑可维护、可复用、可測试。
可维护是一个重要的指标。假设不能维护，一个软件产品非常难成功，由于一个软件产品使用周期是非常长的。10年是算短的，在这10年内。不同用户加进来，以及竞争对手的出现，对软件产品进行升级就是成为常有的事情。
怎么样让软件产品更新更快，还能对旧用户进行兼容，还不让越改就越多BUG出现，这是一个有难度的事情。
假设代码不考虑可维护性。就更加成为不可能完毕的任务。可复用性就是节省软件的开发成本，这个比較关键，由于软件的开发效率就决定产品的定价。也就是决定了招标时，你的产品是否被中标的关键因素，一般在价格方面都起到50%以上作用。可測试就是软件的质量了，以及软件是否可维护的一项指标。由于一个软件产品开发持续达到10年，每个月更新了。还要兼容旧的产品、旧的用户，那么怎么样保证兼容旧的产品呢？仅仅能针对旧的产品进行回归測试。这个回归測试。假设是人工的，显然不全面。也不着实际。因此，自己主动化的測试是必定的选择，也仅仅有自己主动化測试才干够更全面地測试，确保产品方方面面都已经符合原来的规则。而且自己主动化測试比人工来说，也更有效率，足以减少成本。