Asp.NET Core Constructor Injection Hell
Herkese yeniden merhaba,
Umarım sizler için her şey yolundadır. Bugünkü yazımda üzerinde çalıştığım bir projede karşılaştığım soruna çözüm ararken varlığını keşfettiğim bir konu hakkında bilgi vermeye çalışacağım. Aslında buna tam olarak bir sorun diyemeyiz çünkü kodumuzun işleyişini bozan bir durum değil. Fakat yazdığınız kodun daha temiz ve düzenli görünmesini istiyorsanız yazıyı okumaya devam edebilirsiniz.
Önceki yazımda IoC Prensibi nedir ne değildir bahsederken Dependency Injection Design Pattern üzerine konuşarak örnek vermiştik. Dependency Injection Design Pattern’ ’i uygulamak için metod , property ve constructor olmak üzere üç yöntem mevcuttur demiştik. Bu yazım bu yöntemler arasında en popüler olan “constructor injection” üzerine olacaktır. Asp.Net Core uygulamalarımızda “constructor injection” kullanırken IoC container’dan nesneleri talep etmek üzere constructor’da aşağıdaki gibi bir injection işlemi uygulamaktayız:
Projemiz büyüdükçe constructor’daki injection işlemleride artmaktadır. Bu da aşağıdaki gibi bir görüntüye sebebiyet vermekte:
Kullanılan interface sayısı az olduğunda (3–6) sorun teşkil etmeyen bu yöntemde injection sayısında bariz bir artış oluştuğunda istediğimiz servisi bulmak veya eklemek bile başlı başına büyük bir problem teşkil ediyor. Oluşan bu durum Constructor Injection Hell olarak nitelendirilmektedir.
Sorunlar neler:
1-) Constructor’un fazla parametre alması best practices açısından uygun değil.
2-) Constructor 10/100 kuralını çiğner.
Not: 10/100 Kuralı
1 -Bir metot 10 satıra ulaşırsa durup metodu refactoring yapmayı düşünmeliyiz.
2-Bir sınıf 100 satıra ulaşırsa (yorumlar ve parantezler dahil) durup refactoring yapmayı düşünmeliyiz.
3-) DRY (Don’t Repeat Yourself) ve KISS (Keep It Simple, Stupid) prensiplerini ihlal eder.
Not: DRY And KISS Principle
— DRY prensini “Kendini Tekrar Etme” anlamına gelir. Bir yazılımın farklı bölümlerinde benzer kodların olmaması gerektiğini söyler. Örneğin aynı işi yapan bir metodu farklı yerlerde tekrar tekrar yazmak yerine, tek bir metodu her yerde kullanılmasını amaçlar.
— KISS prensibi “Basit Tut, Aptal” anlamına gelir. Bu prensip, kodu basit ve açık tutmayı ve böylece herkesin anlamasını kolaylaştırmayı amaçlar.
4-) Dependency Injection Hell’e maruz kalmış bir constructor, o sınıfın birden fazla sorumluluğunun olduğuna işaret eder. Ve bu durum SOLID’in Single Responsibility Prensibini ihlal etmektedir. Peki bunun çözümü nedir?
Build-in AspNetCoreInjection.TypedFactories Kütüphanesi
Projemize Nuget Manager’dan AspNetCoreInjection.TypedFactories kütüphanesini indiriyoruz. Ardından biz sadece controller tarafı için bu işlemi gerçekleştireceğimizden dolayı business sınıflarının implement’e ettiği interface’leri tek bir factory interface’i altında topluyoruz:
IBusinessFactory adındaki interface’imizi oluşturduk. Bu interface bize build-in IoC container olan AspNetCoreInjection.TypedFactories ‘den nesne örneği talep ederken kullanılacak. Ardından Program.cs sınıfına gelerek aşağıdaki register işlemlerini gerçekleştiriyoruz:
Son olarak controller tarafında aşağıdaki injection işlemlerini gerçekleştiriyoruz:
Görüldüğü üzere constructor’ımıza sadece bir tane injection uyguladık. Bu sayede daha temiz , sade ve anlaşılır bir koda kavuştuk. Bundan sonra sınıfımıza yeni bir business(servis) nesnesini enjekte edeceğimiz zaman bunu IBusinessFactory interface’i yardımıyla yapacağız.
Evet her şey tamam göründüğüne göre yazımızın da bitme vakti geldi demektir. Eğer gözümden kaçan yazım hatası veya anlatım bozukluğu olduysa şimdiden kusuruma bakmayın. Okuduğunuz için şimdiden teşekkür ederim. Bir sonraki yazıda görüşmek üzere!
Yararlandığım Başlıca Kaynaklar:
