Yii2.0框架 MVC 最佳实践

ゝ一纸荒年。 2022-02-27 08:34 353阅读 0赞

# Yii2.0框架 MVC 最佳实践 #

## [Controller最佳实践][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最佳实践][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最佳实践][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层处理。

[Controller]: http://www.yiichina.com/doc/guide/2.0/structure-controllers#best-practices
[Model]: http://www.yiichina.com/doc/guide/2.0/structure-models#best-practices
[View]: http://www.yiichina.com/doc/guide/2.0/structure-views#best-practices