合作联系

商务QQ: 1903765595


友情链接

新浪微博

最佳实践

admin
2017-06-20 23:47:30

控制器

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


归纳起来,控制器:

  • 可访问 请求 数据;

  • 可根据请求数据调用 模型 的方法和其他服务组件;

  • 可使用 视图 构造响应;

  • 不应处理应被模型处理的请求数据;

  • 应避免嵌入HTML或其他展示代码,这些代码最好在 视图中处理.


模型

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


归纳起来,模型 


  • 可包含属性来展示业务数据;

  • 可包含验证规则确保数据有效和完整;

  • 可包含方法实现业务逻辑;

  • 不应直接访问请求,session和其他环境数据, 这些数据应该由控制器传入到模型;

  • 应避免嵌入HTML或其他展示代码,这些代码最好在 视图中处理;

  • 单个模型中避免太多的 场景


在开发大型复杂系统时应经常考虑最后一条建议, 在这些系统中,模型会很大并在很多地方使用,因此会包含需要规则集和业务逻辑, 最后维护这些模型代码成为一个噩梦, 因为一个简单修改会影响好多地方, 为确保模型好维护,最好使用以下策略:


定义可被多个 应用主体 或 模块 共享的模型基类集合。 这些模型类应包含通用的最小规则集合和逻辑。

在每个使用模型的 应用主体 或 模块中, 通过继承对应的模型基类来定义具体的模型类, 具体模型类包含应用主体或模块指定的规则和逻辑。

例如,在高级应用模板, 你可以定义一个模型基类`common\models\Post`, 然后在前台应用中,定义并使用一个继承`common\models\Post`的具体模型类`frontend\models\Post`, 在后台应用中可以类似地定义backend\models\Post。 通过这种策略,你清楚`frontend\models\Post`只对应前台应用, 如果你修改它,就无需担忧修改会影响后台应用。



视图

视图负责将模型的数据展示用户想要的格式,总之,视图


应主要包含展示代码,如HTML, 和简单的PHP代码来控制、格式化和渲染数据;

不应包含执行数据查询代码,这种代码放在模型中;

应避免直接访问请求数据,如` $_GET`,` $_POST`,这种应在控制器中执行, 如果需要请求数据,应由控制器推送到视图。

可读取模型属性,但不应修改它们。

为使模型更易于维护,避免创建太复杂或包含太多冗余代码的视图, 可遵循以下方法达到这个目标:


  • 使用 布局 来展示公共代码(如,页面头部、尾部);

  • 将复杂的视图分成几个小视图, 可使用上面描述的渲染方法将这些小视图渲染并组装成大视图;

  • 创建并使用 小部件 作为视图的数据块;

  • 创建并使用助手类在视图中转换和格式化数据。



上一篇: 没有了

下一篇: Activeform表单部分组件使用方法