MVC模式.docVIP

模型-视图-控制器 上下文 许多计算机系统的用途都是从数据存储检索数据并将其显示给用户。在用户更改数据之后，系统再将更新 内容存储到数据存储中。因为关键的信息流发生在数据存储和用户界面之间，所以您可能倾向于将这两部分绑在一起，以减少编码量并提高应用程序性能。但是，这 种看起来自然而然的方法有一些大问题。一个问题是，用户界面的更改往往比数据存储系统的更改频繁得多。将数据和用户界面这两部分耦合在一起带来的另一个问 题是，业务应用程序往往会并入远不止数据传输功能的其他业务逻辑。 影响因素 下列影响因素作用于此上下文内的系统，在考虑问题的解决方案时必须协调这些因素 用 户界面逻辑的更改往往比业务逻辑频繁，尤其是在基于 Web 的应用程序中。例如，可能添加新的用户界面页，或者可能完全打乱现有的页面布局。毕竟，基于 Web 的瘦客户端应用程序的优点之一是可以随时更改用户界面，而不必重新分发应用程序。如果将显示代码和业务逻辑组合一起并放在单个对象中，则每次更改用户界面 时，都必须修改包含业务逻辑的对象。这很可能引入错误，并需要在对用户界面进行每个极小更改之后都要重新测试所有业务逻辑。 在某些情况下，应用程序以不同的方式显示同一数据。例如，分析员喜欢用电子表格视图显示数据，而管理人员喜欢用饼图显示相同的数据。在一些胖客户端用户界面中，常常用多个视图同时显示相同数据。如果用户在一个视图中更改了数据，则系统必须自动更新该数据的其他所有视图。 设计令人赏心悦目而有效的 HTML 页通常要求采用一套与开发复杂业务逻辑不同的技能。很少有人同时具有这两种技能。因此，将这两部分的开发工作分隔开来是最理想的。 用户界面活动通常由以下两部分组成：显示和更新。显示部分负责从数据源检索数据，并格式化数据以便进行显示。当用户基于该数据执行操作时，更新部分将控制权返回给业务逻辑，以便更新数据。 在 Web 应用程序中，单个页面请求将这两方面的工作组合在一起：与用户所选链接相关联的操作进行的处理，以及目标页面的显示。在许多情况下，目标页可能不与操作直 接相关。例如，假设有一个用于显示项目列表的简单 Web 应用程序。在将项目添加到列表或从列表中删除项目之后，用户将返回主列表页。因此，应用程序必须在执行两个有很大差异的命令（添加或删除）之后显示相同页 面（列表），而所有这些操作均在同一个 HTTP 请求内进行。 与业务逻辑相比，用户界面代码对设备的 依赖性往往更大。如果要将应用程序从基于浏览器的应用程序迁移到个人数字助理 (PDA) 或支持 Web 的手机上，则必须替换很多用户界面代码，而业务逻辑可能不受影响。这两部分的完全分离可以使迁移更快完成，并最大限度地降低将错误引入业务逻辑的风险。 通常，为用户界面创建自动测试比为业务逻辑更难、更耗时。因此，减少直接绑到用户界面中的代码量可提高应用程序的可测试性。 解决方案 Model-View-Controller (MVC) 模式基于用户输入将域的建模、显示和操作分为三个独立的类 [Burbeck92]： 模型。模型用于管理应用程序域的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）。 视图。视图用于管理信息的显示。 控制器。控制器用于解释用户的鼠标和键盘输入，以通知模型和/或视图进行相应的更改。 图 1 描述了这三个对象之间的结构关系。 图 1:MVC 类结构 请 务必注意，视图和控制器都依赖于模型。但是，模型既不依赖于视图，也不依赖于控制器。这是分离的主要优点之一。这样的分离允许模型在独立于可视表示功能的 情况下建立和测试。在许多胖客户端应用程序中，视图与控制器的分离是次要的，实际上，许多用户界面框架将角色实现为一个对象。另一方面，在 Web 应用程序中，视图（浏览器）与控制器（处理 HTTP 请求的服务器端组件）的分离是很好定义的。 Model-View-Controller 是 一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式。遗憾的是，此模式的普及导致了许多错误的描述。特别是在不同的上下文中，术语控制器已经用 于意指不同的事物。幸运的是，Web 应用程序的出现已经帮助消除了一些不明确性，因为视图与控制器的分离是如此明显。 变型 在 Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC) [Burbeck92] 中，Steve Burbeck 描述了 MVC 的两个变型：被动模型和主动模型。 当 一个控制器以独占方式操作模型时，将使用被动模型。控制器将修改模型，然后通知视图：模型已经更改，应该进行刷新（见图 2）。此情况下的模型完全