MVC架构

Posted 2021-05-01 小谢backup

MVC 持久存储模式

有许多不同的方式通过 MVC 框架实现持久存储，每一种都有不同的优缺点。当您编写 Chrome 应用时，选择您觉得最自然并且最适合您的应用需要的 MVC 与持久模式框架。

模型自己进行持久存储——ActiveRecord 模式

在诸如 Ruby on Rails 的服务器端框架以及诸如 Backbone.js 和 ember.js 之类的客户端框架中 ActiveRecord 模式都很流行，它将持久存储的责任放在了模型自身上，通常通过 JSON API 实现。

与让模型处理持久存储有所区别的方式是引入单独的存储区与适配器 API 的概念。存储区、模型与适配器（在某些框架中称为代理）同时工作。存储区是包含已加载模型的库，并提供诸如创建、查询及过滤包含在其中的模型实例的功能。

适配器或代理从存储区接收请求，并将它转换为对您的持久数据层（例如 JSON API）进行的适当操作。这种方式在现代网络应用设计中十分有意义，因为您经常与不止一个持久数据层交互，例如远程服务器与浏览器的本地存储区。Chrome 应用为客户端存储提供了 Chrome 浏览器的存储 API 与html5 文件系统 API。

优势：

• 使用简单，易于理解。

缺点：

• 测试困难，因为持久存储层混合在对象架构内。

• 让不同的对象使用不同的持久存储区比较困难（例如文件系统 API、IndexedDB 与服务器端）。

• 在其他应用程序中重用模型可能会带来冲突，例如在两个不同的视图中共享一个顾客类，每一个视图都希望保存到不同的位置。

控制器进行持久存储

在这种模式中，控制器包含对模型与数据存储区的引用，并负责保持模型持久存储。控制器对诸如加载、保存、删除之类的生命周期事件作出响应，并向数据存储区发送命令以便获取或更新模型。

优势：

• 方便测试，可以向控制器传递一个伪数据存储区写入测试内容。

• 同样的模型可以与多个数据存储区重用，只要构造具有不同数据存储区的控制器。

缺点：

• 代码维护起来可能会更复杂。

应用控制器进行持久存储

在某些模式中，有一个超级控制器，负责在一个 MVC 与另一个之间导航。例如应用控制器决定“后退”按钮将客户端从编辑屏幕（包含 MVC 小工具/格式）移动至设置屏幕。

在应用控制器模式中，应用控制器响应事件，并通过向数据存储区发出调用，加载所需的模型并构造所有匹配视图及控制器的方式更改应用的当前屏幕。

优势：

• 将持久存储层移到更高的层次，这样更容易修改。

• 不会污染较低级的控制器，例如日期选择器控制器，使它需要了解持久存储。

缺点：

• 应用程序的每一个“页面/屏幕”现在都需要编写或更新大量公共代码：模型、视图、控制器、应用程序控制器。

推荐的 MVC 框架

MVC 对于设计 Chrome 应用是至关重要的。我们推荐如下遵循 CSP（内容安全策略）的 MVC 框架，用于编写安全而且可伸缩的 Chrome 应用：

• AngularJS （Text Drive 参考应用 和 用 AngularJS 建立应用的教程）

• Kendo UI （Photo Booth 参考应用）

• Sencha （Video Player 参考应用 和 用 Sencha Ext JS 建立应用程序的教程）