Laravel中大型模型的最佳實踐

Question

我已經決定重新創建一個我在Laravel中的現有網站，作為學習框架如何工作的方法，並且遇到了一個我似乎無法得到合適解釋的問題。

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

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

Answer 1

沒關系。 但是如果模型類變得太大，有時我會創建一個“管理器”對象來推卸出模型類的一些責任。 例如：

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 2

很少有意見，但我認為將用戶相關邏輯保留在那里是可以的。 至少我在真正的大項目中看到了完全相同的方法，其中有很多膨脹的Controller / Model類。 使用單一責任原則是一個好主意，但在使用它時不要狂熱。 過度工程是邪惡的。

Answer 3

我建議你利用traits 。 您可以在app目錄中有一個traits文件夾。 然后我會將每個函數分類到其單獨的文件夾中，如：

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

然后我會創建一個名為UserFunctions.php的抽象類，它將包含所有特征。 然后我將使用抽象類擴展我的User模型。

class User extends BaseUser,UserFunctions