Laravel中大型模型的最佳实践

Mar*_*rah 4 php oop laravel eloquent laravel-5

我已经决定重新创建一个我在Laravel中的现有网站,作为学习框架如何工作的方法,并且遇到了一个我似乎无法得到合适解释的问题.

我目前使用我构建的自定义MVC框架.目前,我将拥有一个拥有大量业务逻辑的"模型".因此,例如,在我的UserModel中,我拥有与数据库交互的所有函数,但我还有许多与用户相关但没有与数据库交互的其他函数.

是否可以将此代码放入Eloquent模型中?

Mop*_*ppo 5

没关系.但是如果模型类变得太大,有时我会创建一个"管理器"对象来推卸出模型类的一些责任.例如:

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
    }
}
Run Code Online (Sandbox Code Playgroud)

这些管理器对象与用户模型严格相关,实际上您将模型的依赖关系传递给经理类的构造函数,但主要的好处是您可以避免创建"上帝"类并使用对象组合来保持责任分散.

使用此结构,您可以调用:

$user->permissionManager->hasAccessTo( $resource );
Run Code Online (Sandbox Code Playgroud)

您甚至可以使用接口,子类UserPermissionManager类,并根据实例(也称为工厂方法)在层次结构中创建不同的类型

减轻模型的另一种方法是使用Traits.Laravel本身在应用程序的各个部分使用特征; 看一下核心类,看看它们是如何被使用的.由于种种原因,很多人不喜欢特征,我刚刚提出的方法的优点是它更明确地使用特征而不易发生冲突


Ale*_*nin 3

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