php – 一直使用Laravel Eloquent？

有没有使用Laravel Eloquent而不是原始sql的优势？

我习惯先在PHPMyAdmin中编写sql来检查关系,然后将其翻译为Eloquent ORM.

有时翻译为Eloquent ORM既痛苦又耗时,尤其是从长时间复杂的SQL查询转换.我能够在sql中快速编写,而不是使用Eloquent ORM.

解决方法:

使用查询生成器的最重要的好处是抽象,这通常会导致更少的代码.此外,由于构建器与数据库无关,因此它允许无缝切换RDBMS,例如从MySQL切换到Postgresql(但这仅适用于某些情况,因为有些内容是特定于数据库且无法抽象的).

将它与Eloquent结合使用可以将结果转换为Eloquent模型,这意味着您可以使用关系,变更器,访问器以及Eloquent模型提供的所有其他好处.例如：

$users = DB::select('select * from users');

将返回一个stdClass对象数组,而以下内容：

$users = User::all();

将返回一组Eloquent模型,您可以在其中获得关系：

foreach ($users as $user) {
    $user->projects();
}

或者进行更改并保存条目：

$user->name = 'Bob Dylan';
$user->save();

这些事情可以通过原始查询方法完成,通过手动创建一组模型,如下所示：

// Replace the stdClass items with User models
foreach ($users as &$user) {
    $user = new User($user);
}

// Create a Collection with the results
$users = new Illuminate\Support\Collection($users);

但它增加了Eloquent已经实现的复杂性.

抽象如何导致更少代码的一个很好的例子是：

User::whereIn('id', [1, 7, 100]);

哪个代码少于等价代码：

DB::select('select * from users where id in (?)', [implode(',', [1, 7, 100]);

在使用利用用户输入的原始查询时要考虑的重要事项是始终使用绑定以避免让自己对SQL Injection开放.

话虽如此,有些情况下,正如您所说,将查询转换为使用查询生成器是一件痛苦的事情,因为构建器具有限制,因为它与数据库无关.

使用原始查询没有问题.我通常将查询生成器的组合用于需要Eloquent模型的简单查询和用于更复杂操作的原始查询,其中只使用DB :: raw来使用查询生成器这样才有意义.因此,考虑到我上面提到的事情,它只是归结为偏好.