控制器编程最佳实践

在设计良好的应用中，控制器很精练，包含的操作代码简短； 如果你的控制器很复杂，通常意味着需要重构， 转移一些代码到其他类中。

• 可访问 请求 数据;
• 可根据请求数据调用 模型 的方法和其他服务组件;
• 可使用 视图 构造响应;
• 不应处理应被模型处理的请求数据;
• 应避免嵌入HTML或其他展示代码，这些代码最好在 视图中处理。

模型编程最佳实践

模型是 MVC 模式中的一部分， 是代表业务数据、规则和逻辑的对象。
模型是代表业务数据、规则和逻辑的中心地方，通常在很多地方重用， 在一个设计良好的应用中，模型通常比 控制器代码多。

归纳起来，模型：

• 可包含属性来展示业务数据;
• 可包含验证规则确保数据有效和完整;
• 可包含方法实现业务逻辑;
• 不应直接访问请求，session和其他环境数据， 这些数据应该由控制器传入到模型;
• 应避免嵌入HTML或其他展示代码，这些代码最好在 视图中处理;
• 单个模型中避免太多的场景。
  在开发大型复杂系统时应经常考虑最后一条建议， 在这些系统中，模型会很大并在很多地方使用，因此会包含需要规则集和业务逻辑， 最后维护这些模型代码成为一个噩梦， 因为一个简单修改会影响好多地方， 为确保模型好维护，最好使用以下策略：

定义可被多个应用主体 或 模块 共享的模型基类集合。 这些模型类应包含通用的最小规则集合和逻辑。
在每个使用模型的 应用主体 或 模块中，通过继承对应的模型基类来定义具体的模型类， 具体模型类包含应用主体或模块指定的规则和逻辑。
例如，在高级应用模板， 你可以定义一个模型基类common\models\Post， 然后在前台应用中，定义并使用一个继承common\models\Post的具体模型类frontend\models\Post， 在后台应用中可以类似地定义backend\models\Post。 通过这种策略，你清楚frontend\models\Post只对应前台应用，如果你修改它， 就无需担忧修改会影响后台应用。

视图编程最佳实践

视图是 MVC 模式中的一部分。 它是展示数据到终端用户的代码，在网页应用中， 根据视图模板来创建视图，视图模板为PHP脚本文件， 主要包含HTML代码和展示类PHP代码，通过view应用组件来管理， 该组件主要提供通用方法帮助视图构造和渲染， 简单起见，我们称视图模板或视图模板文件为视图。
视图负责将模型的数据展示用户想要的格式，总之，视图：

• 应主要包含展示代码，如HTML, 和简单的PHP代码来控制、格式化和渲染数据；
• 不应包含执行数据查询代码，这种代码放在模型中；
• 应避免直接访问请求数据，如 $_GET, $_POST，这种应在控制器中执行， 如果需要请求数据，应由控制器推送到视图。
• 可读取模型属性，但不应修改它们。
• 为使模型更易于维护，避免创建太复杂或包含太多冗余代码的视图， 可遵循以下方法达到这个目标：
• 使用 布局 来展示公共代码（如，页面头部、尾部）；
• 将复杂的视图分成几个小视图，可使用上面描述的渲染方法将这些 小视图渲染并组装成大视图；
• 创建并使用 小部件 作为视图的数据块；
• 创建并使用助手类在视图中转换和格式化数据。