Dependency Injection di Laravel — Constructor, Method, dan IoC Container

Kalau kamu sudah mulai ngoding Laravel dan sering lihat kelas yang constructornya diisi parameter aneh-aneh — “ini dari mana datangnya? Kan tidak pernah di-new manual?” — itu adalah Dependency Injection yang sedang bekerja.

Topik ini sering terasa misterius karena Laravel melakukan banyak hal “otomatis” di balik layar. Artikel ini akan buka tutupnya satu per satu: mulai dari kenapa DI ada, lalu tiga cara pakainya, sampai bagaimana Laravel tahu harus inject apa.

Kita mulai dari masalahnya dulu.

🤔 Masalah yang DI Selesaikan

Bayangin kamu lagi bikin fitur artikel di blog. Ada ArticleController yang butuh ArticleService untuk logika bisnisnya.

Cara paling naif yang langsung terpikirkan:

class ArticleController extends Controller
{
    public function index()
    {
        // Langsung bikin object di dalam controller
        $service = new ArticleService();

        return $service->getAll();
    }
}

Kelihatannya tidak ada masalah. Tapi coba bayangkan tiga skenario ini:

Skenario 1: ArticleService butuh ArticleRepository untuk akses database. Jadi kamu harus new ArticleRepository() di dalam ArticleService. Dan ArticleRepository butuh koneksi database. Dan seterusnya — kamu tiba-tiba sedang merakit rantai panjang object secara manual.

Skenario 2: Kamu mau test ArticleController. Tapi new ArticleService() di dalamnya langsung memanggil database sungguhan — test-mu tidak bisa jalan tanpa database aktif.

Skenario 3: Kamu mau ganti ArticleService dengan versi berbeda (misalnya yang pakai cache). Kamu harus cari semua tempat yang nulis new ArticleService() dan ganti satu per satu.

Dependency Injection adalah solusinya. Alih-alih kelas yang membuat dependensinya sendiri, dependensi itu diberikan dari luar. Kelas cukup bilang “aku butuh ini” — urusan siapa yang menyediakan, bukan urusannya lagi.

🔧 Constructor Injection — “Kasih Sebelum Mulai”

Analoginya

Bayangin kamu seorang chef baru yang mulai kerja di restoran. Sebelum kamu mulai masak apapun, manajernya sudah menyiapkan semua yang kamu butuhkan di meja dapur: pisau, talenan, dan bumbu dasar.

Kamu tidak perlu keluar dan beli sendiri. Kamu tidak perlu tahu bumbu itu dari warung mana. Kamu tinggal masak.

Constructor Injection persis seperti itu — semua yang dibutuhkan kelas sudah tersedia sejak object pertama kali dibuat, sebelum method apapun dipanggil.

Kapan Cocok?

Kalau dependensi dipakai di banyak method dalam kelas yang sama. Inject sekali di constructor, pakai di mana saja.

Kodenya

Studi kasus: ArticleController butuh ArticleService untuk semua operasinya.

📁 app/Services/ArticleService.php

<?php

namespace App\Services;

use App\Models\Article;
use Illuminate\Support\Collection;

class ArticleService
{
    public function getAll(): Collection
    {
        return Article::with('user')->latest()->get();
    }

    public function getPublished(): Collection
    {
        return Article::with('user')
            ->where('status', 'published')
            ->latest('published_at')
            ->get();
    }

    public function findOrFail(int $id): Article
    {
        return Article::findOrFail($id);
    }
}

📁 app/Http/Controllers/ArticleController.php

<?php

namespace App\Http\Controllers;

use App\Services\ArticleService;
use Illuminate\Http\JsonResponse;

class ArticleController extends Controller
{
    // $articleService tersimpan sebagai property —
    // bisa dipakai oleh index(), show(), store(), dan method lain
    public function __construct(
        private ArticleService $articleService
    ) {}

    public function index(): JsonResponse
    {
        $articles = $this->articleService->getPublished();

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

    public function show(int $id): JsonResponse
    {
        $article = $this->articleService->findOrFail($id);

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

📌 Perhatikan — ArticleController tidak pernah nulis new ArticleService(). Dia hanya mendeklarasikan bahwa dia butuh ArticleService. Laravel yang akan menyediakannya secara otomatis saat controller dipanggil.

Cara Kerja di Baliknya

Ketika ada request masuk ke route yang menuju ArticleController, Laravel membaca constructor-nya: “Oh, butuh ArticleService. Oke, aku buatkan.” Lalu object ArticleService dibuat dan dimasukkan ke constructor secara otomatis. Ini yang disebut auto-resolve — dan kita akan bahas lebih dalam di bagian IoC Container.

💉 Method Injection — “Kasih Saat Dibutuhkan”

Analoginya

Masih di restoran yang sama. Kali ini ada tamu yang pesan menu spesial yang butuh peralatan khusus — blow torch untuk membakar crème brûlée.

Blow torch itu tidak perlu ada di meja kamu sepanjang waktu. Kamu tidak pakai setiap hari. Kamu minta ke dapur hanya ketika ada pesanan menu itu saja.

Method Injection seperti itu — dependensi hanya disediakan ketika method tertentu dipanggil, tidak perlu ada sepanjang hidup object.

Kapan Cocok?

Kalau dependensi hanya dipakai di satu method tertentu — tidak perlu dibawa ke seluruh kelas.

Kodenya

Studi kasus: ada CommentController yang butuh ArticleService hanya di satu method — untuk validasi apakah artikel yang mau dikomentari itu ada.

📁 app/Http/Controllers/CommentController.php

<?php

namespace App\Http\Controllers;

use App\Http\Requests\StoreCommentRequest;
use App\Services\ArticleService;
use App\Services\CommentService;
use Illuminate\Http\JsonResponse;

class CommentController extends Controller
{
    // CommentService dipakai di banyak method → layak di constructor
    public function __construct(
        private CommentService $commentService
    ) {}

    // ArticleService hanya dibutuhkan di method ini saja → method injection
    public function store(StoreCommentRequest $request, ArticleService $articleService): JsonResponse
    {
        // Pastikan artikel yang dituju benar-benar ada
        $article = $articleService->findOrFail($request->article_id);

        $comment = $this->commentService->create(
            $request->validated(),
            $article,
            $request->user()
        );

        return response()->json($comment, 201);
    }
}

📌 ArticleService hanya ada di parameter method store(). Method lain di controller ini tidak akan mendapat — dan tidak butuh — ArticleService sama sekali. Laravel tetap auto-resolve dengan cara yang sama.

Method Injection di Route Closure

Ada satu tempat lagi yang sering dipakai untuk method injection: langsung di route closure. Cocok untuk endpoint ringan yang tidak butuh controller tersendiri.

📁 routes/api.php

use App\Services\ArticleService;
use Illuminate\Http\Request;

// Laravel inject ArticleService langsung ke closure ini
Route::get('/articles/published', function (Request $request, ArticleService $service) {
    return $service->getPublished();
});

📌 Persis seperti di controller — tulis type-hint di parameter, Laravel yang sediakan. Tidak perlu new ArticleService() di mana pun.

📦 IoC Container — “Otak di Balik Semuanya”

Analoginya

Sekarang kamu mungkin bertanya: “Oke, tapi Laravel tahu dari mana harus inject apa?”

Bayangin ada gudang besar di restoran itu. Gudang ini menyimpan daftar semua peralatan yang tersedia, stoknya, dan aturan khusus kalau ada peralatan yang perlu disiapkan dengan cara tertentu sebelum diberikan.

Ketika chef butuh sesuatu, chef tidak pergi ke gudang sendiri. Ada petugas gudang yang bertugas: membaca kebutuhan chef, mengambil dari gudang, menyiapkan sesuai aturan, lalu mengantarkan.

IoC Container (Inversion of Control Container) adalah petugas gudang itu. Di Laravel, dia diakses lewat app() atau App::make(). Dan aturan-aturan khusus tadi? Itu yang kita tulis di Service Provider.

Auto-resolve — Saat Kelas Tidak Butuh Konfigurasi

Untuk kelas biasa seperti ArticleService yang tidak punya dependensi kompleks, IoC Container bisa langsung membuatnya tanpa perlu instruksi apapun. Cukup type-hint, Laravel resolve sendiri.

// Laravel resolve ArticleService otomatis — kamu tidak perlu daftarkan apapun
$service = app(ArticleService::class);

// Atau lewat facade
$service = App::make(ArticleService::class);

Ini jalan karena Laravel membaca constructor ArticleService, melihat dependensinya, membuat dependensi itu dulu, lalu membuat ArticleService-nya. Rekursif sampai semua dependensi terpenuhi.

Binding — Saat Interface Perlu Dipetakan ke Implementasi

Auto-resolve tidak bisa jalan untuk interface. Kalau kamu type-hint dengan ArticleRepositoryInterface, Laravel tidak tahu implementasi mana yang harus dipakai — ada banyak kemungkinan.

Di sinilah binding dibutuhkan.

Studi kasus: CommentService bergantung pada CommentRepositoryInterface, bukan langsung ke Eloquent.

📁 app/Contracts/CommentRepositoryInterface.php

<?php

namespace App\Contracts;

use App\Models\Comment;
use Illuminate\Support\Collection;

interface CommentRepositoryInterface
{
    public function getUnapproved(): Collection;
    public function approve(int $commentId): void;
}

📁 app/Repositories/EloquentCommentRepository.php

<?php

namespace App\Repositories;

use App\Contracts\CommentRepositoryInterface;
use App\Models\Comment;
use Illuminate\Support\Collection;

class EloquentCommentRepository implements CommentRepositoryInterface
{
    public function getUnapproved(): Collection
    {
        return Comment::where('is_approved', false)->latest()->get();
    }

    public function approve(int $commentId): void
    {
        Comment::findOrFail($commentId)->update(['is_approved' => true]);
    }
}

📁 app/Providers/AppServiceProvider.php

Di sinilah kita “mendaftarkan aturan” ke IoC Container — interface ini dipasangkan ke implementasi ini.

<?php

namespace App\Providers;

use App\Contracts\CommentRepositoryInterface;
use App\Repositories\EloquentCommentRepository;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // "Kalau ada yang minta CommentRepositoryInterface,
        //  berikan EloquentCommentRepository."
        $this->app->bind(
            CommentRepositoryInterface::class,
            EloquentCommentRepository::class
        );
    }
}

📁 app/Services/CommentService.php

Service ini tidak tahu apakah yang dipakai Eloquent, cache, atau API — dia hanya tahu kontraknya.

<?php

namespace App\Services;

use App\Contracts\CommentRepositoryInterface;
use Illuminate\Support\Collection;

class CommentService
{
    public function __construct(
        private CommentRepositoryInterface $commentRepository
    ) {}

    public function getUnapproved(): Collection
    {
        return $this->commentRepository->getUnapproved();
    }

    public function approve(int $commentId): void
    {
        $this->commentRepository->approve($commentId);
    }
}

📌 Kalau besok kamu mau ganti implementasi repository — misalnya pakai cache untuk performa lebih cepat — kamu hanya ubah satu baris di AppServiceProvider. CommentService, controller, dan semua kode lain tidak perlu disentuh sama sekali.

bind vs singleton — Kapan Pakai Yang Mana?

Ada dua cara binding yang paling sering dipakai, dan perbedaannya penting:

// bind → buat object BARU setiap kali diminta
$this->app->bind(
    CommentRepositoryInterface::class,
    EloquentCommentRepository::class
);

// singleton → buat object SEKALI, lalu pakai ulang object yang sama
$this->app->singleton(
    ArticleService::class,
    ArticleService::class
);

📌 Untuk kebanyakan service di blog kita, singleton sudah cukup — tidak ada state yang perlu di-reset antar penggunaan. Pakai bind kalau kamu butuh object yang benar-benar fresh setiap kali.

🗺️ Gambaran Besar — Alur Lengkap

Ini alur yang terjadi dari request masuk sampai response keluar, dikaitkan dengan DI:

Request masuk
      ↓
Router menemukan ArticleController@store
      ↓
IoC Container membaca constructor ArticleController
  → Butuh ArticleService
      ↓
IoC Container membaca constructor ArticleService
  → Tidak ada dependensi → langsung dibuat
      ↓
ArticleService selesai dibuat
      ↓
ArticleController dibuat, ArticleService dimasukkan ke constructor
      ↓
Method store() dipanggil
  → Butuh StoreArticleRequest (method injection) → dibuat
      ↓
Response dikembalikan

Dan struktur file-nya:

app/
├── Contracts/
│   └── CommentRepositoryInterface.php  ← kontrak repository
│
├── Http/
│   ├── Controllers/
│   │   ├── ArticleController.php        ← constructor injection
│   │   └── CommentController.php        ← constructor + method injection
│   └── Requests/
│       └── StoreCommentRequest.php
│
├── Services/
│   ├── ArticleService.php               ← di-inject lewat constructor
│   └── CommentService.php              ← bergantung pada interface
│
├── Repositories/
│   └── EloquentCommentRepository.php   ← implementasi konkret
│
└── Providers/
    └── AppServiceProvider.php          ← tempat binding interface → implementasi

🧭 Kapan Pakai Yang Mana?

Constructor Injection ketika dependensi dipakai di banyak method dalam satu kelas. Ini pilihan default — kalau ragu, pakai ini.

Method Injection ketika dependensi hanya dipakai di satu method tertentu, atau di route closure yang terlalu kecil untuk dibuatkan controller sendiri.

IoC Container + Binding ketika kamu type-hint dengan interface, atau butuh kontrol lebih atas cara Laravel membuat suatu object (misalnya mau inject konfigurasi tertentu).

📊 Perbandingan Singkat