雄辩的 ORM 控制器或模型

Posted 2023-04-12

【中文标题】雄辩的 ORM 控制器或模型

【英文标题】：eloquent ORM controller or model

【发布时间】：2014-07-17 07:29:50

【问题描述】：

我正在编写一个 Web 应用程序，我自称是一个杂乱无章的开发人员，我写东西很快，担心以后的维护。我目前正在使用 laravel，我有很多数据库交互，所有 eloquent 的示例似乎都直接在控制器中与数据库对象交互。这是最好的选择，还是更有条理地将这些雄辩的方法包装在模型中用于该相关查询的函数中。例如

class HomeController extends \BaseController 

    public function index()
    
         $user = User::find(1);
         return $user;
    

这样会更好吗，

class HomeController extends \BaseController 

    public function index()
    
         $user = new User;
         $result = $user->getSingleUser(1); //Being a method in the User.php model
         return $result;
    

我意识到这是非常基本的示例，但出于组织目的，最好将数据库和“业务逻辑”与控制器分开吗？

【参考方案1】：

但出于组织目的，最好将数据库分开 和“业务逻辑”远离控制器？

是的

这样会更好吗，

是的 - 您应该将您的逻辑分成正确的区域，以使代码更易于管理。

【参考方案2】：

这就是 MVC 模式适用的原因。将您的数据库请求存储在深处，如果您愿意，您也可以将模型层与数据库层分开。如果您对应用程序结构进行更多解耦，那么您的代码将更易于管理。

【讨论】：

其实“模型层”是the whole thing。您所指的通常（在非框架文献中）称为“领域层”或“领域模型”。

随意称呼它。解耦和分离是oop中的正确方式。框架中的模型当然可以是一个整体，但是你能把一个不代表业务逻辑的类称为模型吗？ ;-)

从哪里打电话？ “模型”不是一个类。

对不起，我应该说“你能说出它的名字”而不是“你能打电话”，但是类可以代表一个模型吗？ （我没说那个类是模型）

仅当您的整个应用程序是“匿名留言簿”.. 或类似规模的东西时，这将是对 MVC 架构模式的延迟使用。