Laravel. Что такое «eager loading» в двух словах на пальцах?

Question

[Ernest Faizullin]

Вот и весь вопрос. Привет всем!

Answer 1

[Inclusive]

В документации все просто расписано.
Есть модель:

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * Get the phone record associated with the user.
     */
    public function phone()
    {
        return $this->hasOne('App\Phone');
    }
}

Выбрали вы пользователей:
$users = (new User())->newQuery()->get();

Если вы сделаете так:

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

То при каждом запросе к отношению - будет отдельный запрос.
Вместо этого можно сделать либо:

$users = (new User())->newQuery()->with('phone')->get();

либо уже после получения:
$users->load('phone');
В первом случае при наличии 10 записей с пользователями произойдет 11 запросов, во втором и третьем всего 2 запроса.

Comments

[Alex Wells]

Можно же User::query() делать, явно проще будет, и без магии)

[Inclusive]

Alex Wells, смешной бред) Вы сейчас как раз магию и расписали, ибо это статика, что также как и фасады - является moveton, за которую нужно отрывать руки...
Разбросаете таких соплей, и по всему коду потом будете прыгать при смене зависимости, ибо в конструктор вы эту статику не пропишете и не сможете инжектить с контейнера так:

Class Repository
{
   public function __construct(User $user)
   {
       $this->user = $user;
   }
}

Еще лучше бы было: не User а UserInterface, а в контейнере сделать бинд:
$app->bind(UserInterface::class, User::class);
Замен класса будет происходить 1 правкой.
Если же вы предлагаете сделать так:
$this->user::query();
Что тоже возможно, но больно коряво, ибо посмотрев метод - можно увидеть, что это обертка над моим кодом.
Нет, вы конечно можете написать фасад для этой модели, и при необходимости менять в нем зависимость, но это уже полная наркомания)

[Alex Wells]

Inclusive, с каких пор статика - это магия? User::with - это уже магия, staticCall вызывает, а query - существующий метод в классе.

В том примере с DI в конструкторе, следуя логике, вы инжектите инстенс модел, то есть конкретный ее экземпляр, а не инстенс квери-билдера/энтити-менеджера. Правильным решением будет вообще не использовать такую бредятину вместе с Eloquent. А с Doctrine такого вообще не выйдет.

[Inclusive]

Alex Wells, Немного плохой пример, посыл вы не увидели. Инжектите в сервис, это не запрещено?
" вы инжектите инстенс модел, то есть конкретный ее экземпляр, а не инстенс квери-билдера/энтити-менеджера" - методы вы все равно будете держать модели, и работать вы будете с ее интерфейсом.

interface Interface{
 public function filterParams($val):self;
 ...
}

Примерно в таком типе, и мы опять же вернемся к моему первому ответу - написав обновленную модель вы проинжектите ее в контейнер, а не будете менять по всему коду статику. Даже если вы пропишете в контракте отношения - лишним это не будет.

User::with - это уже магия, staticCall вызывает, а query - существующий метод в классе.

С вами все в порядке?

<?php namespace Illuminate\Database\Eloquent;
abstract class Model implements ArrayAccess, Arrayable, Jsonable, JsonSerializable, QueueableEntity, UrlRoutable
{
...
public static function with($relations)
{
        return (new static)->newQuery()->with(
            is_string($relations) ? func_get_args() : $relations
        );
}
public static function query()
{
        return (new static)->newQuery();
}
...
}

Вы вообще разбираетесь в том, о чем говорите?

[Alex Wells]

Inclusive, ок, был не прав на счет with. Мне казалось, что там только phpdoc, а сам метод, как и все остальные, просто создают query builder и дергают нужный метод на нем, и.е. User::where() и тд.

Не пойму о каких методах вы говорите. Об квери методах? Нет, они в квери-билдере eloquent'овском. Скоупы? Их так-же как-то либо моделька, либо квери-билдер вызывает. Релейшены? Другие методы, которые именно к реальным данным привязаны? Ну тоже не имеет отношения к этому. А еще каких-то методов там не будет. И не пойму что за filterParams - это уже либо к репозиторию, либо в скоуп.

Опять же не пойму зачем что-то везде менять, если в современных IDE, если вам очень захотелось поменять название метода/класса, есть рефакторинг автоматический =/

И не вьезжаю, зачем что-то менять по проекту после, цитирую, "написания обновленной модели"? Чем инжект и (new User)->newQuery()->whatever() отличается от User::whatever() с этой стороны? Что там что там скоуп whatever IDE, понятное дело, не сможет отрефакторить, и я не вижу какие преимущества это вам дает.

[Inclusive]

Опять же не пойму зачем что-то везде менять, если в современных IDE, если вам очень захотелось поменять название метода/класса, есть рефакторинг автоматический =/

Он не всегда работает правильно, есть исключения, все-равно нужно все просматривать глазами, менять в 1 месте и во многих - большая разница.

И не вьезжаю, зачем что-то менять по проекту после, цитирую, "написания обновленной модели"? Чем инжект и (new User)->newQuery()->whatever() отличается от User::whatever() с этой стороны? Что там что там скоуп whatever IDE, понятное дело, не сможет отрефакторить, и я не вижу какие преимущества это вам дает.

Это был ответ на вопрос человека, разумеется использоваться это будет по другому - проинжектили в конструкторе, вызываете через $this->model, вместо User в инжекте используется UserInterface.

Не пойму о каких методах вы говорите. Об квери методах? Нет, они в квери-билдере eloquent'овском. Скоупы? Их так-же как-то либо моделька, либо квери-билдер вызывает. Релейшены? Другие методы, которые именно к реальным данным привязаны? Ну тоже не имеет отношения к этому. А еще каких-то методов там не будет. И не пойму что за filterParams - это уже либо к репозиторию, либо в скоуп.

Под UserInterface вы прячете все как можно глубже, оставляя только публичные методы.

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

[Alex Wells]

Inclusive, логично, если использовать интерфейс. Но это уже, имхо, overcomplication - очевидно, что у этого интерфейса всегда будет только одна реализация, и реально профита он вам не даст. А фигачить его просто что бы красиво было - можно, конечно, но, имхо опять же, это только усложнит разработку в дальнейшем (лазить в интерфейс и в модель, напичканную магией, дабы изменить/добавить метод - такое себе удовольствие).

А на счет рефакторинга - исключений много, и скоупы - одно из них. Да, тут интерфейс пригодится. Но так ли оно вам надо? Я бы лучше избавлялся от магии в моделях, например использованием Doctrine или репозиториев, ежели поверх и так странноватенькой системы пилил костыли. Ну, опять же, это мое имхо только.