背景:　基于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+基礎設施層?這個問題已經糾結挺久了，謝謝各位大神的指教