Understanding Laravel's Service Container: How Does It Resolve Dependencies?

29 Eyl 08:17

Laravel’ın service container’ı aslında bir “çözüm makinesi” gibi çalışıyor; bir sınıfı `app()->make(Foo::class)` ile istediğimizde container, o sınıfın ctor‑unda tanımlı diğer sınıfları da tarayıp otomatik olarak enjekte ediyor. Bunun arkasında Reflection API var; container, sınıfın constructor parametre tiplerini okuyup, eğer o tip daha önce bir binding olarak kaydedildiyse (örneğin `bind('RepoInterface', RepoEloquent::class)`) o binding’i çözümleyip instance oluşturuyor. Eğer binding yoksa doğrudan sınıf ismi üzerinden yeni bir obje yaratıyor. Binding kaydetmek iki şekilde yapılabilir: `bind` (her çağırmada yeni bir obje üretir) ve `singleton` (ilk oluşturulup aynı örnek her istekte geri döner). Benim projelerimde “singleton” genelde config, log vs. tek seferlik nesneler için, “bind” ise request‑a‑request yeni state‑i olan servisler için tercih ediyorum; çünkü state tutmak istemediğimizde her seferinde temiz bir nesne alıyoruz. Kontekstüel binding ise bir sınıfın aynı interface’i farklı bir implementasyonla almasını sağlıyor; örneğin `MailController` içinde `MailServiceInterface` yerine `SmtpMailService` kullanırken, `NotificationController` içinde aynı interface’i `SendgridMailService` ile bağlamak istiyorsak: ```php $this->app->when(MailController::class) ->needs(MailServiceInterface::class) ->give(SmtpMailService::class); $this->app->when(NotificationController::class) ->needs(MailServiceInterface::class) ->give(SendgridMailService::class); ``` Valla bu yapı sayesinde kodum daha temiz ve test edilebilir oluyor; birim testte sadece interface’i mock’layıp container’a bind ediyorum, gerçek uygulamada ise gerçek implementasyon otomatik çözülüyor. Bence service container, Laravel’ın “magical” kısmı değil, aslında çok net bir DI (Dependency Injection) mekanizması; bir kez kavradıktan sonra projelerde dependency yönetimi bir çocuk oyuncağı gibi geliyor.

29 Eyl 08:51

Laravel’s service container is basically a tiny IoC kernel that keeps a map of abstract types to concrete factories. When you call `app()->make(Foo::class)` it looks up the binding; if none exists it falls back to reflection, reads the constructor’s type‑hints and recursively resolves each dependency the same way. That’s why you can just type‑hint an interface or another class in a controller’s constructor and Laravel will inject the right object automatically. Bindings are registered in a service provider via `$this->app->bind()` for transient (a fresh instance on every resolve) or `$this->app->singleton()` for a single shared instance. The difference shows up when you need stateful objects (like a cache client) – singleton keeps the same instance, bind creates a new one each time. Contextual binding lets you override the default for a specific consumer, e.g. `$this->app->when(OrderController::class)->needs(PaymentGateway::class)->give(function () { return new StripeGateway(); });`. In my projects I often start with simple bindings, then switch to singletons for services that hold connections, and use contextual bindings when a controller needs a different implementation than the rest of the app. This pattern mirrors what we do with Spring’s `@Bean` scopes and qualifier annotations, just with a more PHP‑ish syntax.