背景: 基于laravel的后台管理系统，CURD密集型业务问题：当直接在控制器方法中调用orm处理业务逻辑时，代码复用性差，控制器层很肥尝试解决１：新建一个model层，将原先在控制器中的处理逻辑移到model中，包括数据校验下面是model的基类class BaseModel implements Responsable,UniqueCheckable
{
// 业务模型应当都具备产生模型响应的能力
use ModelResponse;
// 当前业务CRUD操作密集，几乎都需要检验唯一性
use CheckUniqueness;
//业务模型以orm为驱动将数据进行持久化
protected static $orm = null;
// 一个业务模型能被一个id唯一标识
protected $primaryId;
public function __construct($primaryId){
$this->primaryId = $primaryId;
}
// 实现UniqueCheckable接口,子类必须重写该方法
public static function getPrimaryField(){
exit(static::class." doesn't implements getPrimaryField function");
}
}其他模型类中的属性都是为了实现具体的方法服务的，下面是其中一个model的定义：class Tables extends BaseModel
{
private $tenantId;
private $branchId;
protected static $orm = 'App\DAL\Tenant\Tables';
/**
* @param int $tenantId [商户id]
* @param int $branchId [门店id]
*/
public function __construct($tenantId , $branchId){
$this->tenantId = $tenantId;
$this->branchId = $branchId;
}
/**
* [参数初始化]
* @param array $data [description]
* @return [type] [description]
*/
public static function paramInit(array &$data){
$data['pricePerHour']= array_key_exists('pricePerHour',$data)?$data['pricePerHour']:0;
$data['minConsumption']= array_key_exists('minConsumption',$data)?$data['minConsumption']:0;
$data['number']= array_key_exists('number',$data)?$data['number']:0;
}
/**
* @param array $data [description]
*/
public function add(array $data){
// 请求参数初始化
static::paramInit($data);
// 业务规则校验
if(!static::isValueAllowed($this->branchId,'name',$data['name'])){
return static::response(false,'该桌台已经存在');
}
$table = static::$orm::create(['tenantId'=>$this->tenantId,
'branchId'=>$this->branchId,
'position'=>$data['position'],
'minConsumption'=>$data['minConsumption'],
'number'=>$data['number'],
'pricePerHour'=>$data['pricePerHour'],
'name'=>$data['name']
]);
return $table?static::response(true,$table):static::response(false,'数据写入失败');
}
}该方法的问题：model层只是业务逻辑的封装？但有新的需求就往model中加新的方法，然后在控制器中调用，那么这个model类不就只是方法的堆积？尝试解决２：initPHP框架中提出了dscv的架构，其实就是把业务逻辑放在service中，然后在控制器中调用service对象来完成请求的处理这种方法正在考虑实施尝试解决3: 在看到了这篇文章后:也许后端MVC的说法已经过时了，感觉作者正好说到了我的痛点，所以又打算把控制器层分割为控制器+service层，把model分割为使用orm的数据持久层和repository层。这几者之间的关系是repository调用orm进行数据持久化，service层通过repository实现相关操作，然后控制器层调用service处理请求。但是这时候对这个repository层感到疑惑，如果重新对orm实现的功能进行封装那么工作量将很大，而实际带来的好处也不是很显而易见的。所以我目前倾向于认为orm中对应的对象是数据库中的表，而repository对应的对象是领域驱动设计中谈到的entity或者aggregate，那么这个时候我是不是又该根据把m变为 领域层＋repository+基础设施层?这个问题已经纠结挺久了，谢谢各位大神的指教
添加回答
举报
0/150
提交
取消