За годы своей практики я наблюдал интересную закономерность: разработчики, освоившие базовые приемы Eloquent, часто застревают на этом уровне. Они умеют создавать модели, определять отношения, выполнять типичные CRUD-операции. И казалось бы, чего ещё желать? А потом наступает момент истинны — проект растет, база данных распухает, и производительность начинает "хромать" на обе ноги.
Большинство проблем в крупных Laravel-проектах связаны не с архитектурой фреймворка, а с неоптимальным использованием Eloquent. Я сам попадал в эту ловушку, пока не осознал, насколько глубоким может быть кроличья нора под названием "продвинутые техники Eloquent".
| PHP | 1
2
3
4
5
| // Типичный код неопытного разработчика
$posts = Post::all();
foreach ($posts as $post) {
echo $post->user->name; // Здравствуй, N+1 запрос!
} |
|
Eloquent — не просто слой абстракции над базой данных. Это полноценный инструмент моделирования предметной области, который при правильном использовании позволяет писать чистый, поддерживаемый и производительный код. Он воплощает принципы DDD (Domain-Driven Design) в своей структуре, позволяя моделям быть чем-то большим, чем просто отражением таблиц базы данных.
| PHP | 1
2
3
4
5
6
7
8
9
10
| // Один из моих любимых трюков с использованием локальных скопов
class Post extends Model {
public function scopePopular($query) {
return $query->withCount('comments')
->orderBy('comments_count', 'desc');
}
}
// И теперь можно легко получить популярные посты
$popularPosts = Post::popular()->take(10)->get(); |
|
Post::popular(), ему не нужно разбираться в сложной логике определения популярности. Всё скрыто внутри модели, как и положено при хорошей инкапсуляции.
Освоение продвинутых техник Eloquent — это инвестиция, которая окупается многократно на протяжении всего жизненного цикла проекта. От оптимизации производительности до улучшения поддерживаемости кода — преимущества очевидны для тех, кто берет на себя труд копнуть глубже стандартной документации.
Мощь отношений данных
Если бы Eloquent был вселенной, то отношения данных были бы её гравитацией — фундаментальной силой, связывающей все объекты воедино. Многие разработчики останавливаются на базовом понимании hasMany, belongsTo и, если повезет, belongsToMany. Однако в реальных проектах этого часто недостаточно. Я столкнулся с этим, работая над CMS для медиа-холдинга. Контент мог быть связан с разными сущностями: статьи, фотогалереи, видеоролики. И все они могли иметь комментарии. Создавать отдельную таблицу для каждого типа комментариев было бы кошмаром поддержки. И тут на сцену выходят полиморфные отношения.
Полиморфные отношения: когда одна модель — несколько хозяинов
Полиморфные отношения — это не просто фича фреймворка, а настоящее архитектурное решение. Они позволяют модели принадлежать более чем одному типу другой модели. Звучит странно? Представьте комментарий, который может относиться и к посту, и к фотографии, и к видео.
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| class Comment extends Model
{
public function commentable()
{
return $this->morphTo();
}
}
class Post extends Model
{
public function comments()
{
return $this->morphMany(Comment::class, 'commentable');
}
}
class Photo extends Model
{
public function comments()
{
return $this->morphMany(Comment::class, 'commentable');
}
} |
|
commentable_id и commentable_type. Первое хранит ID связанной модели, второе — её тип (в Laravel обычно это полное имя класса).
Но это только верхушка айсберга. Настоящая мощь проявляется при использовании полиморфных отношений типа "многие ко многим". В одном из проектов мне потребовалось реализовать теги, которые могли применяться к разным типам контента.
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| // Определяем полиморфное отношение многие ко многим
class Tag extends Model
{
public function posts()
{
return $this->morphedByMany(Post::class, 'taggable');
}
public function videos()
{
return $this->morphedByMany(Video::class, 'taggable');
}
}
// А в модели Post
public function tags()
{
return $this->morphToMany(Tag::class, 'taggable');
} |
|
taggables с полями tag_id, taggable_id и taggable_type. И теперь можно легко получить все теги поста или все посты с определённым тегом.
Глубокая загрузка: вложенные отношения
Проблема N+1 запросов — один из распространённых источников проблем с производительностью. Допустим, нам нужно вывести список постов с авторами и комментариями к этим постам, причём для комментариев тоже показать авторов.
| PHP | 1
2
3
4
5
6
7
8
| // Антипаттерн: N+1 запрос в геометрической прогрессии
$posts = Post::all();
foreach ($posts as $post) {
echo $post->user->name;
foreach ($post->comments as $comment) {
echo $comment->user->name; // Привет, база данных! Мы ещё встретимся... много раз.
}
} |
|
| PHP | 1
2
| // Решение: вложенная жадная загрузка
$posts = Post::with(['user', 'comments.user'])->get(); |
|
Но тут есть подводный камень: излишняя жадная загрузка. Попытка загрузить слишком много вложенных отношений может привести к загрузке огромных объёмов данных. Я научился формировать запросы максимально точно:
| PHP | 1
2
3
4
5
6
| // Более точный запрос с выбором конкретных полей
$posts = Post::with([
'user:id,name', // Только имя и ID автора
'comments:id,post_id,body,user_id', // Только нужные поля комментариев
'comments.user:id,name' // И только имя автора комментария
])->select('id', 'title', 'body', 'user_id')->get(); |
|
Рекурсивные отношения: когда структура уходит вглубь
Особый случай — рекурсивные отношения, где модель связывается сама с собой. Классический пример — древовидное меню, где каждый пункт может содержать подпункты.
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
| class MenuItem extends Model
{
public function children()
{
return $this->hasMany(MenuItem::class, 'parent_id');
}
public function parent()
{
return $this->belongsTo(MenuItem::class, 'parent_id');
}
} |
|
| PHP | 1
2
| // Загружаем все уровни вложенности
$menuItems = MenuItem::with('children.children.children')->whereNull('parent_id')->get(); |
|
| PHP | 1
2
3
4
5
| // Загружаем рекурсивно все дочерние элементы
$menuItems = MenuItem::with('children.children.children')->whereNull('parent_id')->get();
// В Laravel 8+ можно использовать бесконечную рекурсию
$menuItems = MenuItem::with('children.children.*')->whereNull('parent_id')->get(); |
|
Эти техники позволяют моделировать сложные отношения между данными и эффективно работать с ними, избегая потенциальных проблем с производительностью. В следующих разделах мы рассмотрим более продвинутые способы фильтрации и манипуляции связанными моделями.
Laravel- Eloquent "many to many". Как создать модель из дополнительной таблицы
Здравствуйте. Я новичок в фреймворках. Нужно сделать электронный документооборот. есть таблицы... Как реализовать такую архитектуру на Eloquent Laravel?
Есть проект, в нем такие роли - админ, врач, клиент. У клиента своя анкета, у врача своя. Про RBAC... Как в Laravel eloquent сделать запрос с одним фильтром по многим полям ?
Всем привет,
В Laravel 5.7/ mysql приложении я делаю форму фильтра с более 10 инпутами,
и один... Как вернуть только количество найденных строк в базе в отношениях eloquent Laravel?
Как вернуть только количество найденных строк в базе в отношениях eloquent Laravel?
Всем привет!...
Фильтрация коллекций связанных моделей
Работа с отношениями не ограничивается простой загрузкой данных. Часто требуется применять сложную фильтрацию к связанным моделям. Eloquent предлагает элегантные решения для таких задач.
Фильтрация при загрузке отношений
Допустим, мы хотим получить только те посты, у которых есть хотя бы один одобренный комментарий. Вот как это можно сделать:
| PHP | 1
2
3
4
| // Ищем посты с одобренными комментариями
$posts = Post::whereHas('comments', function ($query) {
$query->where('is_approved', true);
})->get(); |
|
| PHP | 1
2
3
4
| // Посты с более чем 5 одобренными комментариями
$popularPosts = Post::whereHas('comments', function ($query) {
$query->where('is_approved', true);
}, '>', 5)->get(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
| // Получаем посты с количеством одобренных комментариев
$posts = Post::withCount(['comments' => function ($query) {
$query->where('is_approved', true);
}])->get();
// Теперь у каждого поста есть атрибут approved_comments_count
foreach ($posts as $post) {
echo "Пост '{$post->title}' имеет {$post->approved_comments_count} одобренных комментариев";
} |
|
Условная загрузка отношений
Иногда нам нужно загружать отношения только при определенных условиях. Например, загрузить комментарии только если их больше трёх:
| PHP | 1
2
3
4
| // Загружаем комментарии только если их >= 3
$posts = Post::withWhereHas('comments', function ($query) {
$query->having(DB::raw('count(*)'), '>=', 3);
})->get(); |
|
| PHP | 1
2
3
4
5
| $patients = Patient::with(['labTests' => function ($query) {
$query->where('result', 'abnormal');
}])->whereHas('labTests', function ($query) {
$query->where('result', 'abnormal');
})->get(); |
|
Манипуляция отношениями через pivot-таблицы
В сложных приложениях часто используются отношения "многие ко многим", реализуемые через промежуточные (pivot) таблицы. Laravel предоставляет мощный API для работы с такими таблицами.
Расширенные данные в промежуточной таблице
Не ограничивайтесь только внешними ключами в pivot-таблицах! Я часто добавляю дополнительные поля, которые обогащают отношения между моделями.
| PHP | 1
2
3
4
5
6
7
8
9
10
| // В модели определяем, какие поля нужно загружать из pivot-таблицы
class User extends Model
{
public function roles()
{
return $this->belongsToMany(Role::class)
->withPivot('expires_at', 'created_by')
->withTimestamps();
}
} |
|
| PHP | 1
2
3
4
| $user = User::find(1);
foreach ($user->roles as $role) {
echo "Роль {$role->name} истекает: {$role->pivot->expires_at}";
} |
|
Фильтрация через pivot-атрибуты
Особо ценная возможность — фильтровать результаты на основе данных в промежуточной таблице:
| PHP | 1
2
| // Получаем только роли, срок действия которых не истек
$activeRoles = $user->roles()->wherePivot('expires_at', '>', now())->get(); |
|
access_level:
| PHP | 1
2
| // Найти всех друзей с полным доступом
$closeFriends = $user->friends()->wherePivot('access_level', 'full')->get(); |
|
Динамические pivot-модели
Для полного контроля над промежуточной таблицей можно создать отдельную pivot-модель. Это отличный подход, когда промежуточная таблица содержит сложную логику:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| class UserRole extends Pivot
{
// Мьютатор для автоматического установления срока действия
public function setExpiresAtAttribute($value)
{
$this->attributes['expires_at'] = $value ?: now()->addYear();
}
// Проверка, истекла ли роль
public function isExpired()
{
return $this->expires_at && $this->expires_at->isPast();
}
} |
|
| PHP | 1
2
3
4
5
6
| public function roles()
{
return $this->belongsToMany(Role::class)
->using(UserRole::class)
->withPivot('expires_at');
} |
|
| PHP | 1
2
3
4
| // Проверяем, истекла ли роль
if ($user->roles->first()->pivot->isExpired()) {
// Делаем что-то...
} |
|
room_bookings связывала комнаты и бронирования, но также содержала информацию о ценах, специальных запросах и статусе подтверждения.
Правильное использование отношений в Eloquent — это не просто техническая оптимизация. Это возможность адекватно представить реальные связи между сущностями вашего бизнес-домена. Когда модели и отношения между ними правильно спроектированны, код становится не только эффективным, но и удивительно выразительным, отражающим реальную предметную область. Стоит отметить, что излишне усложнять отношения тоже не стоит. Иногда простой запрос к базе данных может быть более пондятним и производительным, чем сложная цепочка отношений Eloquent. Это всегда баланс между чистотой абстракции и производительностью.
Оптимизация производительности
Когда дело доходит до оптимизации Laravel-приложений, Eloquent может быть как вашим лучшим другом, так и злейшим врагом. Это как швейцарский нож — мощный и универсальный, но нужно знать, когда использовать открывашку, а когда — пилочку для ногтей.
Стратегии загрузки данных: ленивая VS жадная
Первое, с чем сталкивается каждый разработчик при оптимизации — выбор между ленивой и жадной загрузкой. Ленивая загрузка — паттерн по умолчанию в Eloquent, и именно это часто становится причиной знаменитой проблемы N+1 запросов.
| PHP | 1
2
3
4
5
| // Классический пример проблемы N+1
$authors = Author::all(); // 1 запрос
foreach($authors as $author) {
echo $author->profile->bio; // +N запросов
} |
|
| PHP | 1
2
3
4
5
| // Решение: 2 запроса вместо N+1
$authors = Author::with('profile')->get();
foreach($authors as $author) {
echo $author->profile->bio; // Данные уже загружены
} |
|
Настоящий баланс: выборочная загрузка
Вот техника, которая спасла один из моих проектов электронной коммерции:
| PHP | 1
2
3
4
| // Выборочная загрузка только нужных полей
$products = Product::select(['id', 'name', 'price'])
->with(['category:id,name', 'tags:id,name'])
->get(); |
|
Отложенная жадная загрузка
Иногда вы не знаете заранее, какие отношения понадобятся. В таких случаях Eloquent предлагает отложенную жадную загрузку:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
| $book = Book::find(1);
if ($shouldShowAuthor) {
$book->load('author');
}
if ($shouldShowReviews) {
$book->load(['reviews' => function ($query) {
$query->where('rating', '>', 3);
}]);
} |
|
load() выполнит жадную загрузку уже после получения основной модели. Я активно использовал этот подход в панели администратора, где пользователь мог выбирать, какие секции данных отображать.
Query Builder: сила без излишеств
Иногда полноценное использование Eloquent моделей избыточно. Если вам не нужны события, аксессоры и мутаторы, можно использовать голый Query Builder для экономии ресурсов:
| PHP | 1
2
3
4
5
| // Вместо этого
$expensiveItems = Product::where('price', '>', 1000)->get();
// Попробуйте это
$expensiveItems = DB::table('products')->where('price', '>', 1000)->get(); |
|
Инкрементные операции без загрузки моделей
Для операций, которые изменяют данные без необходимости их предварительного чтения, Eloquent предлагает неявные инкрементные методы:
| PHP | 1
2
3
4
5
6
7
| // Вместо этого
$post = Post::find(1);
$post->views_count += 1;
$post->save();
// Используйте это
Post::where('id', 1)->increment('views_count'); |
|
Агрегатные операции прямо в БД
Еще одна распространенная ошибка — выгрузка данных для выполнения агрегатных функций в PHP:
| PHP | 1
2
3
4
5
| // Неэффективно: загружаем все данные и считаем в PHP
$totalRevenue = Order::all()->sum('amount');
// Эффективно: считаем на уровне БД
$totalRevenue = Order::sum('amount'); |
|
Использование raw-выражений для сложной логики
Бывают случаи, когда Eloquent не предоставляет изящного решения для сложного SQL. Не бойтесь использовать raw-выражения, когда это оправдано:
| PHP | 1
2
3
| // Пример: подсчёт словосочетания в тексте
$posts = Post::whereRaw('LOWER(content) LIKE ?', ['%' . strtolower($term) . '%'])
->get(); |
|
| PHP | 1
2
3
4
5
6
| $analysisResults = DB::table('user_activities')
->select(DB::raw('user_id, COUNT(*) as total,
PERCENTILE_CONT(0.5) WITHIN GROUP(ORDER BY duration) as median_duration'))
->groupBy('user_id')
->having(DB::raw('COUNT(*)'), '>', 10)
->get(); |
|
Кэширование запросов для часто повторяемых данных
Самая простая и эффективная оптимизация — кэширование часто запрашиваемых данных:
| PHP | 1
2
3
| $categories = Cache::remember('all_categories', 3600, function () {
return Category::all();
}); |
|
| PHP | 1
2
3
4
5
6
7
| // Кэширование с тегами
$products = Cache::tags(['products', 'frontpage'])->remember('featured_products', 3600, function () {
return Product::featured()->with('category')->get();
});
// Инвалидация при изменении продуктов
Cache::tags('products')->flush(); |
|
Выборочная тюнинг-настройка часто используемых запросов
Иногда небольшие изменения в структуре запросов могут дать огромный прирост производительности. Например, использование метода exists() вместо count() для проверки наличия записей:
| PHP | 1
2
3
4
5
| // Вместо этого (запрашивает количество)
if (User::where('email', $email)->count() > 0) { ... }
// Используйте это (останавливается после первого найденного)
if (User::where('email', $email)->exists()) { ... } |
|
| PHP | 1
2
3
4
| // Добавляем индексы в миграции
Schema::table('posts', function (Blueprint $table) {
$table->index(['user_id', 'created_at']);
}); |
|
Динамические соединения и шардинг данных
Очень часто с ростом проекта база данных превращается в бутылочное горлышко. Когда индексы и кэширование уже не спасают, наступает время для более радикального решения — шардинга. В Laravel сравнительно легко реализовать динамическое переключение между несколькими базами данных:
| PHP | 1
2
3
4
5
| // Временно переключаемся на другое соединение
$users = DB::connection('slave_db')->table('users')->get();
// Или через модель
$stats = Stats::on('analytics_db')->where('date', '>', $startDate)->get(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| // На уровне модели
class User extends Model
{
public function getConnectionName()
{
// Для операций записи используем основную БД
if ($this->isWriteOperation()) {
return 'master';
}
// Для чтения - балансируем между репликами
return 'replica_' . (crc32($this->id) % 3 + 1);
}
protected function isWriteOperation()
{
return $this->wasRecentlyCreated || $this->isDirty();
}
} |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // Определяем соединение по ID организации
DB::resolverFor('tenant', function ($tenantId) {
// Крупные клиенты получают выделенную БД
if (in_array($tenantId, config('database.premium_tenants'))) {
return DB::connection("tenant_{$tenantId}");
}
// Остальные распределяются по шардам
$shardNumber = $tenantId % config('database.tenant_shards_count');
return DB::connection("tenant_shard_{$shardNumber}");
});
// Использование в коде
$result = DB::tenant($currentTenantId)->table('some_table')->get(); |
|
Оптимизация памяти и ресурсов PHP
Не забывайте, что Eloquent работает в контексте PHP, со всеми его ограничениями по памяти. В проекте с миллионами записей стандартный подход с жадной загрузкой может быстро исчерпать доступную память.
Для работы с большими наборами данных я рекомендую использовать потоковую обработку с методом chunk():
| PHP | 1
2
3
4
5
6
| // Обрабатываем миллионы записей без исчерпания памяти
User::chunk(1000, function ($users) {
foreach ($users as $user) {
// Обработка каждого пользователя
}
}); |
|
| PHP | 1
2
3
| foreach (User::cursor() as $user) {
// Память используется только для одной модели за раз
} |
|
| PHP | 1
2
3
4
5
6
7
| $query = DB::table('giant_table')->where('processed', false);
// Используем генератор для минимального потребления памяти
while ($row = $query->first()) {
// Обрабатываем запись
DB::table('giant_table')->where('id', $row->id)->update(['processed' => true]);
} |
|
Асинхронная обработка и очереди
Тяжелые операции над моделями лучше выносить в отложенную обработку через очереди. Laravel делает это удивительно просто:
| PHP | 1
2
| // Создаем задачу для очереди
ProcessUserData::dispatch($user)->onQueue('data-processing'); |
|
Индексы в базе данных: "запрятанная" оптимизация
Разработчики часто недооценивают роль индексов в базе данных. Помню случай, когда простой индекс на поле status ускорил критичный запрос в 27 раз!
Eloquent не имеет прямого управления индексами (это делается в миграциях), но понимание того, как ваши запросы соотносятся с индексами, критически важно:
| PHP | 1
2
3
4
5
6
7
8
| // Миграция с правильными индексами для часто используемых запросов
Schema::table('orders', function (Blueprint $table) {
// Композитный индекс для часто используемой выборки
$table->index(['user_id', 'status', 'created_at']);
// Индекс для полнотекстового поиска (MySQL 5.7+)
$table->fullText(['description']);
}); |
|
Оптимизация для конкретных СУБД
Eloquent абстрагирует нас от конкретной СУБД, но для максимальной производительности иногда стоит использовать специфичные возможости:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| // Для MySQL: использование FORCE INDEX
DB::table('large_table')
->fromRaw('large_table FORCE INDEX (created_at_index)')
->where('active', 1)
->get();
// Для PostgreSQL: эффективная пагинация с использованием курсоров
if ($driver === 'pgsql') {
$users = User::orderBy('id')
->where('id', '>', $lastId)
->take($perPage)
->get();
} else {
$users = User::orderBy('id')
->offset($offset)
->take($perPage)
->get();
} |
|
Измерение и мониторинг
Любая оптимизация должна начинаться с измерений. Laravel предоставляет удобные инструменты для отладки запросов:
| PHP | 1
2
3
4
5
6
7
8
| // Включаем логирование запросов
DB::enableQueryLog();
// Выполняем запрос
$users = User::popular()->get();
// Анализируем лог
$queries = DB::getQueryLog(); |
|
Профилирование запросов через EXPLAIN
Для тонкой настройки критичных запросов необходимо понимать, как СУБД их выполняет. Используйте EXPLAIN:
| PHP | 1
2
3
4
5
6
7
8
9
10
| $sql = User::where('status', 'active')
->where('last_login_at', '>', now()->subDays(30))
->toSql();
$bindings = [
'active',
now()->subDays(30)
];
$results = DB::select("EXPLAIN " . $sql, $bindings); |
|
Оптимизация производительности Eloquent — это целое искусство, сочетающее понимание ORM, специфики СУБД и особенностей PHP. Помните, что истинная оптимизация часто требует компромиссов: простота использования vs производительность, абстракция vs контроль, гибкость vs специализация. Выбор правильного баланса — ключ к созданию производительных и поддерживаемых Laravel-приложений.
Хаки и трюки Eloquent
Eloquent — это не просто ORM для выполнения CRUD-операций. Это инструмент, полный секретных лазеек и изящных приёмов, которые могут превратить громоздкий код в шедевр лаконичности. За годы работы с Laravel я собрал целую коллекцию таких хаков, и сегодня готов поделиться самыми эффектными из них.
Скопы: локальные и глобальные
Скопы — одна из моих любимых фишек Eloquent. Они позволяют инкапсулировать часто используемую логику запросов и переиспользовать её.
Локальные скопы
Локальные скопы определяются в модели через методы, начинающиеся с scope:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
| class Post extends Model
{
public function scopePublished($query)
{
return $query->where('status', 'published');
}
public function scopePopular($query, $minViews = 1000)
{
return $query->where('views_count', '>=', $minViews);
}
} |
|
| PHP | 1
2
3
4
5
| // Получаем опубликованные популярные посты
$posts = Post::published()->popular()->get();
// С параметром
$veryPopularPosts = Post::published()->popular(5000)->get(); |
|
Глобальные скопы
Глобальные скопы — ещё более мощный механизм. Они автоматически применяются ко всем запросам модели. Классический пример — фильтрация удалённых элементов (это, кстати, как soft deletes в Laravel работают):
| PHP | 1
2
3
4
5
6
7
8
9
| class Post extends Model
{
protected static function booted()
{
static::addGlobalScope('published', function ($query) {
$query->where('status', 'published');
});
}
} |
|
Post будет включать фильтрацию по статусу. А если нужно получить все посты, включая неопубликованные?
| PHP | 1
2
3
4
5
| // Отключаем конкретный глобальный скоп
$allPosts = Post::withoutGlobalScope('published')->get();
// или все скопы разом
$allPostsUnfiltered = Post::withoutGlobalScopes()->get(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
| // В сервис-провайдере
Clinic::addGlobalScope(new ClinicScope);
// Сам скоп в отдельном классе
class ClinicScope implements Scope
{
public function apply(Builder $builder, Model $model)
{
if (auth()->check()) {
$builder->where('clinic_id', auth()->user()->clinic_id);
}
}
} |
|
События моделей и наблюдатели
Модели Eloquent генерируют события на разных этапах своего жизненного цикла: создание, обновление, удаление и т.д. Это открывает возможности для гибкого расширения функциональности.
Прослушивание событий в модели
Самый простой способ — обработать события внутри самой модели:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Post extends Model
{
protected static function booted()
{
static::created(function ($post) {
// Отправка уведомлений подписчикам
Notification::send($post->author->subscribers, new NewPostNotification($post));
});
static::deleting(function ($post) {
// Удаление связанных комментариев
$post->comments()->delete();
});
}
} |
|
| PHP | 1
2
3
| static::creating(function ($booking) {
$booking->commission = $booking->calculateCommission();
}); |
|
Наблюдатели (Observers)
Когда логика становится сложнее, или вы хотите держать модель "чистой", на помощь приходят Observers:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| // app/Observers/PostObserver.php
class PostObserver
{
public function created(Post $post)
{
// Логика при создании
}
public function updated(Post $post)
{
// Логика при обновлении
}
// ... другие методы
}
// В сервис-провайдере
public function boot()
{
Post::observe(PostObserver::class);
} |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| public function updated(MedicalRecord $record)
{
$changes = $record->getChanges();
foreach ($changes as $field => $newValue) {
if (in_array($field, $record->getAuditableFields())) {
Audit::create([
'record_id' => $record->id,
'field' => $field,
'old_value' => $record->getOriginal($field),
'new_value' => $newValue,
'user_id' => auth()->id(),
]);
}
}
} |
|
Мьютаторы и аксессоры: магия трансформации данных
Мьютаторы и аксессоры — одна из самых недооценённых возможностей Eloquent. Они позволяют трансформировать данные при записи и чтении.
Аксессоры (геттеры)
Аксессоры преобразуют данные при их получении из модели:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
| class User extends Model
{
public function getFullNameAttribute()
{
return "{$this->first_name} {$this->last_name}";
}
public function getAgeAttribute()
{
return now()->diffInYears($this->birth_date);
}
} |
|
| PHP | 1
2
| echo $user->full_name; // "Иван Иванов"
echo $user->age; // 35 |
|
Мьютаторы (сеттеры)
Мьютаторы преобразуют данные при их записи в модель:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
| class User extends Model
{
public function setPasswordAttribute($value)
{
$this->attributes['password'] = Hash::make($value);
}
public function setEmailAttribute($value)
{
$this->attributes['email'] = strtolower($value);
}
} |
|
| PHP | 1
2
3
4
| $user = new User;
$user->password = 'секретный_пароль'; // Будет захеширован
$user->email = 'USER@EXAMPLE.COM'; // Будет приведен к нижнему регистру
$user->save(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
| // Храним в копейках, но работаем в рублях
public function setAmountAttribute($value)
{
$this->attributes['amount'] = $value * 100;
}
public function getAmountAttribute()
{
return $this->attributes['amount'] / 100;
} |
|
Алиасы атрибутов
Еще один малоизвестный хак — алиасы атрибутов. Они позволяют создавать "синонимы" для существующих полей:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| class Customer extends Model
{
public function getAttribute($key)
{
$aliases = [
'name' => 'company_name',
'phone' => 'contact_phone'
];
if (isset($aliases[$key])) {
return $this->{$aliases[$key]};
}
return parent::getAttribute($key);
}
} |
|
Некоторые из этих хаков могут показаться мелочами, но именно из таких мелочей складывается красивый, лаконичный и поддерживаемый код. Как говорит Тейлор Отвелл, создатель Laravel: "Элегантность заключается не в том, чтобы сделать что-то сложное, а в том, чтобы сделать что-то сложное просто".
Использование трейтов для расширения моделей
Когда модели Eloquent разрастаются, они могут превратиться в настоящих монстров. Одно из элегантных решений этой проблемы – трейты PHP. Они позволяют выносить общую функциональность в отдельные компоненты и подмешивать их в модели по необходимости.
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| // app/Traits/HasComments.php
trait HasComments
{
public function comments()
{
return $this->morphMany(Comment::class, 'commentable');
}
public function addComment($body, $user = null)
{
$comment = new Comment(['body' => $body]);
if ($user) {
$comment->user()->associate($user);
}
return $this->comments()->save($comment);
}
public function getRecentCommentsAttribute()
{
return $this->comments()->latest()->take(5)->get();
}
} |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
| class Post extends Model
{
use HasComments;
// Остальной код модели
}
class Video extends Model
{
use HasComments;
// Абсолютно другая модель, но с теми же возможностями
} |
|
Taggable для всех моделей, которые можно было помечать тегами. Это избавило нас от дублирования кода и сделало функциональность тегирования единообразной во всей системе.
Особенно мощным становится комбинирование трейтов с макросами Query Builder:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| trait Searchable
{
public function scopeSearch($query, $term)
{
$columns = $this->getSearchableColumns();
$query->where(function($q) use ($term, $columns) {
foreach($columns as $column) {
$q->orWhere($column, 'LIKE', "%{$term}%");
}
});
return $query;
}
protected function getSearchableColumns()
{
return $this->searchable ?? ['name', 'description'];
}
}
// Использование
class Product extends Model
{
use Searchable;
protected $searchable = ['name', 'sku', 'description'];
}
// Теперь можно делать так:
$results = Product::search('ноутбук')->get(); |
|
Интерсепторы запросов
Иногда требуется перехватывать и модифицировать запросы Eloquent перед их выполнением. Это можно сделать через макрос или напрямую через расширение Builder:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
| // В сервис-провайдере
Builder::macro('whereAuthorized', function () {
$user = auth()->user();
if ($user->isAdmin()) {
return $this; // Админам можно всё
}
return $this->where('user_id', $user->id); // Обычным пользователям только своё
});
// Использование
$posts = Post::whereAuthorized()->get(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Builder::macro('applyPolicy', function ($policy, ...$args) {
$user = auth()->user();
$model = $this->getModel();
// PolicyResolver - собственный класс для определения подходящей политики
$policyInstance = PolicyResolver::resolve($model, $policy);
// Применяем ограничения из политики к запросу
return $policyInstance->apply($this, $user, ...$args);
});
// И теперь можно применять политики прямо в запросах
$viewablePosts = Post::applyPolicy('viewAny')->get();
$editablePosts = Post::applyPolicy('update')->get(); |
|
Кастомные коллекции
Одна из недооценённых фишек Eloquent – возможность создавать собственные классы коллекций для моделей. Это добавляет мощные возможности для манипуляции наборами объектов:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| // app/Collections/PostCollection.php
class PostCollection extends Collection
{
public function withReadTime()
{
return $this->map(function ($post) {
$post->read_time = ceil(str_word_count($post->content) / 200); // ~200 слов в минуту
return $post;
});
}
public function groupByCategory()
{
return $this->groupBy(function ($post) {
return $post->category->name;
});
}
}
// В модели указываем кастомную коллекцию
class Post extends Model
{
public function newCollection(array $models = [])
{
return new PostCollection($models);
}
}
// И теперь можно использовать кастомные методы
$posts = Post::all()->withReadTime();
$groupedPosts = Post::with('category')->get()->groupByCategory(); |
|
Асинхронные операции с моделями
Массовые операции над моделями могут быть ресурсоёмкими. Перенос их в очереди позволяет избежать таймаутов и улучшить отзывчивость приложения:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| // Создаём задачу для очереди
class ProcessUserData implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
protected $user;
public function __construct(User $user)
{
$this->user = $user;
}
public function handle()
{
// Долгая операция над моделью
$this->user->calculateActivityScore();
$this->user->updateRecommendations();
$this->user->save();
}
}
// Использование
ProcessUserData::dispatch($user); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| trait ProcessesAsynchronously
{
public function processAsync($method, ...$args)
{
dispatch(function () use ($method, $args) {
$this->$method(...$args);
});
return $this;
}
}
// В модели
class Report extends Model
{
use ProcessesAsynchronously;
public function generate()
{
// Долгий процесс генерации отчёта
}
}
// Использование
$report->processAsync('generate')->save(); |
|
Сериализация и кеширование моделей
Кэширование моделей Eloquent требует аккуратности из-за особенностей их сериализации. Вот проверенный подход:
| PHP | 1
2
3
4
5
6
7
8
9
| // Кэширование
Cache::put('user.1', $user);
// Десериализация
$cachedUser = Cache::get('user.1');
// Но есть нюанс: отношения могут быть не загружены при кешировании
// Решение: явно указываем, что нужно кешировать
Cache::put('user.1.with.posts', $user->load('posts')); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| class UserRepository
{
public function find($id)
{
return Cache::remember("user.{$id}", 3600, function () use ($id) {
return User::with('profile', 'roles')->findOrFail($id);
});
}
public function invalidateCache($user)
{
Cache::forget("user.{$user->id}");
}
} |
|
Расширение стандартных возможностей
Eloquent при всей своей мощи имеет границы возможностей. Но это не значит, что остановился и ты! Laravel предлагает несколько элегантных механизмов, позволяющих расширить стандартные возможности Eloquent под твои потребности. Я всегда говорю своим подопечным: Laravel не заканчивается на том, что описано в официальной документации. Настоящая магия начинается, когда ты выходишь за рамки стандартных решений.
Создание собственных макросов
Макросы — особый шедевр Laravel, позволяющий внедрять кастомную функциональность в существующие классы. С помощью макросов можно расширить Builder, Collection и многие другие компоненты Eloquent.
Представь, что в твоем проекте часто используется выборка случайных записей с определенным лимитом. Вместо того чтобы каждый раз писать inRandomOrder()->take($count), можно создать макрос:
| PHP | 1
2
3
4
5
6
7
8
9
10
| // В сервис-провайдере
Builder::macro('randomSample', function ($count = 1) {
return $this->inRandomOrder()->take($count);
});
// И теперь вместо этого
$randomUsers = User::inRandomOrder()->take(5)->get();
// Можно просто написать
$randomUsers = User::randomSample(5)->get(); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| Builder::macro('percentile', function ($column, $percentile = 0.5) {
// Для MySQL
if (DB::connection()->getDriverName() === 'mysql') {
$count = $this->count();
$offset = floor($count * $percentile);
$row = $this->orderBy($column)->skip($offset)->first();
return $row ? $row->{$column} : null;
}
// Для PostgreSQL (более эффективно)
if (DB::connection()->getDriverName() === 'pgsql') {
$result = $this->selectRaw(
"percentile_cont(?) within group (order by {$column}) as percentile",
[$percentile]
)->first();
return $result ? $result->percentile : null;
}
// Общий случай
$items = $this->pluck($column)->sort()->values();
$position = $percentile * ($items->count() - 1);
return $items->get($position);
});
// Использование
$medianAge = User::percentile('age', 0.5);
$p90ProcessingTime = Order::where('status', 'completed')->percentile('processing_time', 0.9); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| Builder::macro('withStatistics', function ($column) {
return $this->selectRaw("
AVG({$column}) as avg_{$column},
MIN({$column}) as min_{$column},
MAX({$column}) as max_{$column},
STDDEV({$column}) as stddev_{$column}
");
});
Builder::macro('analyzeTrend', function ($column, $dateColumn = 'created_at', $interval = '1 day') {
return $this->selectRaw("
DATE_FORMAT({$dateColumn}, '%Y-%m-%d') as date,
COUNT(*) as count,
AVG({$column}) as avg_{$column}
")
->groupBy(DB::raw("DATE_FORMAT({$dateColumn}, '%Y-%m-%d')"))
->orderBy('date');
});
// И использовать их вместе
$orderStats = Order::withStatistics('total_amount')
->analyzeTrend('items_count')
->where('status', 'completed')
->get(); |
|
Работа с raw-запросами
Иногда Eloquent просто не может обеспечить оптимальную производительность или функциональность для особо сложных запросов. В таких случаях не стоит боятся сырых SQL-запросов. Laravel предлагает несколько подходов к их использованию.
Использование DB::raw внутри Eloquent запросов
| PHP | 1
2
3
4
| $users = User::select('name', DB::raw('DATEDIFF(NOW(), created_at) as days_registered'))
->having(DB::raw('days_registered'), '>', 30)
->orderBy('days_registered', 'desc')
->get(); |
|
Полная замена Eloquent на DB Query Builder
| PHP | 1
2
3
4
5
6
7
8
9
10
| $results = DB::select("
SELECT users.name, COUNT(orders.id) as orders_count, SUM(orders.total) as revenue
FROM users
JOIN orders ON users.id = orders.user_id
WHERE orders.created_at >= ?
GROUP BY users.id, users.name
HAVING revenue > ?
ORDER BY revenue DESC
LIMIT 10
", [now()->subDays(30), 1000]); |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| // Громоздко и неэффективно в Eloquent
$customers = Customer::withCount(['orders' => function ($query) {
$query->where('created_at', '>=', now()->subYear());
}])
->withSum(['orders' => function ($query) {
$query->where('created_at', '>=', now()->subYear());
}], 'total')
// ... еще много логики ...
// Чистый SQL оказался в 20 раз быстрее и гораздо понятнее
$customers = DB::select("
WITH customer_stats AS (
SELECT
c.id,
c.name,
COUNT(o.id) AS order_count,
SUM(o.total) AS total_spent,
AVG(o.total) AS avg_order_value,
MIN(o.created_at) AS first_order_date,
MAX(o.created_at) AS last_order_date,
DATEDIFF(MAX(o.created_at), MIN(o.created_at)) /
NULLIF(COUNT(o.id) - 1, 0) AS avg_days_between_orders
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.id, c.name
)
SELECT
*,
total_spent / NULLIF(DATEDIFF(NOW(), first_order_date), 0) * 365 AS yearly_value,
CASE
WHEN last_order_date > DATE_SUB(NOW(), INTERVAL 3 MONTH) THEN 'active'
WHEN last_order_date > DATE_SUB(NOW(), INTERVAL 1 YEAR) THEN 'at_risk'
ELSE 'churned'
END AS status
FROM customer_stats
ORDER BY yearly_value DESC
"); |
|
Интеграция с нестандартными базами данных
Laravel по умолчанию поддерживает MySQL, PostgreSQL, SQLite и SQL Server, но иногда требуется работать с экзотическими СУБД или нереляционными базами данных. Для этого можно создать кастомные коннекторы.
Однажды мне пришлось интегрировать Laravel с ClickHouse для аналитической системы. Мы создали свой драйвер:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| // В сервис-провайдере
$this->app->resolving('db', function ($db) {
$db->extend('clickhouse', function ($config, $name) {
$config['driver'] = 'clickhouse';
return new ClickHouseConnection($config);
});
});
// Кастомный класс соединения
class ClickHouseConnection extends Connection
{
public function select($query, $bindings = [], $useReadPdo = true)
{
// Специфичная для ClickHouse реализация запросов
}
// ... другие методы ...
} |
|
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // В config/database.php
'connections' => [
'mysql' => [ /* ... */ ],
'clickhouse' => [
'driver' => 'clickhouse',
'host' => env('CLICKHOUSE_HOST', 'localhost'),
'port' => env('CLICKHOUSE_PORT', '8123'),
// Другие опции...
],
],
// В коде
$analyticsData = DB::connection('clickhouse')
->select('SELECT date, COUNT() as count FROM events GROUP BY date'); |
|
Техники отладки и профилирования запросов
Как бы хорошо ты не писал запросы, без инструментов отладки сложно понять, что происходит под капотом. Laravel предлагает несколько техник для исследования и оптимизации запросов Eloquent.
Просмотр SQL без выполнения запроса
| PHP | 1
2
3
4
5
6
7
8
9
| $query = User::where('active', true)->orderBy('created_at');
$sqlWithPlaceholders = $query->toSql();
$bindings = $query->getBindings();
// Заменяем плейсхолдеры реальными значениями (упрощенно)
$sql = str_replace('?', "'%s'", $sqlWithPlaceholders);
$sql = vsprintf($sql, $bindings);
dump($sql); // Выводим реальный SQL-запрос |
|
Логирование всех запросов
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
| // В начале запроса
DB::enableQueryLog();
// Выполняем запросы через Eloquent...
// Анализируем результаты
$queries = DB::getQueryLog();
foreach ($queries as $query) {
echo "SQL: {$query['query']}\n";
echo "Bindings: " . json_encode($query['bindings']) . "\n";
echo "Time: {$query['time']} ms\n\n";
} |
|
Ключевой совет: не оптимизируй то, что не измерил. Всегда начинай с профилирования и только потом применяй оптимизации там, где они действительно нужны.
Расширение стандартных возможностей Eloquent — один из признаков зрелости как разработчика на Laravel. Умение выходить за рамки стандартного функционала, когда это необходимо, без потери элегантности и читаемости кода — вот что отличает ремесленника от мастера.
Как внедрить продвинутые техники Eloquent в живые проекты
Продвинутые техники Eloquent — вроде китайских боевых искусств: легко восхищаться ими со стороны, но совсем другое дело — применять в реальном бою. За годы консультирования и рефакторинга Laravel-проектов я видел много команд, которые пытались сразу запрыгнуть на поезд продвинутых техник — и нередко это приводило к катастрофе.
Пошаговое внедрение: эволюция, а не революция
Главная ошибка большинства разработчиков — пытаться внедрить все оптимизации одновременно. Так делать не нужно! Вместо этого начните с "болевых точек" вашего проекта. Проведите аудит своих запросов: какие из них выполняются чаще? какие медленее всего? где явно просматриваются проблемы N+1?
| PHP | 1
2
3
4
5
6
| // Сначала найдите "грязные" места:
DB::enableQueryLog();
// Вызываем проблемный код...
$queries = DB::getQueryLog();
// Сортируем по времени выполнения:
usort($queries, fn($a, $b) => $b['time'] <=> $a['time']); |
|
Безопасное внедрение через абстракционные слои
Если вы добовляете продвинутые техники в существующий проект, крайне желательно изолировать изменения через абстракционные слои:
| PHP | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| // Создаем репозиторий для работы с пользователями:
class UserRepository
{
public function findActive($criteria = [])
{
// Здесь можно добавлять сколько угодно продвинутых техник,
// не затрагивая основной код
return User::active()
->with(['profile', 'roles.permissions'])
->when(!empty($criteria['search']), function($q) use ($criteria) {
$q->where('name', 'like', "%{$criteria['search']}%");
})
->get();
}
} |
|
Тестирование перед внедрением
Любая оптимизация должна быть проверена в тестовой среде. Я видел случаи, когда "оптимизация" запросов для MySQL полностью ломала совместимость с PostgreSQL. Или кэширование, которое прекрасно работало в разработке, приводило к утечкам памяти в продакшене.
| PHP | 1
2
3
4
5
6
7
8
9
10
11
| // Всегда тестируйте производительность до и после:
$start = microtime(true);
$result1 = YourModel::withOptimizedQueries()->get();
$optimizedTime = microtime(true) - $start;
$start = microtime(true);
$result2 = YourModel::withOriginalQueries()->get();
$originalTime = microtime(true) - $start;
printf("Оптимизация дала прирост: %.2f%%",
($originalTime - $optimizedTime) / $originalTime * 100); |
|
Документирование решений
Не все ваши коллеги могут понимать, зачем вы заменили простой whereHas() на хитрую конструкцию с подзапросами. Документируйте не только что вы сделали, но и почему. Измерения "до" и "после" должны быть частью этой документации.
Баланс между оптимизацией и читаемостью
В погоне за производительностью легко создать монстра, который никто не сможет поддерживать. Всегда спрашивайте себя: стоит ли выигрыш в 50мс того, чтобы сделать код на 200% сложнее? Иногда ответ будет "да" — например, для критичных участков высоконагруженых приложений. Но чаще всего — "нет".
Помню один проект, где разработчик так увлекся оптимизацией, что заменил все Eloquent-запросы на raw SQL. Через полгода никто не мог это поддерживать, и пришлось переписывать почти с нуля.
Начинайте с малого, думайте о большом
Техники, которые мы обсудили в этой статье, могут показаться сложными и запутанными поначалу. Но как и с любым навыком, начинайте с малого. Попробуйте внедрить сначала скопы, потом поиграйтесь с жадной загрузкой отношений. Постепенно добавляйте слой за слоем, и однажды вы заметите, что все эти "продвинутые" техники стали для вас обыденными инструментами.
Написать сложный запрос ELOQUENT. Выборка
Здравствуйте, вот моя модель User
class User extends Authenticatable
{
use Notifiable;
... Не меняется значение свойства у eloquent объекта
В строке 2 и 4 создаются свойства и меняются далее в коде, однако свойства в строке 17 и 18 не... eloquent with и doesntHave одновременно
Здравствуйте, подскажите как вывести одновременно и существующие записи и не существующие.
Есть 4... eloquent метод where и связи БД
Добрый день, подскажите как произвести выборку по нескольким связям в БД?
Нужно отфильтровать... Как правильно сделать сложный запрос через Eloquent, для получения объекта на выходе
Всем привет, начал с Ларыкастс, но там не подсказали, пока молчат, может кто знает.
Стоит задача... Переписать "сырой" sql запрос в Eloquent ORM
Есть сырой sql запрос который отлично работает
SELECT
FLOOR( open_time / 900 ) * 900 as... Eloquent - связи с доп. данными из 3й таблице
Приветствую уважаемых коллег, я начал разбираться с eloquent….
Читал про связи моделей и про... Eloquent одна модель на две таблицы, связанные один ко одному
Допустим в базе данных есть 2 таблицы:
1. Люди
имя
пол
дата рождения
2. Сотрудники... Eloquent - отношения через 2 промежуточных таблицы
Привет коллегам!
В базе данных такая структура таблиц:
Продукт -> Значения <- Поле ->... Eloquent SQL reference
Создал репозиторий с сырыми SQL запросами, генерируемыми Eloquent ORM. Может быть, кому-то будет... Eloquent - Подсчет связанных моделей: withCount, withAvg
https://laravel.su/docs/11.x/eloquent-relationships#podscet-sviazannyx-modelei
Здесь показано как... Installing laravel/laravel (v5.8.17) [ErrorException] mkdir(): Invalid path
Я только начинаю разбираться не судите строго. Пытаюсь установить laravel на XAMPPv3.2.4 командою...
|
