ASP.NET Core DI: Kapsamlar, Ömürler ve .NET 9 Kaynak Üreteçleri

ASP.NET Core’da Bağımlılık Enjeksiyonu (DI), modern uygulama geliştirmede kritik bir role sahiptir. Kapsamlar, hizmet ömürleri ve .NET 9’un yenilikçi kaynak üreteçleriyle uygulamanızı daha performanslı ve yönetilebilir kılın.

Günümüz yazılım dünyasında, uygulamaların karmaşıklığı her geçen gün artmaktadır. Bu karmaşıklık, bakım zorlukları, test edilebilirlik sorunları ve esneklik eksikliği gibi pek çok problemi beraberinde getirir. Peki, bu sorunların üstesinden gelmek ve daha sürdürülebilir, ölçeklenebilir uygulamalar geliştirmek mümkün müdür? İşte bu noktada Bağımlılık Enjeksiyonu (Dependency Injection – DI) devreye girer. ASP.NET Core, güçlü ve yerleşik bir DI mekanizması sunarak geliştiricilerin bu zorlukların üstesinden gelmesine yardımcı olur. Bu makalede, ASP.NET Core’daki Bağımlılık Enjeksiyonu’nun temellerinden başlayarak, hizmet ömürlerinin (lifetimes) derinliklerine inecek ve .NET 9 ile hayatımıza giren kaynak üreteçlerinin (source generators) DI performansına nasıl devrim niteliğinde katkılar sağladığını keşfedeceğiz. Gelin, bu yolculuğa birlikte çıkalım ve kodunuzu daha iyi hale getirmenin yollarını öğrenelim.

Bağımlılık Enjeksiyonu (DI), bir yazılım tasarım deseni olup, Bileşenler Arası Bağımlılıkların Dışarıdan Sağlanması prensibine dayanır. Bu prensip, bir nesnenin ihtiyaç duyduğu diğer nesneleri (bağımlılıklarını) kendi yaratmak yerine, dışarıdan kendisine enjekte edilmesini (sağlanmasını) savunur. Kulağa karmaşık gelse de, aslında kodunuzu çok daha esnek ve yönetilebilir hale getiren temel bir kavramdır. ASP.NET Core, “Inversion of Control” (Kontrolün Tersine Çevrilmesi – IoC) prensibini uygulayan bir IoC konteyneri ile birlikte gelir. Bu konteyner, uygulamadaki servislerin yaşam döngülerini ve bağımlılıklarını yönetmekten sorumludur.

Peki, DI neden bu kadar önemlidir? En başta gelen faydası, test edilebilirliği artırmasıdır. Bir sınıfın bağımlılıkları dışarıdan sağlandığında, birim testleri (unit tests) sırasında bu bağımlılıkların kolayca sahte (mock) veya taklit (stub) nesnelerle değiştirilebilmesini sağlarız. Bu durum, yalnızca test ettiğimiz sınıfın davranışına odaklanmamıza olanak tanır ve entegrasyon bağımlılıklarından kaynaklanan karmaşıklığı ortadan kaldırır. Bununla birlikte, DI gevşek bağlılığı (loose coupling) teşvik eder. Bir sınıf, bağımlılıklarını somut tipler yerine arayüzler (interfaces) üzerinden talep ettiğinde, bu bağımlılıkların altındaki somut implementasyonları değiştirmek çok daha kolay hale gelir. Bu da kod tekrarını azaltır, kodunuzu daha modüler yapar ve ilerideki değişikliklere karşı daha dirençli olmasını sağlar.

ASP.NET Core’daki yerleşik DI mekanizması, uygulamanızın başlangıç noktası olan Program.cs dosyasında IServiceCollection arayüzü aracılığıyla servislerinizi kaydetmenize olanak tanır. Uygulama başlatıldığında, bu koleksiyon IServiceProvider‘a dönüştürülür ve uygulama genelinde bağımlılıkları çözümlemek için kullanılır. Servislerinizi kaydederken, genellikle üç ana enjeksiyon yönteminden birini kullanırız: constructor injection, property injection ve method injection. Constructor injection, bağımlılıkların bir sınıfın yapıcı metoduna (constructor) parametre olarak geçirilmesiyle sağlanır ve bağımlılıkların açıkça belirtilmesi ve sınıfın geçerli bir durumda olabilmesi için gerekli olması nedeniyle en çok tercih edilen yöntemdir. Property injection ve method injection da belirli senaryolarda kullanılabilir, ancak constructor injection genellikle daha temiz ve net bir bağımlılık grafiği sağlar.

// Program.cs
public class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        // Bağımlılık Enjeksiyonu (DI) servisi kaydı
        builder.Services.AddScoped();
        builder.Services.AddTransient();

        builder.Services.AddControllers();

        var app = builder.Build();

        app.UseAuthorization();
        app.MapControllers();

        app.Run();
    }
}

// Servis Arayüzü
public interface IMyService
{
    string GetData();
}

// Servis Implementasyonu
public class MyService : IMyService
{
    private readonly IOtherService _otherService;

    public MyService(IOtherService otherService) // Constructor Injection
    {
        _otherService = otherService;
    }

    public string GetData()
    {
        return $"MyService'den veri ve {_otherService.GetInfo()}";
    }
}

// Diğer Servis Arayüzü
public interface IOtherService
{
    string GetInfo();
}

// Diğer Servis Implementasyonu
public class OtherService : IOtherService
{
    public string GetInfo()
    {
        return "OtherService'den bilgi";
    }
}

Yukarıdaki örnekte görebileceğiniz gibi, MyService, IOtherService bağımlılığını constructor aracılığıyla alır. Bu, hem MyService'in neye ihtiyaç duyduğunu açıkça belirtir hem de IOtherService'in farklı implementasyonlarını kolayca enjekte etmemize olanak tanır. Sonuç olarak, Bağımlılık Enjeksiyonu, modern yazılım geliştirmede vazgeçilmez bir araç olup, daha esnek, test edilebilir ve sürdürülebilir uygulamalar oluşturmanın temelini oluşturur. Bu konsepti anlamak, ASP.NET Core ekosisteminde etkin bir şekilde çalışabilmek için kritik öneme sahiptir.

Hizmet Ömürleri (Lifetimes): Singleton, Scoped ve Transient Arasındaki Farklar Nelerdir?

ASP.NET Core Bağımlılık Enjeksiyonu sisteminin kalbinde, bir servisin ne kadar süreyle canlı kalacağını ve ne zaman yeni bir örneğinin oluşturulacağını belirleyen "hizmet ömürleri" (lifetimes) kavramı yatar. Bu ömürler, uygulamanızın kaynak yönetimini, performansını ve doğru çalışma biçimini doğrudan etkiler. Üç temel hizmet ömrü tipi vardır: Singleton, Scoped ve Transient. Her birinin kendine özgü kullanım durumları, avantajları ve dikkat edilmesi gereken noktaları bulunmaktadır. Bu üç tipi doğru bir şekilde anlamak ve uygulamak, hatasız ve verimli bir ASP.NET Core uygulaması geliştirmek için hayati öneme sahiptir. Şimdi, bu ömürleri daha yakından inceleyelim.

Singleton Hizmet Ömrü: Uygulama Boyunca Tek Bir Örnek

Singleton hizmet ömrü, uygulamanın başlatılmasından kapanmasına kadar yalnızca tek bir servis örneğinin oluşturulmasını sağlar. Bu, uygulamanızda ne kadar çağrı yapılırsa yapılsın veya kaç farklı bileşenin bu servisi talep etmesinden bağımsız olarak, her zaman aynı örneğin döndürüleceği anlamına gelir. Bu tür servisler genellikle uygulama genelinde paylaşılan, durumsuz (stateless) veya değişmeyen yapılandırma verileri, loglama mekanizmaları veya cache servisleri gibi durumlar için idealdir. Örneğin, bir veritabanı bağlantı havuzunu veya bir yapılandırma yöneticisini Singleton olarak kaydetmek mantıklı olabilir, çünkü bu kaynakların her istek için yeniden oluşturulması gereksiz bir performans yükü yaratır.

Ancak, Singleton servisleri kullanırken dikkatli olmak gerekir. Thread-safety (iş parçacığı güvenliği) büyük bir endişe kaynağıdır. Eğer bir Singleton servisi durum (state) tutuyorsa ve bu durum birden fazla iş parçacığı tarafından aynı anda erişilip değiştirilebiliyorsa, yarış koşulları (race conditions) veya diğer eş zamanlılık sorunları ortaya çıkabilir. Bu nedenle, Singleton servislerin durumsuz olması veya içerdiği durumu iş parçacığı güvenli bir şekilde yönetmesi şiddetle tavsiye edilir. Performans açısından, ilk talep edildiğinde bir kez oluşturulduğu ve sonraki tüm taleplerde mevcut örneği kullandığı için oldukça verimlidirler.

// Program.cs
builder.Services.AddSingleton();

// Singleton Servis Implementasyonu
public class SingletonService : ISingletonService
{
    private readonly Guid _instanceId;

    public SingletonService()
    {
        _instanceId = Guid.NewGuid();
        Console.WriteLine($"SingletonService oluşturuldu: {_instanceId}");
    }

    public Guid GetInstanceId()
    {
        return _instanceId;
    }
}

Yukarıdaki örnekte, SingletonService yalnızca bir kez oluşturulacak ve tüm uygulama boyunca aynı _instanceId değerini döndürecektir.

Scoped Hizmet Ömrü: İstek Başına Tek Bir Örnek

Scoped hizmet ömrü, ASP.NET Core uygulamalarında belki de en sık kullanılan ömür tipidir. Bu ömür tipine sahip bir servis, her yeni "kapsam" (scope) için bir kez oluşturulur. ASP.NET Core uygulamalarında, tipik olarak her HTTP isteği, kendi özel kapsamını (scope) oluşturur. Bu, bir HTTP isteği içinde talep edilen tüm Scoped servis örneklerinin, o istek boyunca aynı örneği paylaşacağı anlamına gelir. Ancak, farklı HTTP istekleri, aynı Scoped servis için farklı örnekler alacaktır. Bu davranış, veritabanı bağlamları (DbContext), kullanıcıya özgü oturum verileri veya belirli bir istek için geçerli olacak diğer durum bilgileri gibi kaynaklar için mükemmel bir uyum sağlar.

Örneğin, Entity Framework Core'un DbContext'i genellikle Scoped olarak kaydedilir. Bu, bir web isteği süresince aynı DbContext örneğinin kullanılmasını sağlar, böylece veritabanı işlemleri atomik kalır ve aynı istekte farklı noktalarda aynı veriye erişim tutarlı olur. İstek tamamlandığında, DbContext örneği ve onunla ilişkili tüm kaynaklar uygun şekilde serbest bırakılır. Bu model, bellek sızıntılarını önlemeye ve kaynak yönetimini optimize etmeye yardımcı olur. Scoped servisler, Singleton servislerin potansiyel thread-safety sorunlarını çözmek için iyi bir alternatif olabilir, zira her isteğin kendi izole servis örneği bulunur.

// Program.cs
builder.Services.AddScoped();

// Scoped Servis Implementasyonu
public class ScopedService : IScopedService
{
    private readonly Guid _instanceId;

    public ScopedService()
    {
        _instanceId = Guid.NewGuid();
        Console.WriteLine($"ScopedService oluşturuldu: {_instanceId}");
    }

    public Guid GetInstanceId()
    {
        return _instanceId;
    }
}

Her HTTP isteğinde ScopedService'in yeni bir örneği oluşturulacak ve o istek boyunca aynı _instanceId değerini döndürecektir.

Transient Hizmet Ömrü: Her İstendiğinde Yeni Bir Örnek

Transient hizmet ömrü, adından da anlaşılacağı gibi, en kısa ömürlü servis tipidir. Bu ömür tipine sahip bir servis, her talep edildiğinde, yani IServiceProvider'dan her istendiğinde veya bağımlılık olarak her enjekte edildiğinde yeni bir örnek oluşturulur. Bu, aynı HTTP isteği içinde bile, eğer bir Transient servisi birden fazla kez talep edilirse, her seferinde farklı bir örnek alacağınız anlamına gelir. Transient servisler, hafif, durumsuz ve pahalı olmayan nesneler için idealdir. Örneğin, her kullanımda farklı parametrelerle başlatılması gerekebilecek bir yardımcı (utility) sınıf veya belirli bir işlem için kısa süreliğine ihtiyaç duyulan bir hesaplama servisi Transient olabilir.

Transient ömrün temel avantajı, kaynakları anında serbest bırakabilmesi ve bağımlılıkların tamamen izole olmasıdır. Ancak, dikkatli kullanılmazsa, gereksiz nesne oluşturma nedeniyle performans üzerinde olumsuz bir etkisi olabilir. Özellikle karmaşık bağımlılık grafiklerine sahip ve sık sık talep edilen servisler için her zaman yeni bir örnek oluşturmak, çöp toplama (garbage collection) yükünü artırabilir. Bu nedenle, Transient servisleri genellikle çok basit, durumsuz ve "tek seferlik" kullanım senaryolarında tercih etmek en iyisidir. Karmaşık veya kaynak yoğun servisler için Scoped veya Singleton ömürleri daha uygun olabilir.

// Program.cs
builder.Services.AddTransient();

// Transient Servis Implementasyonu
public class TransientService : ITransientService
{
    private readonly Guid _instanceId;

    public TransientService()
    {
        _instanceId = Guid.NewGuid();
        Console.WriteLine($"TransientService oluşturuldu: {_instanceId}");
    }

    public Guid GetInstanceId()
    {
        return _instanceId;
    }
}

Yukarıdaki kodda, ITransientService her talep edildiğinde, farklı bir _instanceId değerine sahip yepyeni bir TransientService örneği oluşturulacaktır. Hizmet ömürlerinin bu farklılıklarını anlamak ve doğru senaryolarda doğru ömür tipini seçmek, uygulamanızın performansını, kararlılığını ve kaynak tüketimini önemli ölçüde optimize edecektir.

Gerçek Dünya Senaryolarında Hizmet Ömürlerini Nasıl Yönetiriz?

Teorik bilgiler önemlidir, ancak hizmet ömürlerinin gerçek dünya uygulamalarında nasıl kullanıldığını anlamak, bu kavramları pekiştirmek için kritik öneme sahiptir. Karmaşık bir web uygulamasında, servislerin doğru ömür tipleriyle yapılandırılması, performanstan kararlılığa kadar pek çok alanda belirleyici bir rol oynar. Şimdi iki farklı vaka analizi üzerinden, Singleton, Scoped ve Transient ömürlerinin pratik uygulamalarını ve neden belirli durumlarda birini diğerine tercih ettiğimizi inceleyelim. Bu örnekler, okuyucunun konuya hakimiyetini artırırken, potansiyel sorunlara karşı da bir farkındalık oluşturacaktır.

Vaka Analizi 1: Bir E-ticaret Uygulamasında Sepet Yönetimi ve Veritabanı İşlemleri

Bir e-ticaret uygulamasında, kullanıcıların ürünleri sepete eklemesi, ödeme yapması ve siparişlerini yönetmesi gibi temel işlevler bulunur. Bu işlevler genellikle veritabanı işlemleri, oturum yönetimi ve farklı servisler arasında koordinasyon gerektirir. Burada servis ömürleri kritik bir hal alır.

1. Veritabanı Bağlamı (DbContext): EF Core'da DbContext, veritabanı işlemlerinin birimini temsil eder ve genellikle bir HTTP isteği boyunca aynı kalması istenir. Bu, bir isteğin farklı aşamalarında (örneğin, ürün ekleme, sepet güncelleme) aynı DbContext örneğinin kullanılarak tutarlı bir veri durumu sağlanması anlamına gelir. Bu nedenle, DbContext genellikle Scoped olarak kaydedilir. İstek bittiğinde, DbContext serbest bırakılır ve bir sonraki istek için yeni bir örnek oluşturulur. Bu, her isteğin kendi izole veritabanı işlemlerini yapmasını ve bellek sızıntılarını önlemesini sağlar.
2. Sepet Yönetimi Servisi (ICartService): Kullanıcının alışveriş sepetini yöneten servis de genellikle Scoped olmalıdır. Çünkü bir kullanıcının sepeti, o kullanıcının mevcut HTTP isteğiyle ilişkilidir. Aynı istek içinde sepetten ürün ekleme, çıkarma veya miktar değiştirme gibi işlemler yapıldığında, bu işlemlerin aynı sepet örneği üzerinde gerçekleşmesi gerekir. Başka bir kullanıcının sepeti ise tamamen farklı bir örnek olacaktır.
3. Kullanıcı Kimlik Doğrulama Servisi (IUserService): Mevcut kullanıcının kimliğini doğrulayan veya kullanıcı bilgilerini getiren bir servis de genellikle Scoped olmalıdır. Bu, her istek için geçerli olan kullanıcı kimliğini veya yetkisini o isteğin yaşam döngüsü boyunca tutarlı bir şekilde sağlamak içindir.
4. Loglama Servisi (ILogger): Uygulama genelinde olayları kaydetmek için kullanılan bir loglama servisi (örneğin, Microsoft.Extensions.Logging) genellikle Singleton olarak kaydedilir. Çünkü loglama servisinin durum tutmasına gerek yoktur ve her istek için yeni bir örnek oluşturulması gereksiz kaynak tüketimine neden olur. Tüm uygulama boyunca tek bir örnek, loglama performansını optimize eder.
5. Ödeme Sağlayıcı Entegrasyonu (IPaymentGatewayService): Belki de bir ödeme ağ geçidi ile iletişim kuran bir servis, duruma göre Scoped veya Transient olabilir. Eğer servis, her ödeme işlemi için hafif bir nesne olarak tasarlanmış ve durum tutmuyorsa, Transient olabilir. Ancak, belirli bir işlem sırasında oturum veya işlem kimliği gibi durumları yönetiyorsa Scoped olması daha uygun olabilir.

// Program.cs - Servis Kayıtları
builder.Services.AddDbContext(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddScoped();
builder.Services.AddScoped();
builder.Services.AddSingleton>(LoggerFactory.Create(builder => builder.AddConsole()).CreateLogger());
builder.Services.AddTransient(); // Ödeme işlemi başına yeni bir örnek

// Örnek Bir Controller Yapısı
public class CartController : ControllerBase
{
    private readonly ICartService _cartService;
    private readonly ILogger _logger;
    private readonly ApplicationDbContext _dbContext;

    public CartController(ICartService cartService, ILogger logger, ApplicationDbContext dbContext)
    {
        _cartService = cartService;
        _logger = logger;
        _dbContext = dbContext;
    }

    [HttpPost("add-item")]
    public async Task AddItemToCart([FromBody] AddItemDto item)
    {
        _logger.LogInformation($"Sepete ürün ekleniyor: {item.ProductId}");
        await _cartService.AddItem(item.ProductId, item.Quantity);
        await _dbContext.SaveChangesAsync(); // Aynı isteğin DbContext'i üzerinden kaydediliyor
        return Ok();
    }
}

Bu senaryoda, CartController içindeki _cartService ve _dbContext aynı HTTP isteği boyunca aynı örneklerdir. _logger ise tüm uygulama boyunca tek bir örnektir.

Vaka Analizi 2: Bir API Gateway'de Kimlik Doğrulama ve Token Yönetimi

Bir API Gateway, birden fazla mikroservisi yönetirken kimlik doğrulama, yetkilendirme ve token yönetimi gibi görevleri üstlenebilir. Bu katmanda, hizmet ömürlerinin doğru seçimi hem güvenlik hem de performans açısından kritik öneme sahiptir.

1. Token Validasyon Servisi (ITokenValidator): Bir gelen JWT (JSON Web Token) tokenini doğrulayan servis, genellikle durum tutmaz ve sadece algoritmik bir doğrulama işlemi yapar. Bu durumda, her istek için yeni bir örneğe ihtiyaç duyulmaz ve Singleton olarak kaydedilmesi performansı artırır. Eğer servisin bazı yapılandırmaları varsa (örneğin, Secret Key), bunlar başlatma sırasında yüklenir ve uygulama ömrü boyunca kullanılır.
2. Kullanıcı Yetkilendirme Servisi (IAuthorizationService): Kullanıcının belirli bir kaynağa erişim yetkisinin olup olmadığını kontrol eden servis, genellikle o anki HTTP isteği bağlamında kullanıcı rollerini veya izinlerini değerlendirir. Bu nedenle, Scoped olarak kaydedilmesi daha uygundur. Böylece, her istek için kullanıcıya özgü yetkilendirme kararları alınabilir.
3. Token Yenileme Servisi (ITokenRefresher): Eğer API Gateway, süresi dolmuş access token'ları refresh token kullanarak yenileme yeteneğine sahipse, bu servis genellikle kullanıcıya özgü bir işlem yapacağı ve bir kez kullanılacağı için Transient olarak kaydedilebilir. Her yenileme işlemi, bağımsız bir işlem olarak kabul edilebilir.
4. Hız Limitleme (Rate Limiting) Servisi (IRateLimitingService): Kullanıcı veya IP bazında istek hızını sınırlayan bir servis, genellikle tüm uygulama genelinde paylaşılan bir state (örneğin, bir distributed cache) üzerinde çalışır. Bu durumda, servisin kendisi Singleton olabilir, ancak kullandığı cache erişim veya istatistik güncelleme metotları iş parçacığı güvenli olmalıdır.

Bu vaka analizleri, farklı servislerin doğasına ve gereksinimlerine göre hizmet ömürlerinin nasıl akıllıca seçilmesi gerektiğini göstermektedir. Doğru hizmet ömrü seçimi, hem uygulamanın verimli çalışmasını sağlar hem de geliştirme sırasında karşılaşılabilecek birçok hatanın önüne geçer.

.NET 9 Kaynak Üreteçleri (Source Generators) ile DI Performansını Artırma: Yenilikler ve Uygulama

ASP.NET Core'un Bağımlılık Enjeksiyonu mekanizması yıllardır oldukça verimli çalışsa da, performansın her zaman artırılabileceği noktalar bulunur. Özellikle büyük uygulamalarda veya yüksek performans gerektiren senaryolarda, DI konteynerinin çalışma zamanında (runtime) yansıma (reflection) kullanarak servisleri çözümlemesi küçük bir ek yük getirebilir. İşte bu noktada .NET 9 ile birlikte Bağımlılık Enjeksiyonu için sunulan kaynak üreteçleri (source generators) devreye giriyor ve performansta önemli iyileştirmeler vadediyor.

Kaynak üreteçleri, .NET 5 ile hayatımıza giren ve derleme zamanında (compile-time) kod üretebilen güçlü araçlardır. Geleneksel olarak, DI konteynerleri servislerinizi kaydettiğinizde ve daha sonra bunları talep ettiğinizde, bağımlılık grafiğini oluşturmak için tipik olarak yansımayı kullanır. Yansıma, çalışma zamanında bir tipin meta verilerini incelemek ve dinamik olarak nesneler oluşturmak için kullanılır. Bu esneklik sağlarken, aynı zamanda bir miktar performans maliyeti de getirir. Kaynak üreteçleri, bu yansıma tabanlı çözümleme sürecini derleme zamanına taşıyarak bu maliyeti ortadan kaldırır.

.NET 9'daki yeni DI kaynak üreteçleri, servislerinizi kaydederken ve bağımlılıklarını belirtirken özel öznitelikler (attributes) kullanmanıza olanak tanır. Bu öznitelikler sayesinde, derleme sırasında konteyner, servis çözümleme mantığını doğrudan sizin için C# kodu olarak üretir. Bu üretilen kod, çalışma zamanında yansıma kullanmak yerine doğrudan metod çağrıları yapar. Sonuç olarak, servis çözümleme süreçleri çok daha hızlı hale gelir, bellek tahsisi (memory allocation) azalır ve genel uygulama performansı artar.

Peki, bu yeniliği uygulamalarımıza nasıl entegre edebiliriz? .NET 9 ile birlikte, aşağıdaki gibi öznitelikler kullanabilirsiniz:

// MyService.cs
using Microsoft.Extensions.DependencyInjection; // Veya daha spesifik bir namespace

[ServiceInjection(ServiceLifetime.Scoped)]
public class MyService : IMyService
{
    private readonly ILogger _logger;

    // Bağımlılığın da öznitelik ile belirtilmesi (örneğin, [Inject])
    // .NET 9'da bu syntax değişiklik gösterebilir veya varsayılan olarak desteklenebilir
    public MyService(ILogger logger)
    {
        _logger = logger;
    }

    public void DoWork()
    {
        _logger.LogInformation("MyService çalışıyor!");
    }
}

// Program.cs
// Artık elle AddScoped() çağırmaya gerek kalmaz
// Kaynak üreteci bunu sizin için yapar.
public static class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        // Kaynak üreteçleri sayesinde bu satırlara gerek kalmayabilir
        // veya daha az kod ile servislerinizi kaydedebilirsiniz.
        //builder.Services.AddScoped();

        builder.Services.AddControllers();

        var app = builder.Build();

        app.UseAuthorization();
        app.MapControllers();

        app.Run();
    }
}

Yukarıdaki hayali örnekte, [ServiceInjection(ServiceLifetime.Scoped)] özniteliği, MyService sınıfının IMyService arayüzü için Scoped ömürlü bir servis olarak kaydedilmesi gerektiğini kaynak üreteciye bildirir. Derleme zamanında, kaynak üreteci otomatik olarak AddScoped() çağrısını yapan bir kod bloğu oluşturur ve bunu uygulamanızın DI konfigürasyonuna ekler. Bu, servis kaydı için manuel kod yazma ihtiyacını azaltır ve aynı zamanda yansıma kullanımını ortadan kaldırır.

Bu yaklaşımın temel avantajları şunlardır:

• Performans Artışı: Çalışma zamanında yansıma maliyetinin ortadan kalkmasıyla servis çözümleme performansı önemli ölçüde artar. Özellikle çok sayıda servise sahip büyük uygulamalar için bu fark hissedilir olabilir.
• Daha Az Bellek Tahsisi: Yansıma, genellikle ek bellek tahsisine neden olur. Kaynak üreteçleri ile doğrudan kod üretimi, bu tahsisleri azaltarak çöp toplama (garbage collection) yükünü hafifletir.
• Geliştirici Deneyimi: Belki de en önemlisi, servislerinizi doğrudan sınıflarınızda özniteliklerle işaretleyerek kaydetme yeteneği, kodun daha okunabilir ve yönetilebilir olmasını sağlar. Servis kaydı ve implementasyonu arasındaki ilişki daha şeffaf hale gelir.
• Derleme Zamanı Doğrulaması: Kaynak üreteçleri, olası yapılandırma hatalarını (örneğin, döngüsel bağımlılıklar) derleme zamanında tespit etmeye yardımcı olabilir, böylece bu tür sorunlar çalışma zamanında değil, geliştirme aşamasında yakalanır.

Kaynak üreteçlerinin DI ile entegrasyonu, ASP.NET Core'da performans ve geliştirici verimliliği açısından önemli bir adım atmamızı sağlıyor. Özellikle büyük ölçekli ve performans kritik uygulamalarda, bu yeni yetenekler Bağımlılık Enjeksiyonu kullanımını daha da çekici hale getirecektir.

Bağımlılık Enjeksiyonu İçin En İyi Uygulamalar ve İpuçları

Bağımlılık Enjeksiyonu, modern yazılım geliştirmede güçlü bir araç olsa da, etkili bir şekilde kullanılmadığında sorunlara yol açabilir. Bu bölümde, ASP.NET Core uygulamalarınızda DI'ı en iyi şekilde kullanmanıza yardımcı olacak bazı önemli en iyi uygulamaları ve ipuçlarını ele alacağız. Bu uygulamalar, kodunuzun daha temiz, daha test edilebilir ve daha bakımı kolay olmasını sağlayacaktır.

1. Constructor Injection'ı Tercih Edin: Bağımlılık enjeksiyonunun en yaygın ve genellikle en iyi yolu, yapıcı metot (constructor) enjeksiyonudur. Bir sınıfın ihtiyaç duyduğu tüm bağımlılıkları yapıcı metodu aracılığıyla talep etmesi, sınıfın hangi servislere ihtiyaç duyduğunu açıkça belirtir ve bu bağımlılıklar olmadan geçerli bir durumda oluşturulamayacağını garanti eder. Bu yaklaşım, eksik bağımlılıkları derleme zamanında veya uygulama başlangıcında ortaya çıkararak runtime hatalarını önlemeye yardımcı olur. Yansıma (reflection) tabanlı property injection veya method injection'dan kaçının, çünkü bu yöntemler bağımlılık grafiğini gizleyebilir ve test edilebilirliği zorlaştırabilir.
2. Arayüzlere Bağımlı Olun (Depend on Abstractions): Somut implementasyonlar yerine arayüzlere (interfaces) bağımlı olun. Örneğin, MyService doğrudan ConcreteDependency yerine IDependency'ye bağlı olmalıdır. Bu, gevşek bağlılığı artırır, uygulamanızın daha esnek olmasını sağlar ve gelecekteki değişikliklere daha kolay uyum sağlamasına olanak tanır. Bir bağımlılığın implementasyonunu değiştirdiğinizde, arayüzü kullanan diğer sınıfların kodunu değiştirmeniz gerekmez.
3. Servis Lokasyonunu (Service Locator) Kullanmaktan Kaçının: IServiceProvider'ı doğrudan bir sınıf içinde bağımlılıkları çözümlemek için kullanmak (genellikle "Service Locator" anti-pattern'ı olarak bilinir) genellikle kötü bir uygulamadır. Bu, sınıfın bağımlılıklarını gizler, test edilmesini zorlaştırır ve sınıfın farklı bileşenlerin yaşam döngüleri hakkında bilgi sahibi olmasına neden olur. Bağımlılıklarınızı her zaman constructor injection aracılığıyla talep edin.
4. Kapsam Uyumsuzluklarına Dikkat Edin (Captive Dependencies): Uzun ömürlü bir servisin (örneğin, Singleton) daha kısa ömürlü bir servisi (örneğin, Scoped veya Transient) bağımlılık olarak alması "Captive Dependency" (tutucu bağımlılık) sorununa yol açar. Bu durumda, kısa ömürlü servis, uzun ömürlü servis tarafından hapsedilir ve ömrü boyunca serbest bırakılmaz. Bu durum bellek sızıntılarına, yanlış durumlara veya kaynakların gereksiz yere meşgul edilmesine neden olabilir. ASP.NET Core genellikle bu tür sorunları derleme zamanında veya başlangıçta tespit etmeye çalışır ancak her zaman mümkün olmayabilir. En basit kural: asla daha kısa ömürlü bir servisi daha uzun ömürlü bir servise enjekte etmeyin.
5. Döngüsel Bağımlılıklardan Kaçının (Circular Dependencies): Eğer ServiceA, ServiceB'ye ve ServiceB de ServiceA'ya bağımlıysa, bu bir döngüsel bağımlılık yaratır. Bu tür durumlar DI konteynerinin bağımlılıkları çözümlemesini engeller ve genellikle bir tasarım kokusudur. Döngüsel bağımlılıklar, genellikle iş mantığınızı daha küçük, daha odaklı servislere bölerek çözülebilir. Eğer gerçekten iki servis birbirine ihtiyaç duyuyorsa, bu bağımlılıklardan birini bir arayüz arkasına gizlemeyi veya bir olay/mesaj tabanlı iletişime geçmeyi düşünebilirsiniz.
6. Küçük ve Odaklı Servisler Oluşturun (Single Responsibility Principle): Servislerinizi Tek Sorumluluk Prensibi'ne (SRP) uygun olarak tasarlayın. Bir servis, tek bir sorumluluğa sahip olmalı ve bu sorumluluğu yerine getirmek için gerekli olan minimum bağımlılığa sahip olmalıdır. Büyük, "tanrı nesnesi" (God object) servislerinden kaçının. Bu, her bir servisin test edilebilirliğini, bakımını ve anlaşılmasını kolaylaştırır.
7. Gereksiz Servis Bağımlılıklarından Kaçının: Bir servisin, yalnızca metotlarından biri tarafından kullanılan bir bağımlılığı varsa, bu bağımlılığı tüm servise enjekte etmek yerine, ilgili metot içine enjekte etmeyi (method injection) veya bağımlılığı bir fabrika (factory) üzerinden çözümlemeyi düşünebilirsiniz. Ancak bu durumlar daha nadirdir ve genellikle constructor injection tercih edilmelidir.

Bu en iyi uygulamaları takip etmek, Bağımlılık Enjeksiyonu'nun tüm avantajlarından yararlanmanızı ve uygulamanızın uzun vadede sağlıklı kalmasını sağlayacaktır. DI, sadece bir araç değil, aynı zamanda daha iyi yazılım tasarımı ve mimarisi için bir rehberdir.

Sonuç

ASP.NET Core Bağımlılık Enjeksiyonu, modern ve sürdürülebilir uygulamalar geliştirmenin temel taşıdır. Bu makale boyunca, DI'ın ne olduğundan, uygulamanız için neden kritik bir rol oynadığına kadar birçok önemli konuyu ele aldık. Singleton, Scoped ve Transient gibi hizmet ömürlerinin her birinin kendine özgü kullanım senaryolarını, avantajlarını ve potansiyel tuzaklarını detaylı bir şekilde inceledik. Gerçek dünya senaryolarında bu ömürlerin nasıl akıllıca yönetilebileceğini örneklerle göstererek, teorik bilgileri pratik uygulamalarla birleştirdik. Ayrıca, .NET 9 ile birlikte hayatımıza giren kaynak üreteçlerinin, DI performansını nasıl artırdığını ve yansıma tabanlı çözümlemenin getirdiği ek yükü nasıl ortadan kaldırdığını gördük. Son olarak, constructor injection'ı tercih etmek, arayüzlere bağımlı olmak ve döngüsel bağımlılıklardan kaçınmak gibi en iyi uygulamaları paylaşarak, kodunuzun kalitesini ve sürdürülebilirliğini artırmanın yollarını gösterdik.

Bağımlılık Enjeksiyonu, yalnızca bir yazılım deseni olmanın ötesinde, gevşek bağlılık, test edilebilirlik ve modülerlik gibi prensipleri uygulamanıza entegre etmenin güçlü bir yoludur. .NET ekosistemi, kaynak üreteçleri gibi yeniliklerle bu alanı sürekli olarak geliştirmeye devam ediyor, bu da geliştiricilerin daha hızlı, daha güvenilir ve daha bakımı kolay uygulamalar oluşturmasına olanak tanıyor. Bu bilgiler ışığında, ASP.NET Core projelerinizde DI'ı daha bilinçli ve etkin bir şekilde kullanacağınıza inanıyoruz. Unutmayın, iyi tasarlanmış bir bağımlılık enjeksiyonu stratejisi, uygulamanızın gelecekteki büyümesi ve değişimi için sağlam bir temel oluşturur.

Sıkça Sorulan Sorular (SSS)

ASP.NET Core DI konteyneri thread-safe midir?

Evet, ASP.NET Core'un yerleşik DI konteyneri (IServiceProvider ve altında yatan mekanizmalar) thread-safe'dir. Servislerin kaydedilmesi ve çözümlenmesi işlemleri eş zamanlı olarak güvenli bir şekilde gerçekleştirilebilir. Ancak, Singleton ömürlü servislerin kendileri, eğer durum tutuyorlarsa, iş parçacığı güvenli (thread-safe) olacak şekilde tasarlanmalıdır. Bir Singleton servise birden fazla iş parçacığı aynı anda erişebilir ve iç durumunu değiştirebilir, bu da yarış koşullarına yol açabilir. Bu nedenle, Singleton servislerin durumsuz olması veya içerdiği durumu uygun kilitleme mekanizmalarıyla (lock, SemaphoreSlim vb.) koruması önemlidir.

Neden GetService() yerine constructor injection kullanmalıyım?

GetService() doğrudan IServiceProvider üzerinden bir servisi çözümleme yöntemidir ve "Service Locator" anti-pattern'ı olarak kabul edilir. Constructor injection ise bir sınıfın bağımlılıklarını yapıcı metodu aracılığıyla açıkça belirtmesini sağlar. Constructor injection kullanmak, sınıfın neye ihtiyaç duyduğunu ilk bakışta belli eder, test edilebilirliği artırır (bağımlılıkları kolayca mock edilebilir), gevşek bağlılığı teşvik eder ve sınıfın gerekli tüm bağımlılıklar olmadan oluşturulmamasını garanti eder. GetService() kullanımı bağımlılıkları gizler, testleri zorlaştırır ve sınıfın DI konteyneri hakkında bilgi sahibi olmasına neden olur, bu da kodun bakımını zorlaştırır.

Scoped bir servisi Singleton bir servise enjekte etmek neden sorunludur?

Bu durum "Captive Dependency" (tutucu bağımlılık) sorununa yol açar. Singleton ömürlü bir servis, uygulamanın yaşam döngüsü boyunca yalnızca bir kez oluşturulur ve ömrü boyunca bellekte kalır. Eğer bu Singleton servis, Scoped ömürlü bir servisi bağımlılık olarak alırsa, Scoped servis de Singleton servisle birlikte oluşturulur ve Singleton'ın ömrü boyunca onun tarafından hapsedilir. Bu, Scoped servisin her yeni istekte serbest bırakılması ve yeniden oluşturulması gereken beklenen davranışını bozar. Sonuç olarak, bellek sızıntılarına, eski veya yanlış durum bilgilerinin kullanılmasına ve kaynakların gereksiz yere meşgul edilmesine neden olabilir. Temel kural, her zaman bağımlılık grafiğinizdeki en kısa ömürlü servisin, kendisini kullanan servisten daha uzun veya eşit ömürlü olmaması gerektiğidir.

.NET 9 Kaynak Üreteçleri mevcut DI kodumu nasıl etkiler?

.NET 9 Kaynak Üreteçleri, genellikle geriye dönük uyumlu bir şekilde tasarlanır. Mevcut DI kodunuzu hemen değiştirmenizi gerektirmezler. Ancak, performans iyileştirmelerinden ve basitleştirilmiş servis kaydından faydalanmak isterseniz, belirli servislerinizi yeni özniteliklerle işaretleyerek kaynak üreteçlerinin devreye girmesini sağlayabilirsiniz. Bu, manuel AddScoped(), AddSingleton() gibi çağrılarınızı azaltarak veya tamamen ortadan kaldırarak kodunuzu sadeleştirebilir. Kaynak üreteçlerinin faydaları genellikle kademeli olarak ve isteğe bağlı olarak uygulanabilir. Bu yenilik, mevcut uygulamaların iyileştirilmesi için bir fırsat sunarken, geçiş sürecini yönetilebilir kılar.