背景:　基于laravel的后臺管理系統(tǒng)，CURD密集型業(yè)務(wù)問題：當(dāng)直接在控制器方法中調(diào)用orm處理業(yè)務(wù)邏輯時，代碼復(fù)用性差，控制器層很肥嘗試解決１：新建一個model層，將原先在控制器中的處理邏輯移到model中，包括數(shù)據(jù)校驗(yàn)下面是model的基類class?BaseModel?implements?Responsable,UniqueCheckable { ??//?業(yè)務(wù)模型應(yīng)當(dāng)都具備產(chǎn)生模型響應(yīng)的能力 ??use?ModelResponse; ??//?當(dāng)前業(yè)務(wù)CRUD操作密集，幾乎都需要檢驗(yàn)唯一性 ??use?CheckUniqueness; ??//業(yè)務(wù)模型以orm為驅(qū)動將數(shù)據(jù)進(jìn)行持久化 ??protected?static?$orm?=?null; //?一個業(yè)務(wù)模型能被一個id唯一標(biāo)識 ??protected?$primaryId; ??public?function?__construct($primaryId){ ????$this->primaryId?=?$primaryId; ??} ?? //?實(shí)現(xiàn)UniqueCheckable接口,子類必須重寫該方法 ??public?static?function?getPrimaryField(){ ????exit(static::class."?doesn't?implements?getPrimaryField?function"); ??} }其他模型類中的屬性都是為了實(shí)現(xiàn)具體的方法服務(wù)的，下面是其中一個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; ????} ????/** ?????*?[參數(shù)初始化] ?????*?@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){ ??????//?請求參數(shù)初始化 ??????static::paramInit($data); ???????//?業(yè)務(wù)規(guī)則校驗(yàn) ??????if(!static::isValueAllowed($this->branchId,'name',$data['name'])){ ??????????return?static::response(false,'該桌臺已經(jīng)存在'); ??????} ??????$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,'數(shù)據(jù)寫入失敗'); ????} }該方法的問題：model層只是業(yè)務(wù)邏輯的封裝？但有新的需求就往model中加新的方法，然后在控制器中調(diào)用，那么這個model類不就只是方法的堆積？嘗試解決２：initPHP框架中提出了dscv的架構(gòu)，其實(shí)就是把業(yè)務(wù)邏輯放在service中，然后在控制器中調(diào)用service對象來完成請求的處理這種方法正在考慮實(shí)施嘗試解決3:　在看到了這篇文章后:也許后端MVC的說法已經(jīng)過時了，感覺作者正好說到了我的痛點(diǎn)，所以又打算把控制器層分割為控制器+service層，把model分割為使用orm的數(shù)據(jù)持久層和repository層。這幾者之間的關(guān)系是repository調(diào)用orm進(jìn)行數(shù)據(jù)持久化，service層通過repository實(shí)現(xiàn)相關(guān)操作，然后控制器層調(diào)用service處理請求。但是這時候?qū)@個repository層感到疑惑，如果重新對orm實(shí)現(xiàn)的功能進(jìn)行封裝那么工作量將很大，而實(shí)際帶來的好處也不是很顯而易見的。所以我目前傾向于認(rèn)為orm中對應(yīng)的對象是數(shù)據(jù)庫中的表，而repository對應(yīng)的對象是領(lǐng)域驅(qū)動設(shè)計中談到的entity或者aggregate，那么這個時候我是不是又該根據(jù)把m變?yōu)?領(lǐng)域?qū)樱玶epository+基礎(chǔ)設(shè)施層?這個問題已經(jīng)糾結(jié)挺久了，謝謝各位大神的指教