Laravel 中大型模型的最佳实践

Question

我决定用Laravel重新创建一个现有的网站，以此学习框架的工作原理，并遇到了一个问题，无法得到一个合理的解释。

我目前使用一个自定义的MVC框架。现在我有一个“模型”，其中包含许多业务逻辑。例如，在我的UserModel中，我有与数据库交互的所有函数，但我还有许多其他与用户相关但不涉及数据库的函数。

将这些代码放入Eloquent模型中可行吗？

- Martin Currah

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本身在应用的各个部分中都使用了traits，请查看核心类以了解它们的用法。由于各种原因，很多人不太喜欢traits，但我提出的这种方法的优点是更明确，而且比使用traits不容易发生冲突。

- Moppo

---

我一直在尝试找出在Laravel中实现这个功能的最佳方式，我认为这可能是最清晰、最解耦的方式，它不会仅把特征（trait）功能硬塞到一个特定的类中。你几乎可以把它看作是一个“能力”类。 - Nick Bedford

Answer 2

虽然意见不多，但我认为在那里保留用户相关逻辑是可以的。至少在真正大型项目中，我看到了完全相同的方法，其中有很多臃肿的控制器/模型类。使用单一职责原则是一个好主意，但在使用时不要过于狂热。过度设计是有害的。

- Alexey Mezenin

Answer 3

我建议您使用traits。您可以在应用程序目录中创建一个traits文件夹。然后，我会将每个函数分类放在其单独的文件夹中，例如：

• 使用数据库的函数将位于app/traits/database文件夹中。
• 不使用数据库的函数将位于app/traits/misc文件夹中。

然后，我会创建一个名为UserFunctions.php的抽象类，其中包含所有traits。然后，我只需使用抽象类扩展我的用户模型。

class User extends BaseUser,UserFunctions   

- Raza Mehdi

---

如果您计划在多个模型中使用此代码，等等，应更多地使用特征。 - Mike Barwick