Makale Özeti

Bu makalede frameworkumuze inversion of control bulastirip controllerlarimizin dependencylerinin otomatik olarak nasil cozulecegini anlatacagim

Makale

ASP.NET MVC framework'u genisletmek - 2

Framework'un genisletilebilir oldugundan daha once de bahsetmistik. Bu genisletilebilme genelde interface'lerin yogun olarak kullanilmasindan geliyor. Framework'un neredeyse her yerini kendi istedigimiz bir yapiyla degistirebiliyoruz. Testing amacli IHttpRequest'i mock edebildigimiz gibi, view engine'i degistirebiliyoruz veya Controller'lari saglayan factory'yi kendimiz implemente ediyoruz. Bu mlakalenin 2.sinde ben Controller factory'yi degistirip Windsor'un cozumleyebilecegi hale getirecegim. Boylece Controller'in bagimliliklarini cozumletebilir ve test edilebilirligi arttirabiliriz.

MVC framework'e ControllerFactory'mizi gecirebilmek icin yapmamiz gereken bu yeni yarattigimiz sinifin IControllerFactory'yi implemente etmesini saglamak. Boylece MVC framework  bu interface uzerinden CreateController metoduna cagri yapip bizim containerimizdan gelen Controlleri kullanabilir.

Ornek uygulamamiza baslayalim:

Yukaridaki kodda bir varsayim yaptim: Bu factory'yi kullanmak isteyen herhangi bir web uygulamasinin global.asax dosyasinin IContainerAccessor'u implemente etmesi. Sunu kabul etmem gerekir ki bu yontem, web uygulamasini Windsor ile coupled hale getiriyor, yani "container bagimsiz"(container agnostic) yapiyi yok ediyor ve Windsor'a bagimli hale getiriyor. Fakat bazen tasarim sirasinda karar vermek gerekir, her seyi decoupled yapmak pratikte pek de mumkun degildir. Illa da bagimsiz olsun diyorsaniz IDependencyResolver diye bir interface yazip kendiniz o sekilde devam edebilirsiniz.

Controller factory'miz yukaridaki gordugunuz kod kadar kisa.

Bu uygulamada dikkat etmemiz gereken bir nokta var: Controller'larin singleton olmamasi gerekiyor, yani her controller cozumleme cagrisi yapildiginda farkli bir ornek gelmeli containerdan. Bunu daha sonra config dosyalarini yazarken yapacagiz.

Simdi ornek uygulamamizi yazalim, bunun icin once yukarida kabul ettigimiz varsayimlari gercekleyelim.

Gordugunuz gibi web uygulamasi baslarken container'i yaratip default factory olarak kendi yarattigimiz WindsorControllerFactory'yi belirtiyoruz.

Container'in controller'daki dependencyleri cozup cozmedigini gorebilmek icin ise once Service.cs diye bir sinfi olusturalim, bu sinif ici bos, dummy bir sinif.

Ve simdi de Controller'imiza bagimlilik olarak bu sinifi ekleyelim

ve isin onemli kismina, config dosyalarina gelelim:


Burada yaptigimiz is container'imiza HomeController'i ve bu controllerin bagimliliklarindan olan Service sinifimizi belirttik.
Islem bu kadar basit.

Uygulamamizi calistirdigimizda Controller sinifimizin bagimsizliginin cozulmus halde elimize geldigini goruyoruz.

Boylece sinifimizin bagimliliklarini kendi elimizle cozme gereginden kurtulmus oluyoruz. Ayrica dependency injection yapilmasi sebebiyle controllerlarimizin bagimliliklarini onlarin Mock'lariyla degistirerek Controller'imizi test etmek icin izole bir yapi kazandirmis oluyoruz.