Laravel中的大型模型的最佳做法

Question

我已決定重新創建一個現有的Laravel站點，以此作爲了解框架如何工作並遇到問題的方法，我似乎無法得到一個合適的解釋。

我目前使用我構建的自定義MVC框架。目前，我將擁有一個擁有大量業務邏輯的「模型」。因此，例如，在我的UserModel中，我擁有所有與數據庫交互的功能，但我也有許多與用戶相關但與數據庫沒有交互的其他功能。

將此代碼放入Eloquent模型中可以嗎？

Answer 1

有幾個意見，但我認爲這是可以保持用戶相關的邏輯那裏。至少我在真正的大項目中看到了完全相同的方法，那裏有很多臃腫的控制器/模型類。使用單一職責原則是一個好主意，但在使用它時不要狂熱。過度工程是邪惡的。

Answer 2

沒關係。但是，如果模型類變得太大，有時候我會創建一個'管理者'對象來將模型類中的某些責任推出去。例如：

class User extends Model 
{ 
    protected $permissionManager; 

    public function __contruct(){ 

     //create a Manager object (in laravel create it through App:make) 
     $this->permissionManager = new PermissionManager($this); 
    } 
} 

class PermissionManager 
{ 
    protected $user; 

    public function __contruct(User $user){ 
     $this->user = $user; 
    } 

    public function hasAccessTo(Resource $res){ 
     //code 
    } 

    public function isManager(){ 
     //code 
    } 
} 

這些管理對象嚴格按照用戶模型相關，其實你通過模型來管理類的構造函數的依賴關係，但主要好處是，你避創建「神'課程並使用對象組合保持潛在的責任感。

有了這個結構，你可以撥打：

$user->permissionManager->hasAccessTo($resource); 

你甚至可以使用接口，子類時User和PermissionManager類，並創建您的層次不同類型取決於實例（又名工廠方法）

減輕模型的另一種方法是使用Traits。 Laravel本身在應用程序的各個部分使用特徵;看看核心課程，看看它們是如何使用的。由於各種原因，許多人不喜歡特質，我剛剛提出的方法的優點是，它比使用特性更不明顯，不太容易發生衝突

Answer 3

我建議你利用traits。您的應用目錄中可以有一個traits文件夾。然後，我會將每個功能分類到其單獨的文件夾中，例如：

• 使用數據庫的功能將位於app/traits/database文件夾中。
• 未使用數據庫的功能將位於app/traits/misc文件夾中。

然後，我會創建一個名爲UserFunctions.php的抽象類，它將包含所有特徵。然後，我將擴展我的用戶模型與抽象類。

class User extends BaseUser,UserFunctions