没关系.但是如果模型类变得太大,有时我会创建一个"管理器"对象来推卸出模型类的一些责任.例如:
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)
您甚至可以使用接口,子类User和PermissionManager类,并根据实例(也称为工厂方法)在层次结构中创建不同的类型
减轻模型的另一种方法是使用Traits.Laravel本身在应用程序的各个部分使用特征; 看一下核心类,看看它们是如何被使用的.由于种种原因,很多人不喜欢特征,我刚刚提出的方法的优点是它更明确地使用特征而不易发生冲突
意见很少,但我认为保留用户相关逻辑是可以的。至少我在真正的大项目中看到了完全相同的方法,其中有很多臃肿的控制器/模型类。使用单一责任原则是一个好主意,但使用时不要狂热。过度设计是邪恶的。
| 归档时间: |
|
| 查看次数: |
1093 次 |
| 最近记录: |