我决定重新创建我在 Laravel 中的现有网站，作为了解框架如何工作的一种方式，但遇到了一个我似乎无法得到适当解释的问题。
我目前使用自己构建的自定义 MVC 框架。目前，我将拥有一个包含大量业务逻辑的“模型”。例如，在我的 UserModel 中，我拥有与数据库交互的所有函数，但我也有许多其他与用户相关但与数据库没有交互的函数。
可以把这段代码放到 Eloquent 模型中吗？
【问题讨论】：
标签： php laravel oop laravel-5 eloquent
没关系。但是如果模型类变得太大，有时我会创建一个“管理器”对象来消除模型类的一些责任。例如：
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 本身在应用程序的各个部分都使用了特征；查看核心类以了解它们的使用方式。由于各种原因，许多人不太喜欢 trait，我刚刚提出的方法的优点是它比使用 trait 更明确，更不容易发生冲突
【讨论】：
意见很少，但我认为保留用户相关逻辑是可以的。至少我在非常大的项目中看到了完全相同的方法，其中有很多臃肿的控制器/模型类。使用单一职责原则是个好主意，但在使用时不要狂热。过度工程是邪恶的。
【讨论】：
我建议您使用traits。你可以在你的应用目录中有一个traits 文件夹。然后，我会将每个函数分类到其单独的文件夹中，例如：
app/traits/database文件夹中。app/traits/misc文件夹中。然后我将创建一个名为UserFunctions.php的抽象类，它将包含所有特征。然后我将使用抽象类扩展我的用户模型。
class User extends BaseUser,UserFunctions
【讨论】：