Utiliser ThinkPhp3.2 pour le développement, car nous devons souvent utiliser des opérations d'ajout, de suppression, de modification et de recherche afin d'augmenter la réutilisation du code. J'ai écrit un curdControler et curdModel en commun pour effectuer l'ajout, la suppression, la modification et l'interrogation du code. Lorsque j'ai besoin d'utiliser l'ajout, la suppression, la modification et l'interrogation, j'hérite directement de curdController et curdModel.
Maintenant, il y a un problème. Généralement, l'opération de caillé nécessite un jugement d'autorisation, sinon ce sera très dangereux. Mon idée ici est d'appeler un checkAuth() dans la méthode de construction curdController ; en raison de diverses fonctions et méthodes de contrôle des autorisations, comment puis-je forcer les sous-classes qui héritent de curdController à surcharger la méthode checkAuth ?
Mon idée est de définir la fonction de jugement de permission comme une méthode abstraite
protected abstract function checkAuth()
La classe curdController est définie comme une classe abstraite, mais si la classe abstraite ne peut pas être instanciée, alors le code du constructeur sera invalide. Quel est le problème avec cette implémentation ?
Deuxième question, avez-vous de meilleures idées lors de la réutilisation du code TP ? Quels sont les dangers et les problèmes cachés de mon approche ? Merci pour vos conseils.
class CurdController extends Controller
{
//基础curd类必须进行权限判断,否则会造成很大的问题
public function __construct()
{
parent::__construct();
$this->checkAuth();
}
//存储模型对象
protected $_model;
//权限判断函数
protected function checkAuth(){}
//列表处理函数
public function listC(){
// 列表前置函数
$this->beforeList();
$data=$this->_model->lists();
$this->assign('lists',$data);
$this->display();
}
public function delC(){
$id=intval(I('get.id'));
$where['id']=$id;
$res=$this->_model->del($where);
$this->redirectUrl($res,'listC');
}
public function addC(){
// 添加前置函数
$this->beforeAdd();
if(IS_POST){
$data=I('post.');
$res=$this->_model->Store($data);
$this->redirectUrl($res,'listC');
}
$this->display();
}
public function editC(){
$id=intval(I('get.id'));
//where的数组形式
$where['id']=$id;
// 编辑前置函数
$this->beforeEdit($where);
if(IS_POST){
$where=I('post.');
$where['id']=$id;
$res=$this->_model->Store($where);
$this->redirectUrl($res,'listC');
}
$this->display();
}
//列表前置操作
protected function beforeList(){
}
/**
* 添加控制器前置操作
*/
protected function beforeAdd(){
}
/**
* 编辑控制器前置操作
* @param $where
*/
protected function beforeEdit($where){
}
Pour réutiliser le code, je recommande d'utiliser les fonctionnalités PHP :
http://php.net/manual/zh/lang...
Ou d'utiliser la liaison de fermeture (non recommandé) :
http://php.net /manual/en /clos...
checkAuth
可以通过不同的业务,书写不同的traits,在具体继承curdController的类中使用对应的traits,由于checkAuth()
只返回校验结果的真假,所以这个可以向任意的Controller中定制checkAuth()
.En réponse à votre première question, puisque vous héritez d'une classe abstraite
.curdController
的子类构造函数里,手动调用了parent::__construct();
, tant que la sous-classe est instanciée, le constructeur de la classe parent est également disponible Voir l'exemple ci-dessous :Code :
Résultat :
En réponse à votre deuxième question, j'estime personnellement que l'ensemble du cadre structurel est un peu approximatif. Les relations communes un-à-plusieurs et plusieurs-à-plusieurs doivent encore être effectuées manuellement. Il est recommandé d'encapsuler cette opération d'association.
Bien que le framework que j'utilise personnellement le plus soit le package de réutilisation made in
CodeIgniter
,但是我觉得MVC(HMVC)模型基本思路都是一致的,所以下面谈下我个人在CodeIgniter
:J'ai personnellement placé les opérations atomiques de la table de données dans la couche inférieure
.Model
上面(是基于CI-Base-Model
改的,你可以看一下CI-Base-Model
里的has_many
和belongs_to
配置),另外我继承了CI-Base-Model
自己写了一个CRUD_Model
,这个CRUD_Model
Presque en m'appuyant sur certains éléments de configuration et quelques réécritures, je peux rapidement générer un tableau CRUD standard. Une partie du code source peut être publiée ci-dessous :J'espère que l'idée de mon modèle pourra vous aider à affiner la logique CRUD.