Dependency Injection: ASP.NET MVC’de Loose Coupling

“`html

Modern yazılım geliştirmede esneklik, sürdürülebilirlik ve test edilebilirlik temel önceliklerdir. Bu hedeflere ulaşmanın en etkili yollarından biri Bağımlılık Enjeksiyonu (DI) tasarım desenini kullanmaktır. Bağımlılık Enjeksiyonu, bir nesnenin bağımlılıklarını kendisinin oluşturması yerine dışarıdan sağlanması prensibine dayanır. Bu yaklaşım, bileşenler arasındaki sıkı bağımlılığı ortadan kaldırarak kodunuzu daha modüler, yeniden kullanılabilir ve en önemlisi test edilebilir hale getirir. Bu makale, özellikle ASP.NET MVC uygulamalarında Dependency Injection’ı nasıl uygulayacağınızı adım adım ele alacaktır. Arayüzlerin gücünden, kurucu metot enjeksiyonuna ve ASP.NET MVC’nin yerleşik DI mekanizmasını kullanarak daha sağlam ve esnek uygulamalar geliştirmeyi öğreneceğiz.

understanding dependency injection and its benefits

Yazılım geliştirmede, bir nesnenin çalışmak için başka nesnelere (bağımlılıklara) ihtiyaç duyması yaygın bir durumdur. Geleneksel yaklaşımlarda, bu bağımlılıklar genellikle ihtiyaç duyulan nesnenin içinde doğrudan oluşturulur. Örneğin, bir denetleyici (controller) bir servis nesnesi oluşturabilir veya bir depo (repository) örneği alabilir. Ancak bu durum, sıkı bağımlılıklara yol açar: denetleyici, belirli bir servis uygulamasını bilir ve ona sıkı sıkıya bağlıdır. Bu da kodun değiştirilmesini, yeniden kullanılmasını ve özellikle test edilmesini zorlaştırır.

Bağımlılık Enjeksiyonu (DI), bu sorunu çözmek için tasarlanmış bir tasarım desenidir. DI’ın temel prensibi, bir nesnenin bağımlılıklarını kendisinin yaratmak yerine, dışarıdan, genellikle bir “enjektör” veya “kapsayıcı” (container) tarafından kendisine sağlanmasıdır. Bu, denetleyicinin veya herhangi bir bileşenin, spesifik bir uygulamaya bağımlı olmak yerine bir soyutlamaya (genellikle bir arayüz) bağlı olmasını sağlar. Sonuç olarak, bileşenler arasındaki bağ gevşer. Bu gevşek bağlama, uygulamanın modülerliğini artırır, bir bileşenin başka bir uygulamayla kolayca değiştirilebilmesini sağlar ve belki de en önemlisi, bileşenlerinizi bağımsız olarak test etmenizi inanılmaz derecede kolaylaştırır.

interfaces and constructor injection: building testable code

Bağımlılık Enjeksiyonu’nun gücünden tam olarak yararlanmak için arayüzler ve kurucu metot enjeksiyonu olmazsa olmazdır. Arayüzler, bir sınıfın ne yapması gerektiğini tanımlayan bir sözleşme görevi görür, ancak nasıl yapacağını belirtmez. Bu, farklı sınıfların aynı arayüzü uygulayarak farklı davranışlar sergileyebileceği anlamına gelir, ancak bu sınıfları kullanan kod, yalnızca arayüz üzerinden çalışır ve belirli bir uygulamayı bilmek zorunda kalmaz.

Bir örnekle açıklayalım. Bir web uygulamasında günlükleme (logging) işlevine ihtiyacımız olduğunu varsayalım. Bunun için bir arayüz tanımlayabiliriz:

public interface ILogger
{
    void Log(string message);
}
    

Şimdi bu arayüzü uygulayan iki farklı sınıf oluşturabiliriz: biri konsola günlükleme yaparken, diğeri bir dosyaya günlükleme yapabilir.

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"[Console Logger] {message}");
    }
}

public class FileLogger : ILogger
{
    public void Log(string message)
    {
        // Gerçek bir uygulamada dosyaya yazma işlemleri burada yapılır.
        // Basitlik adına, sadece konsola yazalım.
        Console.WriteLine($"[File Logger] {message}");
    }
}
    

Şimdi bu günlükleyiciyi bir ASP.NET MVC denetleyicisinde kullanmak istediğimizde, kurucu metot enjeksiyonunu tercih ederiz. Denetleyici, ihtiyacı olan ILogger arayüzünü kurucu metodu aracılığıyla talep eder:

public class HomeController : Controller
{
    private readonly ILogger _logger;

    public HomeController(ILogger logger)
    {
        _logger = logger;
    }

    public ActionResult Index()
    {
        _logger.Log("Home/Index action called.");
        ViewBag.Message = "Merhaba dünya!";
        return View();
    }
}
    

Bu yaklaşımın temel avantajı, HomeController‘ın somut bir ConsoleLogger veya FileLogger sınıfına bağımlı olmamasıdır; yalnızca ILogger arayüzüne bağlıdır. Bu sayede:

• Farklı bir günlükleme mekanizması kullanmak istediğimizde (örneğin veritabanı veya bulut tabanlı bir hizmet), tek yapmamız gereken ILogger arayüzünü uygulayan yeni bir sınıf oluşturmak ve bu yeni uygulamayı DI kapsayıcısına kaydetmektir. HomeController kodunu değiştirmemize gerek kalmaz.
• Test edilebilirlik büyük ölçüde artar. HomeController‘ı test ederken, gerçek bir günlükleyici yerine ILogger arayüzünü uygulayan sahte (mock) bir nesne enjekte edebiliriz. Bu, HomeController‘ın günlükleme mantığını diğer bileşenlerden tamamen izole ederek test etmemizi sağlar.

integrating with asp.net mvc’s dependency resolver

ASP.NET MVC (özellikle .NET Framework tabanlı versiyonlar), bağımlılıkların yönetimi için yerleşik bir DI kapsayıcısına doğrudan sahip olmasa da, bağımlılıkları çözümlemek için güçlü bir genişletilebilirlik noktası sunar: IDependencyResolver arayüzü. Bu arayüz, MVC çerçevesine denetleyici örneklerini ve denetleyicilerin bağımlılıklarını nasıl oluşturacağını söyler. Kendi özel bağımlılık çözümleyicinizi oluşturarak veya popüler üçüncü taraf DI kapsayıcılarını (örneğin Unity, Ninject, Autofac) bu arayüz üzerinden entegre ederek DI’ı uygulayabilirsiniz. Yerleşik bir mekanizma olarak IDependencyResolver‘ı kullanarak basit bir DI uygulamasını nasıl yapılandıracağımızı gösterelim.

İlk olarak, IDependencyResolver arayüzünü uygulayan kendi sınıfımızı oluşturalım. Bu sınıf, kaydedilmiş bağımlılıkları manuel olarak yönetecek basit bir DI mantığına sahip olacaktır. Gerçek uygulamalarda bu genellikle bir üçüncü taraf kapsayıcı tarafından yapılır, ancak bu örnek temel prensibi göstermek için yeterlidir.

using System;
using System.Collections.Generic;
using System.Web.Mvc;

public class CustomDependencyResolver : IDependencyResolver
{
    private readonly Dictionary<Type, Type> _registrations;

    public CustomDependencyResolver()
    {
        _registrations = new Dictionary<Type, Type>();
        // Bağımlılıklarımızı burada kaydediyoruz
        Register<ILogger, ConsoleLogger>(); // Varsayılan olarak ConsoleLogger kullan
    }

    public void Register<TInterface, TImplementation>() where TImplementation : TInterface
    {
        _registrations.Add(typeof(TInterface), typeof(TImplementation));
    }

    public object GetService(Type serviceType)
    {
        if (_registrations.ContainsKey(serviceType))
        {
            Type implementationType = _registrations[serviceType];
            // Enjekte edilecek nesnenin kurucu metot bağımlılıklarını da çözümlemesi gerekir.
            // Bu basit örnekte sadece varsayılan kurucu metodu çağırıyoruz.
            // Gerçek bir DI kapsayıcı, kurucu metot parametrelerini de çözümleyebilir.
            return Activator.CreateInstance(implementationType);
        }

        // Eğer istenen servis kaydedilmemişse, null dön.
        // Bu genellikle Controller'lar için geçerli değildir, çünkü Controller
        // MVC tarafından varsayılan olarak oluşturulmaya çalışılır.
        return null; 
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        // Birden fazla servisin çözümlenmesi gereken senaryolar için.
        // Basitlik adına boş bir liste dönüyoruz.
        return new List<object>();
    }
}
    

Yukarıdaki CustomDependencyResolver sınıfı, ILogger arayüzü için ConsoleLogger uygulamasını kaydetmektedir. GetService metodu çağrıldığında, istenen arayüze karşılık gelen somut sınıfın bir örneğini oluşturur ve döner. Bu basit örnek, sadece varsayılan (parametresiz) kurucu metotları olan bağımlılıkları çözebilir. Daha gelişmiş senaryolar için, bir DI kapsayıcısının iç yansımasını (reflection) kullanarak kurucu metot parametrelerini de çözümlemesi gerekir.

Son olarak, bu özel çözümleyiciyi uygulamanızın başlangıcında Global.asax dosyasında kaydetmeniz gerekir:

using System.Web.Mvc;
using System.Web.Routing;

namespace MyMvcApplication
{
    public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);

            // Özel Dependency Resolver'ımızı kaydet
            DependencyResolver.SetResolver(new CustomDependencyResolver());
        }
    }
}
    

Bu adımlarla, ASP.NET MVC uygulamanız artık bağımlılıkları IDependencyResolver aracılığıyla çözümleyecektir. HomeController bir ILogger istediğinde, çerçeve CustomDependencyResolver‘ımıza soracak ve o da kayıtlarımıza göre bir ConsoleLogger örneği oluşturup HomeController‘ın kurucu metoduna enjekte edecektir. Bu yapı, gelecekte farklı bir günlükleyiciye geçmek veya başka bir servisi enjekte etmek istediğinizde esneklik sağlar ve test yazmayı kolaylaştırır.

Özetle, Bağımlılık Enjeksiyonu deseni, ASP.NET MVC uygulamalarınızın kalitesini ve sürdürülebilirliğini önemli ölçüde artıran güçlü bir tekniktir. Arayüzleri kullanarak soyutlama sağlamak ve kurucu metot enjeksiyonunu tercih etmek, bileşenleriniz arasında gevşek bağımlılık oluşturmanın temelidir. Bu yaklaşım, uygulamanızın farklı bölümlerini kolayca değiştirebilmenizi veya geliştirebilmenizi sağlarken, en kritik fayda olarak kodunuzu birim testleri için son derece uygun hale getirir. ASP.NET MVC’nin Dependency Resolver mekanizması, bu bağımlılıkları merkezi bir yerden yönetmenize olanak tanır. Sonuç olarak, DI’ı benimsemek, daha okunabilir, bakımı kolay ve geleceğe dönük yazılım mimarileri inşa etmenin anahtarıdır.

“`

Resim Sahibi: MART PRODUCTION
https://www.pexels.com/@mart-production