Почему сервисный контейнер Laravel кажется волшебным: объяснение внедрения зависимостей

июль 14, 2026 • 05:34 • 16 минут чтения • 0 просмотров • 0 Комментария

1. Хук и постановка проблемы

Вы с этим сталкивались. Вы создаете Laravel-приложение, и всё идет как по маслу. Вы пишете Route::get('/orders', [OrderController::class, 'index']) , определяете метод, и вдруг вам нужно отправить email.

Вы указываете в конструкторе тип MailerInterface $mailer , и бац — всё просто работает. Вы ничего не инициируете. Вы не видите ключевое слово new . Создается ощущение, будто фреймворк заглянул в эфир, достал нужный объект и передал его вам.

«Как он туда попал?» — спрашиваете вы себя. «Это вуду? Это магия?»

Для многих разработчиков контейнер сервисов Laravel остается черным ящиком. Это та самая «магия» за кулисами, которую мы принимаем как должное, но не понимаем до конца. Из-за этого возникает проблема: когда магия ломается, вы остаетесь беспомощны. Когда вам приходится писать собственные сервисы, вы по умолчанию используете вызовы new и static , создавая код, который невозможно протестировать и невозможно изменить.

Сегодня мы снимем шляпу волшебника с контейнера сервисов и заглянем под капот этой архитектуры. Мы демистифицируем эту магию.

2. Зачем существует этот паттерн / концепция

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

Катастрофа связанности

Представьте класс PaymentProcessor , который зависит от класса StripeAPI . Если вы создаете объект Stripe внутри PaymentProcessor с помощью new StripeAPI() , вы создаете жесткую связанность (tight coupling).

 class PaymentProcessor {
    public function __construct() {
        $this->stripe = new StripeAPI(); // Hard dependency
    }
}

Боль, существовавшая ранее

До того как паттерны вроде внедрения зависимостей (Dependency Injection, DI) стали мейнстримом, разработчики сталкивались с архитектурным хаосом («большим комком грязи»).

Невозможно протестировать: Как протестировать PaymentProcessor без реального списания средств с кредитной карты? Вы не можете подменить (mock) StripeAPI , потому что он жестко зашит в код.
Невозможно заменить: Что происходит, когда бизнес решает переключиться со Stripe на PayPal? Вам приходится вскрывать PaymentProcessor и переписывать его. Это нарушает принцип открытости/закрытости (OCP).
«Эффект домино»: Если для StripeAPI в конструкторе требуется новый HttpClient , вам теперь нужно обновлять абсолютно каждое место, где вы вызываете new StripeAPI() .

Почему это нужно крупным приложениям

По мере масштабирования вашего приложения сложность графов объектов растет. Рассмотрим сервис пользователей (User Service), которому нужен логгер, почтовый клиент и репозиторий. Этим зависимостям, в свою очередь, могут потребоваться их собственные зависимости.

Ручное управление этой цепочкой операторов new ( new A(new B(new C())) ) превращается в кошмар сопровождения. Контейнер решает проблему управления созданием объектов и их жизненным циклом, позволяя вам сосредоточиться на бизнес-логике, а не на сантехнике кода.

Суть в следующем: Нам нужен способ запрашивать то, что нам нужно, не вдаваясь в подробности того, как это собрать. Нам нужно переложить ответственность за создание объектов на «фабрику фабрик».

3. Аналогия из реального мира

Ресторан
Представьте ваше Laravel-приложение в виде элитного ресторана. Вы (контроллер) — официант. Кухня (контейнер сервисов) находится на заднем плане.

Неправильный подход (без DI): Если бы вы, официант, каждый раз, когда клиент заказывает бургер, сами выращивали овощи, разделывали мясо и пекли хлеб, вы бы ужасно справлялись со своей работой. Вы были бы жестко связаны со всей цепочкой поставок еды.
Подход с DI: Вы подходите к раздаточному окну кухни (конструктору) и говорите: «Мне нужен бургер с порцией картофеля фри». Вам всё равно, какой повар его приготовит, какую духовку они используют и откуда привезена говядина. Вы просто знаете, что если попросите об этом кухню, то получите готовое блюдо.
Полномочия в аналогии:
- Официант (клиент): OrderController .
- Запрос (заказ): Метод __construct или __invoke .
- Кухня (контейнер): Контейнер сервисов Laravel.
- Рецепт (привязка): Сервис-провайдер ( $this->app->bind ).
- Повар (фабрика): Процесс сборки, который разрешает зависимости.

Кухня берет на себя всю сложность процесса, чтобы официант мог сосредоточиться на обслуживании.

4. Боль (плохой дизайн)

Давайте посмотрим на типичную ситуацию «адского ада зависимостей» в Laravel-приложении.

 class PdfExporter
{
    public function export(Invoice $invoice): string
    {
        // 1. Hard dependency on a specific library
        $dompdf = new Dompdf();

        // 2. Hard dependency on the Filesystem to save it
        $path = storage_path('app/invoices/');
        if (!is_dir($path)) {
            mkdir($path, 0777, true);
        }

        $html = view('invoices.pdf', compact('invoice'))->render();
        $dompdf->loadHtml($html);
        $dompdf->render();
        $output = $dompdf->output();
        file_put_contents($path . $invoice->id . '.pdf', $output);

        return $path . $invoice->id . '.pdf';
    }
}

Почему это ужасно?

Жесткая связанность: PdfExporter привязан к Dompdf . Если вы захотите использовать Tcpdf , вам придется изменить этот код.
Кошмар тестирования: Чтобы написать юнит-тест для этого кода, вы обязаны генерировать реальный PDF-файл и записывать его в файловую систему. Ваши тесты будут медленными, хрупкими и потребуют места на диске.
Нарушение SRP (принципа единственной ответственности): Этот класс делает слишком много всего. Он генерирует HTML, сохраняет файл и генерирует PDF.
Магические строки: Путь жестко зашит в код.

Этот код негибок. Его нельзя расширить, и он сопротивляется любым изменениям.

5. Обзор решения

Внедрение зависимостей (Dependency Injection) — это принцип, который гласит: класс не должен самостоятельно инициализировать свои зависимости; он должен запрашивать их извне.

Основная идея

Вместо того чтобы класс сам искал свои зависимости (через вызовы new или static ), он получает их извне.

Основные участники

Клиент (Client): Класс, которому требуется сервис (например, PdfExporter ).
Зависимости (Dependencies): Сервисы, необходимые клиенту (например, PdfInterface , FileSystemInterface ).
Инжектор (Injector): Сущность, которая создает зависимости и передает их клиенту (например, контейнер сервисов Laravel).

Ментальная модель

Воспринимайте метод __construct как контракт. Это обещание: «Если вы (контейнер) передадите мне эти объекты, со всем остальным я справлюсь сам». Вы пишете свой код так, чтобы ему передавали готовые объекты, вместо того чтобы он охотился за ними.

Преимущества

Слабая связанность (Loose Coupling): Ваш класс зависит только от интерфейса, а не от конкретной реализации.
Высокая тестируемость: Вы можете легко передавать «моки» (Mock) в конструктор.
Повторное использование кода: Зависимость можно легко подменять для разных окружений.

Компромиссы

Накладные расходы на абстракцию: У вас появится больше интерфейсов и классов.
Косвенность: Иногда становится сложнее отследить, откуда именно берется та или иная реализация.

6. UML-диаграмма

Архитектура контейнера сервисов Laravel

Пояснение: Контейнер знает о ConcreteDependencyA и ConcreteDependencyB . Client знает только про DependencyInterface . Контейнер внедряет правильную конкретную реализацию в клиент во время выполнения программы (runtime).

7. Пример на чистом PHP

Давайте рефакторим PdfExporter , используя синтаксис чистого PHP 8+, чтобы продемонстрировать всю мощь DI.

До рефакторинга

(Как показано в разделе «Боль» — жестко закодированный Dompdf, пути к файлам и т. д.)

После рефакторинга

Шаг 1: Определение интерфейсов (контракт)

 interface PdfGeneratorInterface
{
    public function generate(string $html): string; // returns PDF binary string
}

interface FileStorageInterface
{
    public function save(string $path, string $content): bool;
}

Шаг 2: Создание реализаций

 class DompdfGenerator implements PdfGeneratorInterface
{
    public function __construct(
        private array $options = [] // configuration passed via constructor
    ) {}

    public function generate(string $html): string
    {
        $dompdf = new \Dompdf\Dompdf($this->options);
        $dompdf->loadHtml($html);
        $dompdf->render();
        return $dompdf->output();
    }
}

class LocalFileStorage implements FileStorageInterface
{
    public function __construct(
        private string $basePath
    ) {}

    public function save(string $path, string $content): bool
    {
        $fullPath = rtrim($this->basePath, '/') . '/' . ltrim($path, '/');
        $directory = dirname($fullPath);
        if (!is_dir($directory)) {
            mkdir($directory, 0777, true);
        }
        return file_put_contents($fullPath, $content) !== false;
    }
}

Шаг 3: Рефакторинг клиента

 class PdfExporter
{
    // Dependency Injection via Constructor Promotion (PHP 8)
    public function __construct(
        private readonly PdfGeneratorInterface $pdfGenerator,
        private readonly FileStorageInterface $fileStorage
    ) {}

    public function export(Invoice $invoice): string
    {
        $html = view('invoices.pdf', compact('invoice'))->render();
        $pdfContent = $this->pdfGenerator->generate($html);

        $path = "invoices/{$invoice->id}.pdf";
        $this->fileStorage->save($path, $pdfContent);

        return $path;
    }
}

Шаг 4: Ручной инжектор («контейнер»)

 // This is essentially what Laravel does for you.
$generator = new DompdfGenerator(['isRemoteEnabled' => true]);
$storage = new LocalFileStorage(storage_path('app'));

$exporter = new PdfExporter($generator, $storage);
$exporter->export($invoice);

Что нам удалось улучшить?

Тестируемость: В тестах мы можем передать MockPdfGenerator , который возвращает фиктивную строку, не обращаясь к файловой системе или библиотеке для генерации PDF.
Открытость/закрытость (OCP): Если нам понадобится TcpdfGenerator , мы просто реализуем интерфейс. Нам не придется трогать PdfExporter .
Единственная ответственность (SRP): У каждого класса теперь ровно одна задача.

8. Пример из внутренностей Laravel

Где Laravel использует этот подход? Везде.

HTTP-ядро (HTTP Kernel)

Вы когда-нибудь заглядывали внутрь app/Http/Kernel.php ? Там обрабатываются middleware.
Когда поступает запрос (Request), ядро разрешает зависимости для Router и ControllerDispatcher . Оно не создает их через оператор new ; оно запрашивает их у контейнера.

Метод handle в контроллерах

Laravel не просто разрешает зависимости контроллеров — он разрешает параметры внутри их методов.

 class InvoiceController {
    public function show(InvoiceRepository $repo, int $id) { ... }
}

Когда маршрутизатор Laravel обращается к этому контроллеру, он анализирует сигнатуру метода. Он использует контейнер для сборки InvoiceRepository (и всех его вложенных зависимостей) и внедряет его вместе со скалярным параметром $id .

Сервис-провайдеры (Service Providers)

Сервис-провайдеры служат центральным местом для «связывания» (Binding) сущностей внутри контейнера. Именно так мы сообщаем контейнеру, какую конкретную реализацию класса следует использовать при запросе интерфейса.

 // In a Service Provider
public function register(): void
{
    $this->app->bind(PdfGeneratorInterface::class, DompdfGenerator::class);
}

Это «рецепт», который говорит контейнеру: «Когда кто-то запрашивает PdfGeneratorInterface , отдай ему DompdfGenerator ».

9. Пример реального приложения на Laravel

Давайте создадим систему платежного шлюза для приложения электронной коммерции.

Сценарий: Вы поддерживаете Stripe и PayPal. Бизнес-логика (например, обработка корзины) не должна зависеть от того, какой именно шлюз используется.

Шаг 1: Интерфейс

 namespace App\Contracts\Payment;

interface PaymentGatewayInterface
{
    public function charge(array $customerData, float $amount): array;
    public function refund(string $transactionId, float $amount): bool;
}

Шаг 2: Конкретные реализации

 namespace App\Services\Payment;

use App\Contracts\Payment\PaymentGatewayInterface;

class StripeGateway implements PaymentGatewayInterface { ... }

class PayPalGateway implements PaymentGatewayInterface { ... }

Шаг 3: Контроллер

 namespace App\Http\Controllers;

use App\Contracts\Payment\PaymentGatewayInterface;

class CheckoutController extends Controller
{
    public function __construct(
        private readonly PaymentGatewayInterface $paymentGateway
    ) {}

    public function store(Request $request)
    {
        // The controller uses the interface.
        // It doesn't know if it's Stripe or PayPal.
        $result = $this->paymentGateway->charge(
            $request->only(['email', 'amount']),
            $request->amount
        );

        return response()->json($result);
    }
}

Шаг 4: Привязка в сервис-провайдере

 namespace App\Providers;

use App\Contracts\Payment\PaymentGatewayInterface;
use App\Services\Payment\StripeGateway;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // Magic! We bind the interface to the concrete class.
        // Now, whenever a controller asks for PaymentGatewayInterface,
        // it gets StripeGateway.
        $this->app->bind(PaymentGatewayInterface::class, StripeGateway::class);
    }
}

Теперь, если бизнесу потребуется переключиться на PayPal для определенной страны, вы можете использовать контекстную привязку (Contextual Binding) в сервис-провайдере или обновить одну строчку в сервис-провайдере. Сам контроллер остается чистым и независимым.

10. Применение принципов SOLID

Внедрение зависимостей (Dependency Injection) — это фундамент, на котором строятся принципы SOLID.

D — Принцип инверсии зависимостей (Dependency Inversion Principle, DIP):
Это самый главный пункт. DI напрямую реализует DIP. Модули верхнего уровня ( CheckoutController ) не должны зависеть от модулей нижнего уровня ( StripeGateway ). И те, и другие должны зависеть от абстракций ( PaymentGatewayInterface ). DI — это механизм, который делает такое физическое разделение возможным.
O — Принцип открытости/закрытости (Open/Closed Principle, OCP):
Контроллер CheckoutController закрыт для модификации (мы его не трогаем), но открыт для расширения (мы можем добавить PayPalGateway и изменить привязку). Контейнер делает это расширение подключаемым.
S — Принцип единственной ответственности (Single Responsibility Principle, SRP):
Внедряя зависимости, мы заставляем классы фокусироваться на своей основной задаче. Контроллер CheckoutController обрабатывает HTTP-запросы. Класс StripeGateway выполняет вызовы API. Если бы мы создавали зависимости через new , контроллер был бы вынужден знать секретный ключ Stripe API, что нарушает SRP.
L — Принцип подстановки Барбары Лисков (Liskov Substitution Principle, LSP):
Контейнер опирается на этот принцип. Поскольку StripeGateway и PayPalGateway реализуют один и тот же интерфейс, они взаимозаменяемы. Контроллер (который работает с интерфейсом) будет функционировать корректно независимо от того, какой именно класс ему передан.

11. Плюсы и минусы

Преимущества

Гибкость: Вы можете подменять реализации, изменив всего одну строчку в сервис-провайдере.
Тестируемость: Возможность создавать моки (mock) для зависимостей — это главное преимущество при модульном тестировании (unit testing).
Слабая связанность (Decoupled Architecture): Изменения в одной части системы с меньшей вероятностью сломают другую.

Издержки

Косвенность (Indirection): Сложнее проследить «путь» выполнения кода. Вы видите PaymentGatewayInterface и вынуждены искать, какой конкретно класс к нему привязан.
Накладные расходы: Вы создаете больше файлов (интерфейсы, сервис-провайдеры, DTO). Для крошечных одноразовых скриптов это может быть избыточно.
Сложность: Если вы активно используете сервис-контейнер, вам нужно понимать такие возможности, как контекстная привязка, теги и сервис-провайдеры, чтобы эффективно проводить отладку.

Когда это оправдано?

Внедрение зависимостей следует использовать, когда вы пишете логику, которая может измениться (например, бизнес-правила, внешние интеграции), или когда вам необходимо покрыть класс модульными тестами.

12. Когда НЕ стоит это использовать

3 зелёных света (ИСПОЛЬЗУЙТЕ)

Внешние сервисы: Вы интегрируетесь с внешним API (например, Mailchimp, AWS S3).
Уровень персистентности: Вам нужно взаимодействовать с базой данных или кэшем.
Бизнес-логика: У вас есть сложная доменная логика, требующая серьезного покрытия модульными тестами.

3 красных света (ИЗБЕГАЙТЕ)

Объекты передачи данных (DTO): DTO обычно хранят простые типизированные данные (например, UserInput ). Им редко требуются зависимости. Автоматическое внедрение (autowiring) для DTO — чаще всего избыточность.
Крошечные скрипты: Для простой Artisan-команды, которая просто очищает кэш, прямой вызов Cache::flush() (фасад) намного быстрее и проще, чем внедрение контракта.
Контроллеры с примитивными типами: Иногда контроллеру нужен просто $request или $userId . Laravel справляется с этим, но не стоит создавать целый сервис-класс только ради того, чтобы внедрить число ( int ).

13. Распространенные ошибки

1. Оверинжиниринг (синдром «на всякий случай»)

«Я могу захотеть перейти с MySQL на Postgres, поэтому я определю интерфейс!»
Хотя опасение понятное, многие разработчики преждевременно абстрагируют простые CRUD-операции. Создавайте абстракции только тогда, когда у вас реально есть две реализации или когда они конкретно нужны вам для создания моков. Здесь применим принцип YAGNI (You Ain't Gonna Need It — вам это не понадобится).

2. Путаница между сервис-провайдерами и бизнес-логикой

Размещение бизнес-логики внутри методов boot() или register() сервис-провайдеров.

 // BAD: Service Provider doing business logic
public function boot() {
    $user = User::first(); // NO! This runs on every request!
}

Сервис-провайдеры предназначены исключительно для регистрации сервисов. Метод boot() должен выполнять только логику регистрации (например, Route::macro , Gate::define ).

3. Использование контейнера в качестве Service Locator

 // The "Service Locator" Anti-Pattern
class OrderService {
    public function process(Order $order) {
        $payment = app(PaymentInterface::class); // BAD!
    }
}

Вы вызываете функцию app() внутри класса. Это скрывает зависимость. Класс перестает быть «самодокументируемым» через свой конструктор. Всегда используйте внедрение через конструктор (Constructor Injection).

4. Отсутствие привязок по умолчанию

Если вы не привяжете интерфейс в сервис-провайдере, Laravel попытается создать экземпляр самого интерфейса напрямую и выдаст ошибку привязки (binding error).
Всегда убеждайтесь, что ваши привязки существуют в методе register() .

14. Частые вопросы на собеседованиях

Для начинающих / Middle

В: Что такое внедрение зависимостей (Dependency Injection)? О: Это паттерн проектирования, при котором класс получает свои зависимости из внешнего источника, а не создает их внутри себя.
В: Откуда Laravel знает, что именно нужно внедрить, когда я указываю тип интерфейса? О: Laravel использует сервис-контейнер. Вы должны определить привязку в сервис-провайдере (обычно AppServiceProvider ), которая говорит контейнеру, какой конкретно класс следует использовать для этого интерфейса.
В: В чем разница между bind и singleton в сервис-контейнере? О: Метод bind создает новый экземпляр каждый раз при разрешении зависимости. Метод singleton разрешает экземпляр один раз и использует его повторно на протяжении всего жизненного цикла текущего запроса.
В: Является ли внедрение зависимостей тем же самым, что и сервис-контейнер? О: Нет. Внедрение зависимостей — это паттерн (то, как структурируется код). Сервис-контейнер — это инструмент (помощник), который автоматизирует процесс внедрения в Laravel.

Для Senior / Архитекторов

В: Объясните разницу между внедрением через конструктор (Constructor Injection), через сеттер (Setter Injection) и через метод (Method Injection). Какой вариант предпочтительнее и почему? О: Внедрение через конструктор (зависимости передаются в __construct ) является предпочтительным, поскольку оно гарантирует, что объект находится в валидном состоянии сразу после создания. Внедрение через сеттер позволяет устанавливать необязательные зависимости позже, но может привести к «временной связанности» (когда объект собран лишь частично). Внедрение через метод передает зависимости напрямую в конкретный метод, что полезно для динамических сценариев (например, выбор способа оплаты).
В: Как бы вы реализовали автоматическое разрешение зависимостей, у которых есть примитивные аргументы (например, $apiKey )? О: Вы можете использовать контекстную привязку (Contextual Binding) в сервис-провайдере ( $this->app->when(Service::class)->needs('$apiKey')->give('value') ) либо применить паттерн Фабрика (Factory Pattern) для создания объекта.
В: Как контейнер Laravel справляется с циклическими зависимостями? О: По умолчанию он выбросит исключение LogicException (обнаружена циркулярная зависимость). Контейнер не может собрать класс, которому требуется он сам (например, классу А нужен Б, а классу Б нужен А).
В: Каковы последствия активного использования контейнера для производительности? О: Разрешение зависимостей через рефлексию (автообнаружение) работает медленнее, чем жестко закодированные вызовы new . Тем не менее, Laravel кэширует разрешенные привязки с помощью команды php artisan optimize , превращая разрешение в поиск по массиву, что нивелирует большинство проблем с производительностью.

15. Интерактивное практическое задание

Вы — разработчик в команде, создающей SaaS-приложение. Вам достался в наследство следующий код. Он работает, но он хрупок и его невозможно протестировать.

Ваша задача: Рефакторить этот код с использованием внедрения зависимостей. Определите необходимые интерфейсы, создайте классы реализаций и обновите сервис-провайдер.

Требование:
Нам нужно отправлять приветственное письмо при регистрации пользователя. Класс UserRegistrationService напрямую использует библиотеку SendGridEmail . Он также напрямую взаимодействует с моделью User через статичные вызовы Eloquent.

 // BAD CODE
use App\Models\User;
use SendGrid\Mail\Mail;

class UserRegistrationService
{
    public function register(array $data): User
    {
        // Validates that email is unique
        if (User::where('email', $data['email'])->exists()) {
            throw new \Exception('User already exists');
        }

        // Creates the user
        $user = User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
        ]);

        // Sends welcome email via SendGrid
        $email = new Mail();
        $email->setFrom("admin@example.com", "Admin");
        $email->setSubject("Welcome!");
        $email->addTo($user->email, $user->name);
        $email->addContent("text/html", "Hello {$user->name}");

        $sendgrid = new \SendGrid(getenv('SENDGRID_API_KEY'));
        $response = $sendgrid->send($email);

        if ($response->statusCode() !== 202) {
            \Log::error('Failed to send welcome email', ['user' => $user->id]);
        }

        return $user;
    }
}

Подумайте над следующими вопросами: Как бы вы это протестировали? Как заменить почтовый сервис на Mailgun? Как подменить проверку в базе данных с помощью мока?

(Мы не приводим здесь готовое решение — наденьте кепку Senior-разработчика и сделайте рефакторинг самостоятельно!)

16. Итоговая ментальная модель

Чтобы закрепить материал, запомните эти три фразы:

Определение в одно предложение: Внедрение зависимостей — это принцип проектирования, при котором класс запрашивает то, что ему нужно (через конструктор), вместо того чтобы искать это самостоятельно.
Интуиция в одно предложение: Хватит создавать инструменты прямо внутри фабрики; принесите инструменты к рабочему.
Правило принятия решений в одно предложение: Если в классе есть логика, которую трудно тестировать или которая может измениться, вынесите эту логику наружу и внедряйте её; в противном случае сохраняйте код простым.

17. Связанные концепции

Принципы SOLID: Внедрение зависимостей (Dependency Injection) является практической реализацией принципа инверсии зависимостей (DIP). Оно работает в тандеме с принципом открытости/закрытости (Open/Closed) для обеспечения возможности расширения.
Паттерны проектирования:
- Паттерн «Фабрика» (Factory Pattern): Часто используется вместе с DI. Фабрика создает сложные объекты, в то время как DI использует фабрику для предоставления объекта.
- Паттерн «Стратегия» (Strategy Pattern): DI — это то, как вы внедряете конкретную стратегию в контекст.
- Паттерн «Наблюдатель» (Observer Pattern): Система событий в Laravel использует контейнер для разрешения слушателей.
Внутреннее устройство Laravel:
- Сервис-провайдеры (Service Providers): Конфигурационный слой, где вы регистрируете привязки (bindings).
- Фасады (Facades): «Выключатель света» для контейнера.
- Модели Eloquent (Eloquent Models): Хотя Eloquent в своей основе не зависит строго от DI, вы можете внедрять интерфейсы репозиториев в свои контроллеры для абстрагирования построителя запросов Eloquent.
Корпоративные паттерны:
- Инверсия управления (IoC): DI является подмножеством принципа IoC. Фреймворк (контейнер) берет на себя управление жизненным циклом объектов.