Yii2.0框架 MVC 最佳实践

keithxiaoy 发布于2019-06-28 18:47 / 476人阅读

摘要：框架最佳实践最佳实践在设计良好的应用中，控制器很精练，包含的操作代码简短如果你的控制器很复杂，通常意味着需要重构，转移一些代码到其他类中。层业务逻辑层框架由，，组成，执行流程一般是在访问获取数据，通过渲染页面。

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. 单个模型中避免太多的场景

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

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

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

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

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层处理。

云服务器 GPU云服务器最佳实践 webrtc最佳实践 cdn最佳实践 vpc最佳实践

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/28658.html

【译】前端练级攻略

摘要：由于系统变得越来越复杂，人们提出了称为预处理器和后处理器的工具来管理复杂性。后处理器在由预处理器手写或编译后对应用更改。我之前建议的文章，，也涵盖了预处理器相关的知识。译者：前端小智原文：medium.freecodecamp.org/from-zero-t… medium.freecodecamp.org/from-zero-t… 我记得我刚开始学习前端开发的时候。我看到了很多文章及...

wuyumin 2019-05-22 16:41 评论0 收藏0
[译] 前端攻略-从路人甲到英雄无敌二：JavaScript 与不断演化的框架

摘要：一般来说，声明式编程关注于发生了啥，而命令式则同时关注与咋发生的。声明式编程可以较好地解决这个问题，刚才提到的比较麻烦的元素选择这个动作可以交托给框架或者库区处理，这样就能让开发者专注于发生了啥，这里推荐一波与。本文翻译自FreeCodeCamp的from-zero-to-front-end-hero-part。继续译者的废话，这篇文章是前端攻略-从路人甲到英雄无敌的下半部分，在...

roadtogeek 2019-08-19 18:25 评论0 收藏0
前端练级攻略(第二部分)

摘要：是文档的一种表示结构。这些任务大部分都是基于它。这个实践的重点是把你在前端练级攻略第部分中学到的一些东西和结合起来。一旦你进入框架部分，你将更好地理解并使用它们。到目前为止，你一直在使用进行操作。它是在前端系统像今天这样复杂之前编写的。本文是前端练级攻略第二部分，第一部分请看下面：前端练级攻略(第一部分) 在第二部分，我们将重点学习 JavaScript 作为一种独立的语言，如...

BWrong 2019-08-23 16:49 评论0 收藏0
Android架构 - 收藏集 - 掘金

摘要：代码不会写的很复杂架构思考模块化多进程掘金关于模块化组件化这个问题，我想每个开发者可能都认真的思考过。今天，我安居客项目架构演进掘金本文已授权微信公众号独家发布。关于 Dagger2+Mvp+rxjava+retroft2.0 的一点实践 - Android - 掘金前言做这个项目的初衷是想练手，因为现在rxjava+retrofit框架相当火，而公司的同事正在用这个框架也觉得很方便...

honmaple 2019-06-24 17:54 评论0 收藏0