Laravel 中数据库查询构建器的位置

Posted 2023-03-14

【中文标题】Laravel 中数据库查询构建器的位置

【英文标题】：Place for database query builder in Laravel

【发布时间】：2017-03-27 21:29:42

【问题描述】：

我可以使用范围来执行与模型相关的基本查询（例如选择那些今天过生日的用户），范围显然放在 Eloquent Models 中并返回 Eloquent Query Builder 的实例。但是，如果我需要执行更复杂的查询，比如按电子邮件类型对大量电子邮件日志表进行分组、加入用户和电子邮件并应用一些聚合，该怎么办？由于查询的结果字段是混合的（电子邮件、电子邮件类型、用户、日志字段），我必须使用 Database Query Builder。我正在犹豫是否要给建设者打电话的最佳地点。

可以是主模型中的静态方法，我将其他表加入到：

    class ConcreteModel extends Model 

      public static function someQuery(): \Illuminate\Database\Query\Builder 
        return \DB::table('some_table')->join('something');
      

    

或者也许宁愿将这些东西放在需要它的服务中？

【问题讨论】：

控制器或服务可能是此类查询的好地方。

@linuxartisan 我害怕将任何业务逻辑弄乱我的控制器，这就是为什么我认为应该将查询放在消费服务中作为模型的替代品。

为什么不使用存储库模式？您可以轻松地分离业务逻辑和数据结构的层。

您也可以在模型上调用 join。您不必为此使用 DB 外观。

@Hilmi 但 Eloquent 将模型属性映射到特定表上，即每个模型一个表。使用带有连接的模型对我来说毫无意义（尽管我可能错了），这就是为什么我使用返回 StdClass 对象集合的外观。否则，我最终会得到一组具有不相关属性的模型。在模型上调用这种复杂的自定义查询甚至会破坏模型关系，例如，如果我没有在复杂查询的 select 语句中包含主键或外键。

【参考方案1】：

嗯，我想出了使用访问者模式来封装复杂查询的想法。访问者对象封装了具体的查询，雄辩的模型可以接受客户端传递的访问者，并在他们身上调用标准方法，将自己传递给访问者，并将带有访问者结果的 StdClass 集合交还给客户端。好像对我有用。