Yii2.0框架 MVC 最佳实践

Controller最佳实践

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

控制器职责

1. 可访问 请求 数据

// GET参数
$get = Yii::$app->getRequest()->get();
$get = Yii::$app->getRequest()->getQueryParams();
// POST参数
$post = Yii::$app->getRequest()->post();
$post = Yii::$app->getRequest()->getBodyParams();

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

$searchModel = new ArticleSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);

$websiteKv = Website::kv('id', 'title');

$model = $this->findModel($id);
$model->load(Yii::$app->request->post());
$model->save()

3. 可使用 视图 构造响应

return $this->render('edit', [
    'model' => $model,
    'subjectKv' => $subjectKv
]);

4. 不应处理应被模型处理的请求数据

例如，将表单提交的 Y-m-d 时间格式转换为时间戳等，放到模型中进行处理。

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

Model最佳实践

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

模型职责

1. 可包含属性来展示业务数据

主要是数据表字段映射到模型类中的属性，可适当增加自定义public属性。

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

rules() 方法等

3. 可包含方法实现业务逻辑

public function getSubject()
{
    return $this->hasOne(Subject::className(), ['sid' => 'sid']);
}

public function getMedia()
{
    return $this->hasMany(ArticleMedia::className(), ['aid' => 'aid']);
}

public function updateStatus($status)
{
    return $this->updateAttributes(['status' => $status]);
}

4. 不应直接访问请求，Session和其他环境数据，这些数据应该由控制器传入到模型

不允许使用任何 Yii::$app->getRequest() 下的方法，只可在控制器中使用。

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

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

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

1. 定义可被多个 应用主体 或 模块 共享的的模型基类集合。这些模型类应包含通用的最小规则集合和逻辑。
2. 在每个使用模型的 应用主体 或 模块中， 通过继承对应的模型基类来定义具体的模型类， 具体模型类包含应用主体或模块指定的规则和逻辑。

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

View最佳实践

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

视图职责

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

2. 不应包含执行数据查询代码，这种代码放在模型中

当在 GridView 中感觉需要使用数据库查询时，首先要想一想通过联表（with(),joinWith()）是否能替代该查询。若能，则使用联表；若不能，可适当使用数据查询。

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

4. 可读取模型属性，但不应修改它们

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

• 使用 布局 来展示公共代码（如，页面头部、尾部）；
• 将复杂的视图分成几个小视图，可使用上面描述的渲染方法将这些 小视图渲染并组装成大视图；
• 创建并使用 小部件 作为视图的数据块；
• 创建并使用助手类在视图中转换和格式化数据。

Service层（业务逻辑层）

MVC框架由Model，View，Controller组成，执行流程一般是：在Controller访问Model获取数据，通过View渲染页面。

MVC模式是Web开发中的基础模式，采用的是分层设计，各层之间职责分明。然而事与愿违，当我们日积月累的基于MVC模式开发之后，会逐渐的感受到层与层之间存在粘连和职责模棱两可的地方，这就是Service层出现的重要原因。

Yii2框架建议将大部分业务逻辑放到模型类中，当业务逻辑比较简单时，这样确实能使代码结构清晰，又增加了代码的复用率。但是在开发大型复杂系统时，业务逻辑会比较复杂，模型类的代码量会非常大，通常又会涉及到多个模型类，增大了模型类之间的耦合，不利于维护。

Service职责

1. 对模型类进行解耦

把需要多个model参与的复杂业务逻辑单独封装出来，这些model之间不再发生直接的依赖，而是在Service层内协同完成逻辑。

2. 简化模型类的业务逻辑

模型类应该只处理简单的业务逻辑，当方法的业务逻辑比较复杂时（例如一些统计功能的静态方法等），建议将该业务逻辑放到Service层处理。