Son yılların trend konularından olan tasarım desenleri üzerine bir dizi blog kaydı yapayım dedim. Makale tadında Türkçe içerik oluşturmak açısından kullanışlı olabileceğini düşündüm. Bu arada isimlerin tercüme kargaşasının önüne geçmek için de en azından bulabildiğim Türkçe isimleri Wikipedia'da belirtildiği şekliyle kullanmış olacam.
İçerik sırası olarak kitap veya kullanım şeklini baz almak yerine de kullanım çokluğunu ilke olarak almanın daha faydalı olacağı düşüncesindeyim.
Bir deseni açıklarken; bu desenin ne olduğu, hangi problemlere çözüm getirebileceği(tabi hepsini söylemek zor ama en azından 1-2 tanesi fikir verme babında yararlı olacaktır), diğer benzer desenlerden ne farkı olduğu üzerinde duruyor olacam. Ayrıca yapabildiğim kadarıyla gerçek ve kullanışlı bir örnek sunmak istiyorum.
Umarım takip edecek arkadaşlar için faydalı olur.
7/25/2009
7/11/2009
Asenkron Logging Application Block
Enterprise Library(EL)'i ile loglama yapacaz ama bunun asenkron olmasını istiyoruz diyorsanız Microsoft da size malesef diyor. Esasında forumlarda araştırdığım kadarıyla da asenkron loglama yapmak yerine msmq trace listener'ını kullanın demişler. Bizim durumumuza pek uymuyordu.
Bunun için kendim asenkron olarak çalışacak bir CustomTraceListener oluşturdum. Yalnız sonradan düşen jeton bana birşeyi hatırlattı. Şayet asenkron loglamada herhangi bir hata oluşursa, Logging Application özel kaynaklarından olan Logging Error ayarları ile belirttiğiniz strateji çalışmıyor (asenkron istek için AsyncResult metodunda loglama sırasında oluşan hatayı bu amaçla throw etmiştim CustomTraceListener sınıfımda) ve loglama hatası uygulamayı patlatıyordu. Bu arada loglaması hatalı sonuçlanan log kaydını da kaybediyorduk. CustomTraceListener'da asenkron çağrılar yapmaktan vazgeçtim.
Sonraki denemem Logger sınıfını asenkron olarak çalıştıracak bir proxy oluşturdum. Artık Logger sınıfının Write metodunu ve 18 overload'ı asenkron olarak çağırıyorum. 4.o versiyonu ile kendi trace listener'ıma yaptığım testler olumlu geçti.
Bunun için kendim asenkron olarak çalışacak bir CustomTraceListener oluşturdum. Yalnız sonradan düşen jeton bana birşeyi hatırlattı. Şayet asenkron loglamada herhangi bir hata oluşursa, Logging Application özel kaynaklarından olan Logging Error ayarları ile belirttiğiniz strateji çalışmıyor (asenkron istek için AsyncResult metodunda loglama sırasında oluşan hatayı bu amaçla throw etmiştim CustomTraceListener sınıfımda) ve loglama hatası uygulamayı patlatıyordu. Bu arada loglaması hatalı sonuçlanan log kaydını da kaybediyorduk. CustomTraceListener'da asenkron çağrılar yapmaktan vazgeçtim.
Sonraki denemem Logger sınıfını asenkron olarak çalıştıracak bir proxy oluşturdum. Artık Logger sınıfının Write metodunu ve 18 overload'ı asenkron olarak çağırıyorum. 4.o versiyonu ile kendi trace listener'ıma yaptığım testler olumlu geçti.
7/03/2009
Gevşek Eşleşme (Loose Coupling) ve Test edilebilir kod
Esasında konuya Asp.Net MVC'den girecektim ama bahsedeceklerim teknoloji özgül değil; yine de meramımı ifade etmek açısından güzel bir örnek olacak.
Aşağıdaki köprü, Asp.Net MVC'nin eğitim belgelerinden. Yapılan örneği incelediğiniz vakit (sonradan makale içerisinde de vurgulanıyorda) sınıfların birbirinden bağımsızlığı sağlanmış vaziyette. Bunun için yapıcı metod enjeksiyonu kullanılmış.
Makale içinde bu konuda yapılan vurgu bunun servis katmanını tamamen teknoloji özgül bir halden kurtarmaya yönük olduğunu ifade etse de; diğer bir bakış açısından da daha test edilebilir kod yazmış oluyoruz.
Eğer testleri yazmayacaksak zaten Asp.Net MVC'nin (veya daha geniş bir bakış açısından MVC'nin) hakkını vermemiş oluruz diye düşünüyorum.
http://www.asp.net/learn/mvc/tutorial-38-cs.aspx
Aşağıdaki köprü, Asp.Net MVC'nin eğitim belgelerinden. Yapılan örneği incelediğiniz vakit (sonradan makale içerisinde de vurgulanıyorda) sınıfların birbirinden bağımsızlığı sağlanmış vaziyette. Bunun için yapıcı metod enjeksiyonu kullanılmış.
Makale içinde bu konuda yapılan vurgu bunun servis katmanını tamamen teknoloji özgül bir halden kurtarmaya yönük olduğunu ifade etse de; diğer bir bakış açısından da daha test edilebilir kod yazmış oluyoruz.
Eğer testleri yazmayacaksak zaten Asp.Net MVC'nin (veya daha geniş bir bakış açısından MVC'nin) hakkını vermemiş oluruz diye düşünüyorum.
http://www.asp.net/learn/mvc/tutorial-38-cs.aspx
Kaydol:
Kayıtlar (Atom)