MVC的历史
模型 - 视图 - 控制器 一直沿用自20世纪70年代后期和在Xerox PARC，它被认为是一种方式来组织一些早期的GUI应用程序Smalltalk的项目出现。一些原来MVC模式的精细细节的被捆绑到特定的Smalltalk-概念，如 屏幕 和 工具， 但更广泛的概念仍然适用于应用程序，它们特别适合于Web应用程序。
了解MVC模式
在高层次来看，MVC模式意味着MVC应用程序将被分成至少三段。
- 模型， 含有或表示用户使用的数据
- 视图， 这是用来渲染模型的某些部分作为用户界面
- 控制器， 其中处理传入的请求，在模型上执行操作，并选择视图来呈现给用户
每一块MVC架构的是明确定义和自包含的，其被称为关注点分离。 操纵模型中的数据的逻辑包含 只要 在模型中，显示数据，所述逻辑 在视图中，和处理用户请求，并输入该代码被包含只要 在控制器中。随着各构件之间分工明确，你的应用程序会更容易维护和扩展在其一生中，不管它有多大成为。
了解模型
模型-的 中号 在 MVC -contain用户使用的数据。有两大类模型：视图模型， 这表示刚刚从数据控制器向视图过去了，域模型， 包含数
据在业务域中，与操作，转换，和用于创建，存储和操纵数据规则一起，统称为 模型的逻辑。
模型是应用程序的工作原理在宇宙中的定义，在一个银行应用程序，例如，该模型代表了该应用程序支持的银行，如账户，总账，并为客户提供信用额度的一切，还有可用于操纵模型中的数据，如存入资金，并从账户提款操作。该模型还负责维护的整体状态和数据，例如一致性，确保所有交易都加入到总账和客户不收回更多的钱比他有权或更多的钱比银行具有。
对于每一个在MVC模式的组成部分，我将描述什么应该和不应该被包括在内。在应用程序的模型中使用MVC模式建造
- 应该
- 包含域数据
- 包含所述逻辑用于创建，管理，以及修改所述数据域
- 提供一个干净的API，它暴露了它的模型该模型数据和操作
- 不应该
- 暴露的如何模型数据获得或管理的信息（换言之，数据存储机构的细节不应该被暴露到控制器和视图）
- 包含逻辑变换基于用户交互模型（因为这是控制器的工作）
- 包含逻辑，用于显示数据显示给用户（即该视图的作业）
确保该模型从控制器分离和观点的好处是，你可以测试你的逻辑更容易，并且增强和保持整个应用程序更简单，更容易。
许多开发新的MVC模式感到困惑与包括在数据模型的逻辑，认为MVC模式的目的是将数据从逻辑分离开的想法。这是一个误解：MVC模式的目标是一个应用程序分成三个功能区，其中的每一个可以同时包含逻辑 和 数据。我们的目标是不是从模型中消除逻辑。相反，它是为了确保模型只包含逻辑用于创建和管理模型数据。
了解控制器
控制器是在MVC模式结缔组织，作为数据模型和视图之间的导管。控制器定义提供操作的数据模型和提供观看显示给用户的数据
的业务逻辑的动作。
使用MVC模式构建的控制器
- 应该
- 更新模型包括所需的行动基于用户交互控制器
- 不应该
- 包含管理数据的外观逻辑（即该视图的作业）
- 包含管理数据的持久性逻辑（即模型的作业）
了解视图
视图包含于显示数据给用户或，以便它可以由控制器动作进行处理，以从用户获取数据所需的逻辑。查看
- 应该
- 包含对数据呈现给用户浏览所需的逻辑和标记
- 不应该
- 包含复杂的逻辑（这最好放在一个控制器）
- 包含创建，存储或操纵的域模型视图逻辑 能够 包含的逻辑，但它应该是简单和节约地使用。把任何东西，但在视图中最简单的方法调用或表达式使得整个应用程序难以测试和维护。
网友评论