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

Laravel中大型模型的最佳实践

3 个答案: