控制器最佳实践在一个设计良好的应用中，控制器非常简洁，包含简短的操作代码；如果你的控制器很复杂，通常意味着重构，将一些代码转移到其他类中。控制器职责1.可访问的请求数据//GET参数$get=Yii::$app->getRequest()->get();$get=Yii::$app->getRequest()->getQueryParams();//POST参数$post=Yii::$app->getRequest()->post();$post=Yii::$app->getRequest()->getBodyParams();2、可以根据请求数据调用Model方法和其他服务组件$searchModel=newArticleSearch();$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.可用视图构造响应返回$this->render('edit',['model'=>$model,'subjectKv'=>$subjectKv]);4.不应该处理该模型应该处理的请求数据比如表单提交的Y-m-d时间格式转换为时间戳等，放入模型处理。5.避免嵌入HTML或其他显示代码。这些代码最好在视图中处理。最佳实践模型是代表业务数据、规则和逻辑的中心位置。它通常在许多地方重复使用。在一个设计良好的应用程序中，模型通常比控制器有更多的代码。模型职责1.可以包含显示业务数据的属性。主要是数据表字段映射到模型类的属性，可以适当增加自定义的公共属性。2.可以包含验证规则以确保数据有效和完整rules()方法等3.可以包含实现业务逻辑的方法publicfunctiongetSubject(){return$this->hasOne(Subject::className(),['sid'=>'sid']);}publicfunctiongetMedia(){return$this->hasMany(ArticleMedia::className(),['aid'=>'aid']);}publicfunctionupdateStatus($status){return$this->updateAttributes(['status'=>$status]);}4.Request、Session等环境数据不应该直接访问，这些数据应该由controller传递给model。任何Yii::$app都不允许->getRequest()下的方法只能在控制器中使用。5.应避免嵌入HTML或其他表示代码，这些代码最好在视图中处理6.避免在单个模型中使用太多场景在开发大型复杂系统时应始终考虑此建议它很大并且在很多地方使用，因此它将包含规则集和业务逻辑。最后，维护这些模型代码就成了噩梦，因为一个简单的修改就会影响到很多地方。为确保模型易于维护，最好使用以下策略。定义可由多个应用程序主体或模块共享的模型基类的集合。这些模型类应该包含一组通用的最小规则和逻辑。在每个使用模型的应用程序主体或模块中，通过继承相应的模型基类定义一个具体的模型类，具体的模型类包含应用程序主体或模块规定的规则和逻辑。例如，在高级应用模板中，可以定义一个模型基类common\models\Post，然后在前台应用中，定义并使用一个继承common\models\Post的具体模型类frontend\models\Post，以及后台应用中的backend\models\Post可以类似定义。有了这个策略，就知道frontend\models\Post只对应前台应用，修改了就不用担心修改影响后台应用了。ViewBestPracticeView负责将模型的数据以用户想要的格式展示View职责1.应该主要包括展示代码，比如HTML，以及简单的PHP代码来控制、格式化和渲染数据2.应该不包括执行数据查询的代码，这种代码放在模型中。当你觉得需要在GridView中使用数据库查询时，先想想是否可以用联表（with(),joinWith()）代替查询。如果可能，使用联合表；如果不是，请适当使用数据查询。3、避免直接访问请求数据，如$_GET、$_POST，应该在controller中执行。如果需要请求数据，则应由控制器将其推送到视图。4.模型属性可以读取，但不能修改5.为了使模型更容易维护，避免创建过于复杂或包含过多冗余代码的视图，可以按照以下方法来实现此目的：使用布局显示常用代码（如页眉和页尾）；view被分割成若干个小view，可以使用上面介绍的渲染方式渲染组装成一个大view；创建小部件并将其用作视图的数据块；助手类被创建并用于转换和格式化视图中的数据。Service层（业务逻辑层）MVC框架由Model、View、Controller组成。执行过程一般是：访问Controller中的Model获取数据，通过View渲染页面。MVC模型是Web开发中的基本模型。采用分层设计，各层职责明确。然而，事与愿违。随着时间的推移，我们基于MVC模型进行开发后，会逐渐感觉到层与层之间存在粘连和职责模糊。这是Service层出现的一个重要原因。Yii2框架建议将大部分业务逻辑放在模型类中。当业务逻辑比较简单的时候，这样确实可以让代码结构清晰，提高代码复用率。但是，在开发大型复杂系统时，业务逻辑会比较复杂，模型类的代码量会非常大，通常会涉及到多个模型类，增加了模型类之间的耦合度，不利于维护.服务职责1.模型类解耦，将需要多个模型参与的复杂业务逻辑单独封装。这些模型之间没有直接的依赖关系，而是在Service层协同完成逻辑。2.简化模型类的业务逻辑。模型类应该只处理简单的业务逻辑。当方法的业务逻辑比较复杂时（比如一些统计功能的静态方法等），建议将业务逻辑放在Service层处理。
