Frontend'ciden Backend'ciye : Dependency Injection (DI) Nedir?

bash
Kopyala
function UserProfile() {
const api = new Axios(); // her component'te kendi axios'unu oluşturuyor
api.get("/user");
}

• React kullanıyorsan → Context açtın.
• Vue kullanıyorsan → Provide/Inject kullandın.
• Angular kullanıyorsan → Dependency Injection zaten default geliyor.

• Çay yapmak istiyorsun → Su ısıtıcısına bağımlısın.
• Su ısıtıcısı çalışıyor → Elektriğe bağımlı.
• Elektrik geliyor → Elektrik şirketine bağımlı.
• Yani bir şeyi yapmak için başka bir şeye ihtiyacın varsa, bağımlısındır. Bu kaçınılmazdır. Sorun bağımlı olmakta değil; nasıl bağımlı olduğundadır.

bash
Kopyala
function RegisterForm() {
  const emailService = new EmailService(); // Her yerde new!
  const handleRegister = () => {
    emailService.send("user@example.com", "Hoş geldiniz!");
  };
  return <button onClick={handleRegister}>Kayıt Ol</button>;
}

• Bu component sadece EmailService ile çalışabiliyor.
• Yarın SMS ile bildirim göndermek istersen, bu component'i değiştirmek zorundasın.
• Yani "RegisterForm = EmailService" şeklinde sıkı sıkıya bağlanmış durumda.
• İleride mail göndermek yerine SMS göndermek istedin o zaman ne yapman gerekecek ?
• ❌ Ya EmailService’i değiştireceksin
• ❌ Ya if-else ekleyip çorba yapacaksın
• ❌ Ya da tamamen başka bir sınıf yazacaksın

Çözüm: Karar Vermeyi Sınıfın İçinden Al, Dışarı Taşı

• Problem şuydu: RegisterForm component’i nasıl bildirim gönderileceğine kendisi karar veriyordu. Bu da component’i sadece EmailService’e sıkı sıkıya bağlı hale getiriyordu. Yani esnekliği yoktu, test yazmak zordu ve ileride yeni bildirim tipleri eklemek maliyetli oluyordu.
• Çözüm basit: Component’in içinde new EmailService() oluşturmak yerine, bağımlılığı dışarıdan veriyoruz. Böylece component “bildirim gönderilmesini istiyorum” diyor, “nasıl gönderildiği” ile ilgilenmiyor.

• bash
  Kopyala
  function RegisterForm({ messageService }) {
    const handleRegister = () => {
      messageService.send("user@example.com", "Hoş geldiniz!");
    };
  - return <button onClick={handleRegister}>Kayıt Ol</button>;
  }
  //Kullanımı
  <RegisterForm messageService={new EmailService()} />
  <RegisterForm messageService={new SmsService()} />

• Artık ne kazandık?
  • RegisterForm her türlü mesaj servisiyle çalışabilir (email, SMS, push…)
  • Test etmek kolay (mock servis verebilirsin)
  • Component esnek ve değişime açık

• Component veya sınıf, belirli bir başka sınıfa bağımlıdır.
• Değişiklik gerektiğinde bağımlı olduğu sınıfı veya component’i değiştirmek zorunda kalırsın.
• Örnek: RegisterForm içinde new EmailService() kullanmak.

• bash
  Kopyala
   function RegisterForm() {
  const emailService = new EmailService(); // Sabit bağımlılık
  const handleRegister = () => {
  emailService.send("user@example.com", "Hoş geldiniz!");
  };
  return <button onClick={handleRegister}>Kayıt Ol</button>;
  }

• Loosely Coupled (Gevşek Bağlılık)
  • Component veya sınıf, ihtiyaç duyduğu işlevi bir interface veya dışarıdan verilen servis üzerinden kullanır.
  • Yeni ihtiyaçlar veya değişiklikler geldiğinde sadece dışarıdan sağlanan bağımlılığı değiştirirsin, component’in içi bozulmaz.
  • Örnek: RegisterForm’a messageService prop olarak vermek, UserService’e IMessageService constructor ile enjekte etmek.

  • bash
    Kopyala
    function RegisterForm({ messageService }) {
      const handleRegister = () => {
        messageService.send("user@example.com", "Hoş geldiniz!");
      };
      return <button onClick={handleRegister}>Kayıt Ol</button>;
    }
    // Kullanım:
    <RegisterForm messageService={new EmailService()} />
    <RegisterForm messageService={new SmsService()} />

bash
Kopyala
public class UserService{
  private readonly EmailService _emailService = new EmailService();
    public void RegisterUser(string email)
      {
          _emailService.Send(email, "Hoş geldin!");
      }
}

• UserService, mutlaka EmailService kullanmak zorunda.
• Yarın SMS veya push notification göndermek istersen, sınıfın içini değiştirmek zorundasın.
• Test yazmak zor; çünkü mock servis veremezsin.
• Yani sınıfın sorumluluğu sadece kullanıcı kaydını yapmak değil, aynı zamanda hangi servisi kullanacağına da karar vermek zorunda. Bu durum, sınıfın esnekliğini azaltır ve bakım maliyetini artırır.

Çözüm: Karar Vermeyi Sınıfın İçinden Al, Dışarı Taşı

• Backend’de yaşadığımız problem şuydu: UserService nasıl bildirim gönderileceğine kendisi karar veriyordu. Bu durum sınıfı EmailService’e sıkı sıkıya bağlı hale getiriyordu. Çözüm basit: sınıfın kendi içinde bağımlılığı yaratmak yerine, bağımlılığı dışarıdan veriyoruz.
• Interface ile Soyutlama

  bash
  Kopyala
  //Ufak bir kod örneği
  public interface IMessageService
  {
    void Send(string to, string message); //Bu interface'i kullanan her class Send işlemi yapmak zorunda.
  }

• Bu bir soyutlama. Yani IMessageService diyor ki: “Beni implement eden bir sınıf varsa, Send metodunu içermeli.” Ama interface kendisi nasıl gönderileceğini bilmez. Sadece bir sözleşme tanımlar. IMessageService interface’i sayesinde UserService’in hangi mesaj servisi kullanılacağını bilmesine gerek yok. Artık sadece “bir mesaj gönderilmesini istiyorum” diyor ne şekilde nasıl gönderildiği beni ilgilendirmez demek istiyor .
• Farklı Servisler

  bash
  Kopyala
  public class EmailService : IMessageService
  {
    public void Send(string to, string message)
    {
        Console.WriteLine($"{to} adresine mail gönderildi: {message}");
    }
  }
  public class SmsService : IMessageService
  {
    public void Send(string to, string message)
    {
        Console.WriteLine($"{to} numarasına SMS gönderildi: {message}");
    }
  }

• İkisi de IMessageService sözleşmesini uyguluyor yani daha önceden oluşturduğımuz bu interface'i implement ediyoruz ama içlerinde farklı davranış var:
  • EmailService → mail gönderiyor
  • SmsService → SMS gönderiyor
• UserService’e Enjekte Etme

  bash
  Kopyala
  public class UserService
  {
    private readonly IMessageService _messageService;
    public UserService(IMessageService messageService) // Dependency Injection burada gerçekleşiyor
    {
        _messageService = messageService;
    }
    public void RegisterUser(string email)
    {
        _messageService.Send(email, "Hoş geldin!");
    }
  }

• Burada önemli olan nokta UserService, kendisi hangi servisin kullanılacağını bilmez.
• _messageService interface türünde (IMessageService) tutuluyor. Gerçek servis örneği (EmailService veya SmsService) dışarıdan veriliyor (constructor üzerinden).
• UserService artık loosely coupled: sadece kullanıcı kaydını yapıyor, mesaj servisi seçimi dışarıya bırakılmış.
• Test veya değişiklik için sınıfın içine dokunmana gerek yok.
• Kullanım Örneği

  bash
  Kopyala
  var userService1 = new UserService(new EmailService());
  userService1.RegisterUser("deneme@mail.com");
  var userService2 = new UserService(new SmsService());
  userService2.RegisterUser("5551234567");

• Email veya SMS fark etmez, kullanım tamamen esnek.
• Testte mock bir servis enjekte ederek işlevleri kolayca test edebilirsin.
• Artık ne kazandık?
  • Sınıf artık tek bir sorumluluğa sahip: kullanıcı kaydı yapmak.
  • Mesaj gönderme detayları dışarıya taşındı → loosely coupled oldu.
  • Test ve değişiklikler çok daha kolay.

bash
Kopyala
public class UserService
{
  private readonly EmailService _emailService = new EmailService();
  public void RegisterUser(string email)
  {
      _emailService.Send(email, "Hoş geldiniz!");
  }
}

• Hatırlarsanız öncelikle IMessageService adında bir interface tanımlamıştık.
• Daha sonra bu interface'i implement eden 2 farklı sınıf oluşturduk. EmailService ve SmsService olmak üzere.
• Daha sonra UserService içinde Constructor üzerinden bağımlılığı alıyorduk değil mi ?

Özetleyecek olursak

• Interface ile Soyutlama = IoC’un Temel Mantığı
  • IMessageService oluşturduğunda aslında sınıfın bağımlılığı soyutlanıyor.
  • UserService, hangi servis kullanılacağını bilmek zorunda değil; sadece bir mesaj servisi ile çalışması gerektiğini biliyor.
  • Yani bağımlılığı kendisi yaratmak yerine dışarıdan alıyor. Bu zaten IoC’un temel prensibi.
• Constructor Injection = IoC’un Uygulama Şekli
  • Interface’i oluşturduk ama UserService’e hangi somut servisin geleceğini bir şekilde vermeliyiz.

  • bash
    Kopyala
    var userService1 = new UserService(new EmailService());
    var userService2 = new UserService(new SMSService());
    var userService3 = new UserService(new NotificationService());

  • Burada hepsi aslında kendine dışarıdan verilen servis ile çalışacak kendi içerisinde new yapılarak bir instance üretmeyecek.
    • UserService 1 EmailService ile çalışacak
    • UserService 2 SMSService ile çalışaca
    • UserService 3 NotificationServiceile çalışacak
  • Yani sınıfın içinde hiçbir zaman “hangi servisi kullanacağım” sorusu yok, sadece işi yapıyor.

• Servisleri merkezi olarak oluşturur: Uygulama başlarken “Bu servisler mevcut olacak” der ve hazırlar.
• Bağımlılıkları otomatik verir: Bir sınıf bir servise ihtiyaç duyduğunda, container bunu kendisi sağlar, sınıfın bunu kendisi oluşturmasına gerek yoktur.
• Yaşam döngüsünü yönetir: Bir servisin ne zaman oluşturulacağını ve ne zaman yok edileceğini kontrol eder. (Örneğin, her kullanımda yeni örnek mi olacak, uygulama boyunca tek örnek mi olacak gibi)

1️⃣ Servis Kayıtları (Registration)

• DI Container’ın çalışmasının ilk adımı, hangi servislerin container tarafından yönetileceğini belirlemektir. ASP.NET Core uygulamalarında bu işlem genellikle Program.cs veya Startup.cs dosyasında yapılır. Burada temel olarak üç farklı yaşam döngüsüne sahip servis kaydı yapabiliriz:

• bash
  Kopyala
  var builder = WebApplication.CreateBuilder(args);
  // Scoped: her HTTP isteğinde yeni örnek
  builder.Services.AddScoped<IMessageService, EmailService>();
  // Singleton: uygulama boyunca tek bir örnek
  builder.Services.AddSingleton<ILogger, ConsoleLogger>();
  // Transient: her kullanımda yeni örnek
  builder.Services.AddTransient<NotificationService>();

• AddScoped: Her HTTP isteğinde bir örnek oluşturur. Bu, özellikle isteğe özel kaynaklar (örneğin DbContext) için uygundur.
• AddSingleton: Uygulama başladığında bir örnek oluşturulur ve uygulama boyunca aynı örnek kullanılır. Bu, örnekler arası veri paylaşımı veya kaynak maliyetinin azaltılması gereken durumlar için idealdir.
• AddTransient: Her bağımlılık talebinde yeni bir örnek oluşturulur. Stateless veya kısa ömürlü servisler için uygundur.
• Container, bu kayıtları hafızasında tutar ve ihtiyaç duyulduğunda ilgili servisi üretir. Bu sayede, sınıfların kendi bağımlılıklarını yönetmesine gerek kalmaz.( Bu kavramları birazdan daha net ve anlaşılır şekilde derinlemesine inceleyeceğiz. )

2️⃣ Bağımlılık Çözümü (Resolution)

• DI Container’ın en önemli özelliklerinden biri, bir sınıfın ihtiyaç duyduğu bağımlılığı otomatik olarak çözebilmesidir. Örneğin:

• bash
  Kopyala
  public class UserService
  {
    private readonly IMessageService _messageService;
    public UserService(IMessageService messageService)
    {
        _messageService = messageService;
    }
    public void RegisterUser(string email)
    {
        _messageService.Send(email, "Hoş geldiniz!");
    }
  }

• Burada UserService, bir IMessageService bağımlılığına ihtiyaç duyuyor. DI Container, uygulama başında IMessageService için hangi implementasyonun (bu örnekte EmailService) kullanılacağını biliyor ve bunu otomatik olarak UserService sınıfının constructor’ına enjekte ediyor.
• Bu sayede UserService içinde hangi servisin kullanılacağına dair hiçbir karar bulunmaz. Bu, Inversion of Control (IoC) prensibinin pratik bir uygulamasıdır: kontrol, sınıfın kendisinden alınmış ve container’a verilmiştir. Sonuç olarak kod daha esnek, test edilebilir ve sürdürülebilir olur.

3️⃣ Servis Yaşam Döngüsü (Lifecycle Management)

• DI Container’ın en kritik görevlerinden biri, yalnızca hangi servisi enjekte edeceğine karar vermek değil; bu servislerin ne kadar süre bellekte tutulacağını da yönetmektir. Aynı servis, yanlış yaşam döngüsü ile tanımlandığında bellek sızıntılarına, yanlış veri paylaşımına veya istenmeyen performans kaybına yol açabilir. Bu yüzden lifecycle seçimi geliştirici için basit bir detay değil, stratejik bir mimari karardır.
• Şimdi her bir yaşam döngüsünü gündelik hayata benzeterek ve farklı senaryolarda nasıl çalıştığını göstererek açıklayalım.

• a) Singleton — "Her yerde tek, herkes onu kullansın"

  • Singleton servisler, uygulama ayakta kaldığı sürece yalnızca bir kere oluşturulan ve tekrar tekrar kullanılan servislerdir. En basit haliyle, evde tek bir modem olduğunu düşün. Evdeki herkes (telefonlar, bilgisayarlar, tabletler) o tek modem üzerinden internete bağlanır. Her bağlanan için yeni bir modem açılmaz – paylaşımlı ve merkezi bir kaynak vardır.
  • Yani , uygulama başladığında servis oluşturulur. uygulama boyunca tek bir örnek kullanılır.
  • Avantaj: Kaynak kullanımını azaltır, örnekler arası veri paylaşımı kolaydır.
  • Dezavantaj: Global state oluşabilir, dikkatli kullanılmalı.

  • bash
    Kopyala
    builder.Services.AddSingleton<ILogger, ConsoleLogger>();
    //Uygulama boyunca loglamak için sadece tek bir örnek olması yeterlidir.

  • Ne zaman kullanılır?
    • Konfigürasyon veya Setting okuma servisleri
    • Logger / Audit Servisleri
    • MemoryCache / In-Memory Data tutan servisler
    • 3rd party client’lar (Mail, Payment Gateway vs.)

  • Örnek Kullanım : Global Ayar Servisi

  • bash
    Kopyala
    public class AppSettings
    {
      public string ApplicationName { get; set; } = "MyApp";
      public DateTime StartedAt { get; } = DateTime.Now;
    }

  • bash
    Kopyala
    //`Program.cs` veya `Startup.cs` dosyasında ayarlamamızı yapalım.
    builder.Services.AddSingleton<AppSettings>();

  • bash
    Kopyala
    public class HomeController : Controller
    {
    private readonly AppSettings _settings;
    public HomeController(AppSettings settings) => _settings = settings;
    - [HttpGet("/info")]
    public IActionResult Info() => Ok(_settings);
    }

  • Başka bir Controller:

  • bash
    Kopyala
    public class AdminController : Controller
    {
    private readonly AppSettings _settings;
    public AdminController(AppSettings settings) => _settings = settings;
    - [HttpGet("/admin-info")]
    public IActionResult Info() => Ok(_settings);
    }

  • 👉 Her iki endpoint de aynı StartedAt değerini döner. Çünkü servis uygulama boyunca bir kez oluşturulmuştur.

• b) Scoped — "Her müşteri için ayrı masa"

  • Scoped servisler, her HTTP isteği başladığında oluşturulur ve o istek bitene kadar aynı örnek kullanılır. Bu davranışı bir restoranda her müşteri için ayrı masa açılması gibi düşünebilirsin. Aynı masaya gelen herkes aynı servisi (örneği) paylaşır. Ama yeni müşteri geldiğinde yeni masa açılır – eski masa kullanılmaz.
  • Yani, her HTTP isteğinde yeni bir örnek oluşturulur. Aynı istekte, aynı servis örneği kullanılır.
  • Avantaj: İstek başına izole servis sağlar, state yönetimi daha güvenlidir.
  • Kullanım: Web uygulamalarında DbContext gibi isteğe özel kaynaklar için ideal.

  • bash
    Kopyala
    builder.Services.AddScoped<IMessageService, EmailService>();
    //Her HTTP isteği için bir kere kullanılır ve daha sonra otomatik olarak garbage collector tarafından silinir.

  • HTTP isteği tamamlandığında, container scoped örneği temizler. Yani bellekte artık bu servis örneği tutulmaz, garbage collector tarafından bellek serbest bırakılır. Böylece istek bazlı izolasyon sağlanır ve servisler birbirine karışmaz.
  • Ne zaman kullanılır?
    • DbContext (Entity Framework gibi ORM’lerde neredeyse her zaman scoped olur)
    • Kullanıcıya özel hesaplama veya sepet servisi
    • Request içerisindeki izleme (Trace / Correlation ID) servisleri

  • Örnek Kullanım – İstek Bazlı Request ID

  • bash
    Kopyala
    //Ufak bir kod örneği
    public class RequestContext
    {
      public Guid RequestId { get; } = Guid.NewGuid();
    }

  • bash
    Kopyala
    //`Program.cs` veya `Startup.cs` dosyasında ayarlamamızı yapalım.
    builder.Services.AddScoped<RequestContext>();

  • bash
    Kopyala
    public class OrderController : Controller
    {
    private readonly RequestContext _context1;
    private readonly RequestContext _context2;
    - public OrderController(RequestContext c1, RequestContext c2)
    {
        _context1 = c1;
        _context2 = c2;
    }
    - [HttpGet("/order")]
    public IActionResult Test() => Ok(new { _context1.RequestId, _context2.RequestId });
    }

  • 👉 Aynı endpoint’e bir istek attığında iki RequestId de aynı çıkar.
  • 👉 Farklı bir istek attığında yeni bir RequestId gelir.

• c) Transient — "Her kullanımda yepyeni bir şey"

  • Transient servisler tamamen stateless olmalıdır. Çünkü her kullanıldığında yeni örnek oluşturulur, hiçbir paylaşım yapılmaz. Bu davranış plastik çatala benzer: kullandın → attın → yenisini aldın.
  • Her bağımlılık talebinde yeni bir örnek oluşturulur. Yani bir sınıf veya controller, bir transient servisi her kullandığında, DI Container yeni bir instance (örnek) üretir. Hiçbir şekilde daha önce oluşturulmuş örnek paylaşılmaz.
  • Avantaj: Stateless servisler için uygundur, tam izolasyon sağlar.
  • Dezavantaj: Çok sık kullanılırsa performans maliyeti olabilir.

  • bash
    Kopyala
    //`Program.cs` veya `Startup.cs` dosyasında ayarlamamızı yapalım.
    builder.Services.AddTransient<NotificationService>();

  • Ne zaman kullanılır?
    • Basit yardımcı servisler (StringFormatter, EmailBuilder, CalculationService vb.)
    • Her çağrıda farklı olması gereken servisler

  • Örnek Kullanım – Hesaplama Servisi

  • bash
    Kopyala
    //Ufak bir kod örneği
    public class PriceCalculator
    {
      public Guid InstanceId { get; } = Guid.NewGuid();
    }

  • bash
    Kopyala
    //`Program.cs` veya `Startup.cs` dosyasında ayarlamamızı yapalım.
    builder.Services.AddTransient<PriceCalculator>();

  • bash
    Kopyala
    public class CartController : Controller
    {
    private readonly PriceCalculator _p1;
    private readonly PriceCalculator _p2;
    - public CartController(PriceCalculator p1, PriceCalculator p2)
    {
        _p1 = p1;
        _p2 = p2;
    }
    - [HttpGet("/cart")]
    public IActionResult Test() => Ok(new { _p1.InstanceId, _p2.InstanceId });
    }

  • 👉 Aynı istekte bile p1 ve p2 farklıdır.

Özet: DI Container Avantajları