Caner Tosuner

Leave your code better than you found it

Redis Server Windows Üzerinde Kurulumu ve Kullanımı

Bu yazıda Distributed Caching sistemlerinden biri olan Redis'i inceliyor olacağız.

Redis Nedir ?

Redis için kısaca open source bir NOSQL Memcached veritabanı sistemidir diyebiliriz. Her ne kadar ilk olarak Linux için tasarlanmış olsada ihtiyaç doğrultusunda Windows işletim sistemlerinde de kullanılabilir hale getirildi. Çalışma şekli olarak Key-Value şeklinde gönderilen bilgileri store etmektedir. 

 

Veri Tipleri

Redis verileri String, Hashe, List, Set ve Sorted List olarak saklayabilir.

 Veri tipleri ile ilgili daha ayrıntılı bilgiyi bu linkte bulabilirsiniz. 

Kurulum ve Kullanımı

Öncelikle Redis'i indirip service olarak bilgisayarımıza kuruyoruz. Bunun için bu linkten sizin için uygun olan .rar uzantılı sürümü bulup bilgisayarımıza indiriyoruz. Sonrasında indirmiş olduğunuz dosyalardan redis-server.exe adlı exe'yi çalıştırıp kurulumu yapıyoruz. Default olarak 6379 port'unu hizmete sokar ancak istersek bunu değiştirebiliriz de. Exe çalıştıktan sonra aşağıdaki gibi bir ekran gördüyseniz kurulum OK dir.

Redis çalışıp çalışmadığına dair kontrol için redis-cli.exe'yi çalıştıralım ve aşağıdaki resimde olduğu gibi test amaçlı bir key-value tanımlayıp sonrasında get set işlemi yapalım

Bu yazımızda Windows üzerinde Redis Server nasıl kurulur ve kullanılır bunu gördük. Bir sonraki Redis yazımızda StackExchange.Redis redis client kullanarak NET dilleri için (C# etc) örnek proje yapıyor olacağız.

Server Side Bir Projede Olmazsa Olmazlar || Olursa Güzel Olurlar

Server-side geliştirme yaparken projemizde olursa olmazsa olmaz OR güzel olur diyebileceğimiz bazı modüller&özellikler vardır ve bu özellikler bir çok kitap yazarı, ünlü blogger veya eğitmenler tarafından kabul görmüş özelliklerdir. Yazının başlığına bakacak olursak "Olmazsa Olmazlar" şeklinde ancak yazılım denen şey tabi ki "it depends on the business" duruma göre,ihtiyaca göre geliştirilen bir şey ve "Olmazsa Olmaz" dan kasıt bu zamana kadar hem kendi okuduğum çeşitli makalelerde vurgulanan hemde geliştirmiş olduğum çeşitli projelerde deneyimlediklerimden yola çıkarak 5 farklı önemli özellik var ki bu özellikler gerçekten kurumsal veya büyük çaplı bir projede farkında olarak veya olmadan size oldukça fazla fayda sağlamaktadır.

Bu 5 başlığı sırasıyla yazacak olursak;

  1. Security,
  2. Exception Handling,
  3. Logging,
  4. Response Consistency,
  5. Development Environment

 

1- Security

Bazı bilgiler vardır uygulamanız için veya uygulamayı kullanan kişiler için çok ama çok önemlidir. Örneğin; tckn bilgisi, banka hesap numarası, userId bilgisi, username-password bilgisi vs. bu gibi bilgilere hiç kimsenin ulaşmasını istemeyiz. Günümüzde fiddler, wireshark vb. tool'ları kullanarak client-server arasındaki gidip gelen http paketleri rahatlıkla dinlenmekte ve kötü niyetli bazı kişiler araya girerek giden data'da bulunan tckn,accounNumber,amount vs gibi alanları değiştirip bir çeşit dolandırıcılık yapabilmekteler. Genel de çözüm olarak "ya https yaparız abi hiç bişey olmaz.." şeklinde cümleler kurulup service'i https olarak dışarıya açarlar ve bu tehlikeyi önlediklerini sanarlar ancak artık https bile çeşitli yollar denenerek decrypte edilebilmekte.

Security'den kasıt aslında token based authentication vs. değilde request&response gelip giderken data için uygulanabilecek security. Tabiki de service'e gelecek olan client'ları belli authentication ve authorization kontrollerinden geçirdikten sonra içeriye almak gibi bir çok yöntem mevcut ancak data-trasnfer sırasında belli bazı önlemler alarak projenizin güvenliğini biraz daha atırabilirsiniz. Bunun için çeşitli yöntemler bulunmakta. Property bazında istenilen değeri şifleme veya maskeleme. Örneğin; UserLoginRequest adında bir modeliniz var ve içerisinde bulunan UserName, Password string alanlarını şifreleyebilirsiniz. Diğer bir yöntem ise endpoint'e gelen request ve endpoint'ten çıkan response modellerinizin tamamını şifreleyerek data transferini sağlayabilirsiniz ki bu daha base-oriented bir çözüm gibi duruyor. Örnek bir response örneği aşağıdaki gibi olabilir.

public class BaseResponse
{
	public object Data {get;set;} // şifrelenmiş bir şekilde endpoint'in return ettiği response Data içerisinde gönderilebilir
	public bool IsCrypted {get;set;} her endpoint şifrelenmiş şekilde response dönmeyebilir, client'ı bilgilendirmek adına bir bool alan tutabilirsiniz
}

Not: Checksum'da unutulmaması gereken diğer bir yöntemdir. Checksum kullanarak gelip giden data uzunluğu belli bir algoritma ile şifrelenip çift taraflı kontrol uygulanarak da güvenlik sağlamak işinizi baya bi kolaylaştırabilir.

 

2- Exception Handling

"Hatasız kod olmaz.."

Exception handling her bir proje için oldukça önemli bir konudur. Hatasız kul olmayacağı gibi hatasız kod da olmaz. Exception fırlatabileceğiniz düşündüğümüz yerleri zaten önceden tedbirini alıp handle ediyoruzdur ama asıl önemli olan beklenmedik hataları nasıl handle edeceğimizdir. En yaygın hatalardan biri olan null reference exception hemen hemen bütün projelerde başımıza gelmiş bir exception türüdür ve projeniz bu hatayı fırlattığında client'a http500 internal server error dönecektir. Peki bu tür hataları handle etmek için ne yapmak gerekir ?? Bir çok projede olduğu gibi her yere try catch koyarak kodunuzu spaghetti code haline getirip yönetilmesi zor bir proje haline getirmek heralde yapılabilecek en kolay çözüm. Öyle projeler var ki denk geldiğim adam try catch e bile güvenmeyip iç içe 2 try catch yazmış.

Bu ve benzeri durumlardan sakınmak gerekir. Open-source dünya ile birlikte exception handling için bir çok kütüphaneler-yöntemler mevcut. Projeniz için her yerde kullanabileceğiniz küçük küçük interceptor'lar yazarak exception handling'inizi tek bir yerden yönetebilir ve projenize reuseable fonksiyonaliteler kazandırabilirsiniz. Aspect-Oriented Programming anlayışı aslında en güzel örnek Nuget'te bulunan çeşitli kütüphaneler ile bir kaç dakika içerisinde bu modülleri projenize ekleyebilirsiniz.

Bu gibi yapılar ile çok kolay şekilde projenizi yönetebilir ve tek bir yerden kontrol edilebilir kodlar geliştirebilirsiniz. Böylelikle yarın bir gün exception handling ile ilgili değişiklikler yapmak istediğinizde bu işlem saatlerinizi almak yerine bir kaç dakikada yapabileceğiniz bir geliştirme olacaktır.

 

3- Logging

"Log, uğrunda ölen olmadıktan sonra log değildir.."

Log bir projede her şeydir. Küçük çaplı projeleri baz almazsak log yapısı büyük çapta olan projeler için oldukça hayati önem taşır. Öyle bir an gelir ki log'a attığınız küçücük bir byte size dünyaları kazandırır. Tabi log işlemi yaparken kayda değer şeyler logluyor olmak oldukça önemlidir. Özellikle dışa bağımlı çalıştığınız projelerde yani external bir service call işlemi olan yapılarda gelip giden request & response'ları context halinde logluyor olmak oldukça kolaylık sağlar. Gerek db ye gerekse file log yaparken bütün bu işemleri uçtan uca logluyor olmak ve aralarında ilişkileri bir unique identifier kullanarak loglamak gerekir. Örnek verecek olursak "getAccountList" adında geliştirdiğiniz bir endpoint var ve client'lar bu endpoint'e request atarak hesap listesini alıyor sizde client bu endpoint'e geldiğinde arka tarafta başka bir endpoint'e gidip hesap listesi ile ilgili farklı service call işlemleri yapıyorsunuz. Geliştirmiş olduğunuz log yapısından beklenen, belli bir context olarak uçtan uca hem client'ın request'ini hemde sizin server-side da yapmış olduğunuz diğer servis çağrımlarını logluyor olması gerekir. Bu size şunu kazandırır production'da olan bir müşteri şöyle bir şikayetle müşteri hizmetlerine şikayet bırakabilir "ben saat 11:38'den hesaplarım sayfasını görüntüleyemiyorum, sayfa boş geliyor..." bu gibi durumlarda hemen müşteri numarasından yola çıkarak log'ları kontrol ettiğinizde sorunun sizin geliştirdiğiniz service katmanından değilde dışa bağlandığınız service'den kaynaklandığını kolaylıkla görebilirsiniz. Bu logları internal ve external olarak ayırmakta fayda olabilir zira proje müdürü sizden ilerleyen zamanlarda yüzdelik olarak success ve fail oranlarını isteyebilir yani aslında tutmuş olduğunuz log'lardan yola çıkılarak proje yöneticileri analiz dahi yapmak isteyebilirler. Loglama ile ilgili örnek yazıları buradan göz atabilirsiniz.

Not: Log için çok çeşitli open source kaynaklar bulunmakta. Geliştirmelerinizi loosely coupled olacak şekilde yapıyor olursanız ilerde log yapınızla ilgili kolay değişiklik yapabilir, farklı log yapılarına kolay geçişler sağlayabilirsiniz.

 

4- Response Consistency

Response tutarsızlığı herhalde Türkiye de geliştirilen server-side projelerde ki en büyük sorunlardan biri olabilir. Bir çok defa dış servislere bağlı proje geliştirmiş biri olarak aynı namespace altında olup farklı farklı response'lar dönen durumlarla epeyce bir karşılaştım. Peki projenizde bulunan end-point'lerin döndükleri response'ların tutarlı olması neden önemlidir ? Bu sorunun cevabı hem server-side'da bulunan proje açısından hemde client açısından büyük öneme sahiptir.

Server-side açısından; öncelikle uygulamada exception-handling, logging, caching vs. gibi özellikleri geliştirirken endpoint'lerinizin return ettikleri response'ların bir BaseResponse.cs'den türüyor olması tercih edildiğinde bu gibi operasyonlar için yapılması gereken geliştirmelere harcanan eforu hemen hemen yarı yarıya azaltabilirsiniz. Yapmış olduğunuz BaseResponse.cs içerisinde Error case'leri için de bir property'iniz olması gerekir çünkü client'a farklı akışları olan error-exception mesajları dönebilirsiniz. 

Örnek BaseResponse.cs

public class BaseResponse
{
	public object Data {get;set;} // endpoint'in return ettiği response
	public ErrorModel Error {get;set;} // endpoint'in return ettiği error model
}

Client açısından; yukarıda ki BaseResponse örneğinden yola çıkacak olursak client tarafta geliştirilen network-layer da gelen response açılarak endpoint'in gönderdiği Data içerisinde bulunan gerçek response alınabilir ve sonrasında alt katmanlara gönderilip işlenebilir ve bunu yapabiliyor olmak client yazan arkadaşlar bilirler ki büyük bir nimettir. Servisten hata geldiğinde ise ErrorModel tipinde olan Error property'imiz içerisinde client'a gelen hata mesajı yine network katmanında alınıp base'den hata yönetimi yapılabilen bir layer'a gönderilip gerek pop-up ile hata mesajını gösterme gerekse kullanıcının o hata türünü aldığında uygulamada nasıl bir akışa yönlendirilmesi gibi işlemler yapılmasına kolaylık sağlanabilir.

 

5- Farklı Development Environment

"Dev de çalışıyor ama Test ortamında çalışmıyor..."

Development environment oldukça önemli bir diğer konudur. Farklı ortamlarda geliştirme yapıyor olmak biz developer'lar için eksik konfigurasyon vs gibi durumlarda başımızı ağrıtan bir durum olsada aslında çok önemli bir konudur. Bilindiği üzre Production seviyesinde geliştirme yapmak mümkün değil ama geliştirmekte olduğumuz ürünü prod'a aldığımızda sorunsuz çalışması istenir. Projenizi geliştirirken o an geliştirdiğiniz ortam, test işlemlerinin yapıldığı ortam ve production ortamlarının her birinde farklı konfigurasyonların olduğu server'lar sql'ler vs. bulunur. Geliştirme yaparken bu ortamların yönetimi ve konfigürasyonu oldukça basit ve ortamlar arası geçiş sorunsuz 1-2 hareketle geçilebiliyor olması beklenir. Peki bu development ortamları nelerdir ?

Development
Development ortamı ismindende anlaşıldığı üzre developer'ların geliştirme yaptığı ortam. Bu ortam developer istediğini yapmakta özgürdür diyebiliriz. Developer kritik kararlar alıp anlık değişiklikleri projede deneyebilir çünkü bu ortam onun kendi bireysel ortamıdır diyebiliriz.

Integration
Development ortamında bireysel olarak yapılan geliştirmelerin ortak bir branch'e commit'lenip bütün geliştirmelerin ortak bir alanda gözlemlendiği alan diyebiliriz. Kısaca bu ortamın amacı yapılan işlerin stage'ing den önce combine edilip developer'ların saptayabildiği bir hata varsa hemen fix edilip ürünü görücüye çıkartma şeklinde tanımlayabiliriz.

Staging
Staging Production'dan önceki ortamdır ve sahip olduğu özellikler itibari ile production'ın ile bire bir aynı olması beklenir. Örneğin benzer özelliklere sahip sunucular, sql server'lar, canlıda olan database'in bir gün öncesinin verilerine sahip bir database vs. gibi. Staging ortamına bir çok yerde Pre-Production da denilmekte.

Production
Son adım olarak da Production ortamı artık geliştirmiş olduğunuz projeyi canlıya aldığınız ve son kullanıcının erişimine açtığınız yerdir. Prod'a gelene kadar ki ortamlarda yapılan geliştirmeler sorunsuz-planlı bir şekilde yapıldığı taktirde testler sonucunda ürün prod'a alınır.

 

Yazının başında da belirtiğim gibi "it depends on the business" yani işe bağlı projeye bağlı. Olursa güzel olur diyebileceğimiz bu modülleri projelerinizde farklı şekillerde düşünebilir entegre edebilirsiniz.

Servisten Gelmeli || Client Yapmalı

Servisten mi gelmeli yoksa client mı yapmalı ?.. 

Hem server tarafta hem de client tarafta geliştirme yapan biri olarak kolayca söyleyebilirim ki bu iki soru yazılımla uğraşan kişilerin sıkça dile getirdiği sorulardan dır. Özellikle 10-12 kişilik development ekiplerinin bulunduğu projelerde client ve server tarafını geliştiren kişilerin genelde scrum'larda birbirlerine karşı dile getirirler bu cümleleri. Jira'da yeni bir bug açılır analist arkadaş genelde platform belirtilmişse direkt olarak bug'ı o platformu geliştiren kişiye assign eder. Sonrasında o arkadaş ilgili bug'ın altına server-side geliştirmesini yapan arkadaşlardan birini mention'layarak şu sihirli yorumu yazar "servisten gelmeli veya servis yapmalı" veya bunun tam tersi bug server-side geliştirme yapan kişiye açılır o yorum yazarak "client yapmalı" vs şeklinde bir cümle yazar. İşte taht kavgaları tamda o anda başlar.

Aslında bu gereksiz kavganın yaşanmasındaki sebeplerin başında gerekli geliştirme hem client hem de server tarafta da yapılabiliyordur ancak developer geliştirmeyi üzerine almak istemediğinden diğer tarafa atmak ister. Bir kaç ördenk case den yola çıkarak bu soruna çözüm bulabiliriz aslında. 

SOA gerçeklerinden yola çıkacak olursak yönetimin service tarafından yapılabiliyor olması bir projede oldukça önemlidir. Örneğin bir mobil proje geliştiriyorsunuz ve username password yanlış olduğunda kullanıcıya gösterdiğiniz bir uyarı metni var "Girmiş olduğunuz bilgiler hatalıdır." şeklinde. Bu geliştirmeyi client tarafta yaptığınızı düşünelim ve uygulama marketteyken müşteri dedi ki "ya biz şu metni Girmiş olduğunuz bilgiler hatalıdır. Lütfen tekrar deneyiniz." olarak değiştirelim ve bunu hemen 1-2 saat içerisinde yapalım. Proje müdür OK verdi ve geliştirmeyi yapmak için hem ios hem android projelerinde metni değiştirdiniz tekrardan markete submit ettiniz. Uygulamanın market onay sürecinden geçmesi özellikle ios tarafında bazen 1 hafta dahi sürebiliyor. Ne oldu peki müşteri 1-2 saatte halledelim dedi ancak siz 1 haftada halledebildiniz. Eğer client'cı arkadaşların dediği gibi "geliştirmeyi servis yapsın" cümlesini dinleyerek yola çıksaydık ve geliştme service tarafında yapılmış olsaydı hemen ilgili metin değişikliğini db'de bulunan tablodan güncelleyip dakikalar içerisinde isteği yerine getirmiş olacaktık. 

Tabi client'ın her dediği yapıldığında da bir süre sonra servisci arkadaşlarda şu cümleyi ister sitemez duyabiliyoruz "e uygulamayı biz yazıyoz zaten client napıyo ki.." Bu gibi durumlar içinde aslında çok arada kalınan bir case ise ve client'ın yapması daha kolay bir durum ise client'ta yapmak daha doğru olacaktır. Örnek olarak karşılaştığım bir case olmuştu. Uygulamada ürün detay sayfasının bir bölümünün arka planında blur şekilde ürün görselinni gösterilmesi isteniyordu ve ürün resmi dış servis sağlayıcıdan dikdörtgen şeklinde geliyordu. Bunun için client tarafı bu geliştirmeyi servis yapacak demiş ve servis tarafını geliştiren ekibe yani bize şöyle bir geliştirme ticket'ı açıldı "Gelen dikdörtgen resim alınacak resmin en ortada bulunan kısmından 200x200 boyutlarında bulunan kısmı alnıp client'a o şekilde gönderilecek..." ve 2 gün sonra sürüm çıkmayı planlıyoruz.. WTF oluyosun ilk okuduğunda ama geliştirmede bu. Muhakak yapılır ancak ne gerek var o kadar uğraşmaya diyor insan. Daha önceleri client geliştirmesi yapıtığımdan biliyorum ki o resmi client tarafta alıp arka plana yerleştirip ortalamak max 15 dkkalık bir iş olsa gerek. Hemen takım liderine durumu anlattım ve hakiketen client tarafı 15-20 dkka içerisinde istenilen geliştirmeyi yaptı. Burda şunu sorabilirsiniz, e yarın 300x300 olacak şekilde isterlerse ne olacak ? Olabilir tabikide ancak 15 dkka nere 1-2 gün nere. Bu gibi durumlarda ekip olarak çoğunluğa göre karar alınıp en hızlı çözüm hangisi ise o uygulanmaya çalışılır.

Sonuç olarak; serviste mi gelmeli yoksa client mı yapmalı diye tekrar soracak olursak "it depends on the business" diyorum ben yani işe göre değişir ve her ne kadar herşeyi servisten yönetmemiz gereksede gerçek olan o ana göre mantıklı olan çözüm ney ise o taraf yapıyor olmalıdır. Gerçekten iki tarafıda en iyi şekilde bilen bir kişiye danışarak veya iki taraf bir araya gelip istişare yaptıktan sonra en efektif çözüm bulunacaktır.

 

ServiceLocator Design Pattern

Design pattern'leri spagetti kodlara veya tekrar eden kod bloklarına çözümler olarak ortaya çıkmışlardır. ServiceLocator design pattern ile bağımsız bir şekilde geliştirilebilen, test edilebilen loosely coupled modüller inşa edebilirsiniz. 

ServiceLocator'ı kısaca tanımlamak gerekirse projede kullanılan service instance'larını tek bir yerden add ve get yönetimini yapma işlemlerinden sorumludur diyebiliriz.

İmplemente ederken bağımlılığı interface ve propertilerden veya constructor seviyesinde inject edilebilirsiniz.

Örnek verecek olursak birden fazla service instance'ınızın bulunduğu bir proje var ve bir ara katman web service projesi ile bu servislerin metotlarını dışarıya açtınız diyelim. Her bir metot call işleminde service instance oluşturmak yerine app-start veya başka bir anda instance'ları ServiceLocator'a register edip sonrasında ihtiyaç duyulan yerlerde burada bulunan instance'lar üzerinden service'leri kullanmak diyebiliriz.

ServiceLocator'ın temel yapı taşlarını aşağıdaki gibi sıralayabiliriz;

  1. ServiceLocator , İhtiyaç duyulan service instance'ının yaratılmasından sorumludur, eğer yaratılmışsa da serviceRepository görevi görür diyebiliriz,
  2. Initializer ,  Runtime'da service instance'ının yaratılmasından sorumludur. Instance bir kere oluşturulduğunda ServiceLocator içerisinde store edilir,
  3. Client , Service consumer'larını veya service client'larını temsil eder,
  4. Service(s) , Service contract'larını ve onların implementasyonunu temsil eder.

 

ServiceLocator Patter'nin Implementasyonu

İlk olarak VS kullanarak bir tane WCF projesi oluşturalım ve sonrasında CustomerService ve ProductService adında 2 tane service oluşturalım. Bu iki service'in contract interface'leride aşağıdaki gibi tanımlayalım.

        [ServiceContract]
        public interface ICustomerService
        {
            [OperationContract]
            string GetName();
        }

        [ServiceContract]
        public interface IProductService
        {
            [OperationContract]
            string GetName();
        }

Sırada bu contract'ları service'lere implement etme var.

        public class ProductService : IProductService
        {
            public string GetName()
            {
                return "Fitbit";
            }
        }

        public class CustomerService : ICustomerService
        {
            public string GetName()
            {
                return "John travolta";
            }
        }

Şimdi ise sırada ServiceLocator class'ını yaratmak var. Bu class static olacak ve içerisinde service instance'larını tutan bir Dictionary bulunduracak. Bu Dictionary için get ve set operasyonları kullanılmak üzre ServiceLocator class içerisinde RegisterService ve GetService adında 2 adet metot tanımlayacağız. RegisterService instance'ları dictionary'e eklemek için kullanacağımız metot. GetService ise dictionary'de bulunan service instance'ını return eden metot olacak.

    public static class ServiceLocator
    {
        private static readonly Dictionary<Type, object> registeredServices = new Dictionary<Type, object>();

        public static T GetService<T>()
        {
            return (T)registeredServices[typeof(T)];
        }

        public static void RegisterService<T>(T service)
        {
            registeredServices[typeof(T)] = service;
        }

        public static int Count
        {
            get { return registeredServices.Count; }
        }
    }

Bu aşamaya kadar oldukça basit bir ServiceLocator pattern ile projemizi oluşturduk. Şimdi ise sırada oluşturduğumuz bu Locator'ı proje içerisinde kullanmak var.

    static void Main(string[] args)
       {
           ICustomerService customerService = new CustomerService();//service instance aldık

           IProductService productService = new ProductService();//service instance aldık

           ServiceLocator.RegisterService(customerService);//service locator'da bulunan dictionary içerisine attık

           ServiceLocator.RegisterService(productService);//service locator'da bulunan dictionary içerisine attık

           ICustomerService customerClientService = ServiceLocator.GetService<ICustomerService>();//dictionary içerisinde bulunan service instance'ını aldık

           string msg = customerClientService.GetName();

           Console.WriteLine(msg);
       }

 

ServiceLocator pattern'i objelerinizi bağımlılıklarından ayırmak istediğinizde veya compile-time'da bağımlılıkları bilinmeyen objeler oluşturmanız gerektiğinde güzel bir seçenek olabilir. 

Kısaca Agile Nedir Neler Gerektirir

Agile aşağı Agile yukarı... Herkes bir agile'dır gidiyor ama malesef çoğu kişi için agile bir kaç cümle veya kelimeden ibaret.

Bir çok Yönetici & Patron için çabucak at koşturur gibi işi yapıp bitirme,

Bir çok çalışan için ise agile jira'da bulunan bug'ları çözmekten ve scrum yapmaktan ibaret..

Malesef Türkiye'de biraz gerilerde ancak güzel haberlerde gelmiyor değil, öyle ki bazı kurumsal bankalar dahi yazılım departmanı olmadığı halde kendi iç birimlerinde agile'ı test etmeye başladığı söyleniyor ve Türkiye'de bulunan çok büyük bir bankanın da bütün birimleriyle agile'a %100 geçtiğiyle ilgili geçenlerde bir haber okumuştum. Tabi bunlar agile doğru anlaşıldığı zaman güzel haberler oluyor.

Sektörde bulunan yazılım firmalarında ki bir çok development takımı kendi içlerinde agile yaptıklarını söylüyorlar ancak işin aslını konuşmaya çalıştığınızda anlıyorsunuz ki sadece agile'a ait bir kaç işi yaptıkları ortaya çıkıyor.

Scrum için ise aslında yapılan şey iş yoğunluğa göre bazı sabahlar proje müdürünün ekibi toplayıp sadece kendisinin konuşması...

 

Peki Agile olmak neleri gerektirir ?

Daha önce okuduğum ve bir çok kişininde referans alarak uygulamaya çalıştığı "What Do We Know About Scientific Software Development’s Agile Practices ?" makalesinde belirtilen 35 Agile Best Practice'i baz alarak takım olarak ne yapıp ne yapmıyorsunuz, ne kadar agile'sınız yorumlayabilirsiniz. 

  1. Önceliklendirmeler projede en yetkili kişi olan product owner tarafından (ekibin fikrini alarak) yapılmalı,
  2. Development sürecindeki sorunlar scrum master tarafından scrum'larda çözüm aranmalı,
  3. Spring backlog oluşturmak için Spring planlama toplantıları yapılmalı,
  4. Efor verirken Planning Poker oyunu gibi eğlenceli bir seçiminiz olmalı,
  5. Kısa ve Orta vadede koşan sprint'leriniz olmalı,
  6. Product owner ve ekip arasında sürekli bir communication olmalı,
  7. Mevcut konuları konuşmak için kısa daily meeting'ler düzenlenmeli,
  8. Self-organization yani kendiliğinden organize olabilen bir ekip uluşturulabilmeli,
  9. Grafikler ile sprint süreci gözlemlenmeli,
  10. Sprint sonlarında review toplantıları düzenlenmeli,
  11. Retrospective yaparak geçmiş sprintle ilgili değerlendirmelerde bulunulmalı,
  12. Short & Fast product release'ler çıkılmalı,
  13. User storie'ler yazılmalı,
  14. Takıma dedike bir şekilde çalışabileceği açık çalışma alanları yaratılmalı,
  15. Sürdürülebilir bir çalışma ortamı sunulmalı,
  16. Proje ivmesi ölçülebilmeli,
  17. Ekipte bulunanlar her konuda fikrini söyleyebilmeli,
  18. Müşteriye ihtiyaç duyulduğunda hemen ulaşılabiliyor olmalı,
  19. Ekip olarak kod standartları belirlenmeli,
  20. İlk önce unit-test'ler yazılmalı,
  21. Prod'a alınan kod'un bir pair-programming ürünü olduğu unutulmamalı,
  22. Geliştirmeler branch'lere ayrılarak yapılmalı ve test sonuçlarına göre merge işlemi yapılmalı,
  23. Sürekli olarak yeni şeyler entegre edilebilecek altyapıya sahip bir altyapı,
  24. Repository yönetimini iyi yapıp release günü geldiğinde sorunsuz bir şekilde release çıkılabilmeli,
  25. Collective bir biçimde developer'lar atayın bir sorumluluğu tek bir kişiye yüklemekten kaçının,
  26. Basit bir tasarıma desenine sahip olmalı,
  27. Bir sistem metforu seçilmeli,
  28. Design&Development için Class-responsibility-collaboration kartlarını kullanmaya çalışın,
  29. Riski azaltmak için çözümler üretilmeli,
  30. İhtiyaç duyulmayan hiç bir fonksiyonalite önceden entegre edilmemeli,
  31. Ne zaman-Nerde olduğuna bakılmaksızın refactor edilebilmeli,
  32. Bütün kod'un unit-test'i yazılmış olmalı,
  33. Proje prod'a alınmadan önce bütün unit-test'lerden geçmeli,
  34. Yeni bir bug bulunduğunda testler anında oluşturulmalı,
  35. Acceptence-test'ler sıklıkla uygulanmalı ve skor yayınlanmalı.

 

Agile hakkında söylenecek oldukca fazla şey bulunuyor ancak kısa bir özetle yukarıda ki rule'ları sıralamış olduk. İyi bir agile-team oluştururken bu kurallardan faydalanmak çöğunlukla iyi olacaktır ama belirttiğim gibi liste genişletilebilir de.

Caching With Postsharp

Cache bir proje için olmazsa olmazlardan biridir diyebiliriz ve ihtiyaç duyulduğunda çok can kurtarır. Öyleki çok fazla değişmesini düşünmediğiniz verileri cache de saklayarak reqeust response time konusunda projenize oldukça fazla performans kazandırabilirsiniz. Daha önceki web api için cache ve aspect oriented - postsharp konularından bahsetmiştik. WCF Service projenize Postsharp ile basit bir server-side cache yapısı kurabilirsin.

İlk adım olarak cache de tutacağımız CacheModel adlı model'i tanımlayalım.

public class CacheModel
{
    public DateTime CacheTimeOutInfo { get; set; }//cache'in ne zaman timeout olacağını belirten time bilgisi
    public object CacheData { get; set; }//cache'de tutulacak object
}

Şimdi ise CacheManager'a implement edeceğimiz ICache interface'i tanımlayalım ve içerisine cache metotlarımızı yazalım.

public interface ICache
{
   bool Contains(string key);//key varmı yokmu diye control ettiğimiz metot
   void Add(string key, CacheModel cacheData);//cache key'i ile birlikte cache model'i alıp cache'e ekleyen metot
   object Get(string key);//key parametresi alarak cache'de ki data yı return eden metot
   void Remove(string key);//key parametresine göre mevcut cache'i silen metot
   void RemoveAll();//bütün cache'i silen metot
}

Aşağıda yazacağımız class'ta ise üstte yazdığımız ICache'i implement eden cache yönetimini yapacağımız CacheManager class'ını oluşturacağızz.

    public class CacheManager : ICache
    {
        public bool Contains(string key)
        {
            var isExist = HttpRuntime.Cache[key];
            if (isExist != null)
            {
                var obj = GetCacheModel(key);
                if (obj.CacheTimeOutInfo > DateTime.Now)
                    return true;
                Remove(key);
            }
            return false;
        }

        public void Add(string key, CacheModel cacheData)
        {
            if (Contains(key))
                Remove(key);
            HttpRuntime.Cache[key] = cacheData;
        }

        public object Get(string key)
        {
            var obj = GetCacheModel(key);
            return obj.CacheData;
        }

        private CacheModel GetCacheModel(string key)
        {
            return (CacheModel)HttpRuntime.Cache[key];
        }

        public void Remove(string key)
        {
            HttpRuntime.Cache.Remove(key);
        }

        public void RemoveAll()
        {
            var enumerator = HttpRuntime.Cache.GetEnumerator();
            while (enumerator.MoveNext())
            {
                HttpContext.Current.Cache.Remove((string)enumerator.Key);
            }
        }
    }

Sırada Postsharp kullanarak oluşturacağmız CacheAspect adında interceptor'ı yazama var. Bunun için nuget'ten postsharp'ı indiriyoruz ve aşağıdaki gibi CacheAspect adındaki interceptor'ımızı oluşturuyoruz.

    [Serializable]
    public class CacheAspect : OnMethodBoundaryAspect
    {
        //Metottan alacağımız cache süresi
        public int MethodCacheDurationInMinute = 0;

        public override void OnEntry(MethodExecutionArgs args)
        {
                 //cache key oluşturma
                var cacheKey = CreateMD5(GenerateCacheKey(args));

                var cacheManager = new CacheManager();

                var isCacheKeyExist = cacheManager.Contains(cacheKey);

                if (isCacheKeyExist)
                { 
                    //eğer request geldiğinde cache key cache de varsa client'a cahe de bulunan veriyi dön
                    args.ReturnValue = cacheManager.Get(cacheKey);
                    args.FlowBehavior = FlowBehavior.Return;
                }
                else
                {
                    //cache de yoksa normal akışta ilerlemesine devam eder
                    args.MethodExecutionTag = cacheKey;
                }
        }

        public override void OnSuccess(MethodExecutionArgs args)
        {
                //başarılı bir şekilde metottan çıktıysa cache'e at

                    var cacheKey = (string)args.MethodExecutionTag;

                    var cacheManager = new CacheManager();
                    var cacheModel = new CacheModel
                    {
                        CacheData = args.ReturnValue,
                        CacheTimeOutInfo = DateTime.Now.AddMinutes(MethodCacheDurationInMinute)
                    };
                    cacheManager.Add(cacheKey, cacheModel);
        }

        private static string GenerateCacheKey(MethodExecutionArgs args)
        {
            var generatedKey = string.Empty;

            if (args.Method.DeclaringType != null)
                generatedKey = args.Method.DeclaringType.Name + "-" + args.Method.Name + (args.Arguments.Any() ? "-" + args.Arguments.Aggregate((first, second) => first + "-" + second) : "");
            generatedKey += SerializeObjectToJson(args.Arguments);

            return generatedKey;
        }

        public static string CreateMD5(string input)
        {
            using (var md5 = System.Security.Cryptography.MD5.Create())
            {
                var inputBytes = Encoding.ASCII.GetBytes(input);
                var hashBytes = md5.ComputeHash(inputBytes);

                var sb = new StringBuilder();
                foreach (var t in hashBytes)
                {
                    sb.Append(t.ToString("X2"));
                }
                return sb.ToString();
            }
        }
    }

Artık sıra cache'i projemizde kullanmaya geldi. yazdığımız interceptor'ı projede hangi metodu cache'e atmak istiyorsak metodun başına attribute olarak ekleyip kaç dakikalık cache'de tutacağını belirteceğiz.

        [CacheAspect(MethodCacheDurationInMinute = 120)] //120 dakikalığına cachelemesini söylüyoruz
        public List<FooModel> Foo(FooRequest reqModel)
        {
            var fooManager=new FooManager();
            return fooManager.GetFooList();
        }

 

Kullanım olarak oldukç basit ve projede hangi metotta istersek aynı yukarıda olduğu gibi attribute olarak projemize ekleyebiliriz. Yazının başında da belirttiğim gibi cache bir çok zaman hayat kurtarır ve yabana atılmaması gereken bir konudur.

 

Builder Design Pattern

Design pattern'leri spagetti kodlara veya tekrar eden kod bloklarına çözümler olarak ortaya çıkmışlardı. Builder Design Pattern creational patterns kategorisi altında bulunan patternlerden birisidir ve kısaca basit objeler kullanarak complex objeler inşa etmede kullanılır diyebiliriz. 

 

Builder'ı DTO yani data transfer object class'larını örnek olarak düşünürsek, bu objeler birden fazla objenin birleşmesinden oluşurlar ve genelde complex objelerdir. Builder pattern'nini de base'de bir obje var ve bu objeye ait alt property'leri oluştururken her bir özellik için ayrı build metotları yazmamız gerekir. Builder design pattern'i bu gibi durumlarda kullanabilecegimiz bir pattern olarak dusunebiliriz. Başka bir deyişle; runtime da yaratılması gereken complex objelerinizin olduğu bir projeniz varsa bu pattern'i kullanmak güzel bir seçim olabilir veya adım adım obje yaratma işlemlerini yönetmek istediğiniz bir durum var ise yine bu pattern'i kullanabiliriz.

Builder pattern'i 4 ana yapıdan oluşur;

  • Product  : Build edilen obje,
  • Builder   : Product'ı build eden abstract yapı,
  • Concrete Builder : Builder nesnesinin abstract yapıyı kullanarak aynı yapıdaki farklı ürünlerin build edilmesini sağlayan yapı,
  • Director  : Kendisine verilen Builder'ı property'lerini kullanarak ürünü inşa eden yapı.

Örnek bir proje üzerinden Builder Design Pattern'i implement etmeye çalışalım. Apple fabrikasında Iphone modelleri üretimi yapan bir senaryo yazalım ve bunu pattern'imizi uygulayarak yapmaya çalışalım.

Öncelikle ürün class'ımızı oluşturalım. Iphone'un farklı modellerini (6, 6S, SE, vs.) ürettiğimizi düşünelim ve constractor seviyesinde hangi modeli ürettiğimiz bilgisini verelim.

    //Product'ımız   
    public class Iphone
    {
        string phoneType;
        public Iphone(string phoneType)
        {
            this.phoneType = phoneType;
        }
    }

Şimdi ise Builder gibi davranan abstract class'ımızı oluşturalım. Bu class üretimde kullanacağımız abstract üyeler içerecektir. Icerisinde BuildOS ve BuildDevice adında iki abstract metot ve hangi iphone modelini üreteceği bilgisinin olacağı Iphone tipinde olan obje olacaktır.

    //abstract Builder nesnemiz   
    public abstract class IphoneBuilder
    {
        public abstract void BuildOS();

        public abstract void BuildDevice();

        Iphone IphoneType { get; }
    }

Sırada Builder class'larını geliştirme var. 6sBuilder ve SeBuilder adında iki tane iphone modeli için geliştirme yapalım.

SeBuilder

    // SE modeli için kullanacağımız Concrete Builder class'ımız
    public class SeBuilder : IphoneBuilder
    {
        Iphone device;

        public SeBuilder()
        {
            device = new Iphone("Se");
        }

        public override void BuildOS()
        {
            //TODO
        }

        public override void BuildDevice()
        {
            //TODO
        }

        public Iphone IphoneType
        {
            get { return device; }
        }
    }

_6sBuilder

   // 6S modeli için kullanacağımız Concrete Builder class'ımız
   public class _6SBuilder : IphoneBuilder
    {
        Iphone device;

        public _6SBuilder()
        {
            device = new Iphone("6S");
        }

        public override void BuildOS()
        {
            //TODO
        }

        public override void BuildDevice()
        {
            //TODO
        }

        public Iphone IphoneType
        {
            get { return device; }
        }
    }

Şimdi sırada üretim var. Manufacturer adında üretici class'ımızı oluşturalım.

   //Director class'ımız
   public class Manufacturer
    {
        public void Build(IphoneBuilder iphoneBuilder)
        {
            iphoneBuilder.BuildDevice();

            iphoneBuilder.BuildOS();
        }
    }

Sıra yaptığımız implementasyonu kullanmaya geldi. 

	public static void Main()
	{
		 Manufacturer manufacturer = new Manufacturer();

         _6SBuilder _6s = new _6SBuilder();

         manufacturer.Build(_6s);
	}

Main fonksiyon içerisinde Manufacturer'ı kullanarak _6s modelini build ettik. Builder pattern'nini elimizden geldiğince projemize entegre ettik ve diğer iphone ürünleri için de aynı akışı kullanarak ürünlerimizi Build edebiliriz.

Builder pattern'i factory ve abstract factory pattern'leri ile birçok yönden benzerlikler göstermektedir. Hangisini kullanmalıyım diye tereddütte kaldığınız durumlarda, complex objeler yaratıyorsanız Builder'ı, tek bir obje yaratmak istiyorsanız da factory veya abstract factory design pattern'i tercih edebilirsiniz.

SOLID Yazılım Süreçlerini Yavaşlatıyor Mu ?

Geçtiğimiz haftalarda  SOLID yazı serisini sonlandırdık ve sırasıyla

konularından bahsettik.

İlk defa SOLID'i araştırırken bir çok blog yazlım forum sitesi vs. dolaştım ve yapılan yorumları okuma fırsatım olmuştu. Bu yorumlardan en çok yaygın olanı kabaca şöyle bir şey "ya tamamda ne gerek var bunca şeye ?.. SOLID hem beni hemde yazdığım kodu yavaşlatıyor..." vs. şeklinde yorumlar yapılmıştı. Doğrusu en başlarda bende buna benzer cümleler kurmadım değil :)

SOLID prensiplerinin asıl amacı Separation of Concerns veya türkçe deyimiyle farklı kavramların, işlerin birbirinden ayrılması ilkesini High Cohesion & Low Coupling yoluyla geliştirmek. Prensipleri anlattığımız ilk yazıda şuna benzer bir cümle kullanmıştım "asıl amaç sonradan kolay müdahale edilebilir, yeni modüllerin kolay entegre edilebildiği core code'a çok fazla dokunmadan yazılımlar geliştirmek..." ve aslında bu cümle 5 temel prensiple bizlere anlatılıyor. İlk bakışta bu prensiplerin uygulaması zahmetli gibi geliyor olabilir ancak bunu ileriye dönük iyi bir yatırım olarak görmeliyiz ve yazılım geliştirme sürecini while(true) {develop}şeklinde sonsuz bir döngü olarak bakmalıyız.

SOLID prensiplerine uyalım derken bazı istenmeyen sonuçlarortaya çıkarmamızda mümkün;

  • Çok fazla abstraction ve interface,
  • İstenmeyen Concrete class'lar,
  • Gerektiğidnen fazla layer oluşabilme itimali,
  • Kalıtım ağacıdnaki derinliği gereknden fazla artırma,
  • Yo-yo problemi,
  • vs...

SOLID prensiplerinin gelişi güzel uygulanması bu ve benzeri durumların olmasına neden oalbilir ancak geliştirme yaparken arada bir geriye gelip geniş açıdan bakmakta fayda var çünkü bazen oop nin dibine vurmaya çalışırken farkında olmadan saçmalamışta olabiliriz :) . Tabi burda da devreye iyi deneyime sahip, çeşitli projelerde görev almış vizyon sahibi bir takım liderine gerek var ki code-review sırasında nokta atışı yaparak yanlış veya gereksiz olan yerleri saptayıp düzeltebilme fırsatınız olsun.

SOLID yazılım süreçlerini yavaşlatıyor mu ? sorusuna geri dönecek olursak, yukarıda da bahsettiğimiz üzre çok separation of concern'ü düşünerek yapacağımız işleri çoklu katmanalra ayırarak böyle bir duruma sebebiyet verme ihtimalimiz azda olsa var. Diğer bir deyişle tek bir metot çağrısı yaparak çözebileceğimiz bir sorunu birden fazla instance alarak metot çağrısı yapmaya zorlandığımız durumlar ortaya çıkabilir ve bu da geliştirme süresini uzatabilir. Ancak SOLID prensiplerini hangi projeye uygulanması gerektiğine karar vermekte bir o kadar önemli çünkü small diyebileceğimiz projeler için dibine kadar SOLID kastırmak çokta şart değildir hani. Bunun yerine enterprise veya işlevselliği çok olan büüyk projerlerde SOLID prensiplerini uygulamaya çalışmalıyız ve unutmamalıyız ki SOLID'e uygun geliştirmeler yaparak günü kurtarmıyoruz bunu ileriye dönük bir yatırım olarak görmeliyiz ve asıl faydalarını projenin ilerleyen fazlarında görüyor olacağız.

Ben kendi projelerimde nasıl ilerliyorum diye soracak olursak, mümkün olduğunda separation of concern'e odaklanmaya çalışıyorum ve ona uygun ilerleyecek sade-temiz bir design pattern seçmeye çalışırım. Çok fazla abstraction'dan dolayı performans sorunları olacağını düşündüğüm yerler varsa da yaygın kullanılan bir runtime performans tool'u kullanarak testler yapıp sorunu saptamaya odaklanırım.

 

Sonuç olarak SOLID yazılım süreçlerini yavaşlatıyor mu sorusuna bence en uygun cevap, SOLID'i ne kadar doğru zamanda doğru yerde kullandığınızla ilgili. Eğer prensiplere tamamiyle hakimseniz ve doğru projede uyguladığınızı düşünüyorsanız kesinlikle yazılım süreçlerini yavaşlatmıyor aksine hızlandırıyor. Şuan için farkında olmasanız bile ileriye dönük size birçok katkı sağlayacağı noktalar olacaktır. Eğer çok gereksiz bir projede hiç ihtiyaç yokken SOLID'in dibine vurmakta tavsiye edilen bir durum olmayacaktır, çok büyük bir ihtimalle geliştirme sırasında gereksiz zaman kaybına yol açacaktır.

Repository Design Pattern

Çoğu yazılım uygulamasının belli mimari kurallar çerçevisinde farklı katmanlara ayrılarak geliştirilmesi beklenir ve buna n-tier architecture denir. N-tier architecture presentation tier, middle tier yada data tier gibi çeşitli katmanlardan oluşabilir. Presentation katmanında uygulamanızın UI tarafını ilgilendiren arayüzler bulunur, Middle katmanda business logic'i ilgilendiren geliştirmeler yapılır ve aynı zamanda database ile etkileşimde bu katmanda bulunur. Data katmanı ise uygulamanızdaki SQL Server, Oracle gibi database context'lerini içeren katmandır. Bu katman belkide uygulamadaki en önemli katmandır sebebi ise database. Data bizim için en önemli şey ve database'ler ile olan veri alış verişi işin en güvenlikli ve generic olması gereken yerlerin başında gelir.

Database varsa CRUD işlemi (Create, Read, Update, Delete) heralde olmazsa olmazdır ve data katmanı ile doğrudan business logic'in bulunduğu middle katman haberleşsin istenilmez ve bu durum bazen uygulamanızın büyüklüğüne göre çeşitli sorunlarda çıkartabilir. Repository pattern bu ihtiyacı karşılayan pattern olarak karşımıza çıkıyor ve temelde yaptığı iş ise business logic ile data access arasında arabulucu görevi görme.

Repository Pattern Faydaları

  • Maintainability (sonradan bakım kolaylılığı) arttırır,
  • Unit-test yapabilmemizi kolaylaştırır,
  • Esnek bir mimari uygulamamızı sağlar,
  • Yeni gelecek modüller veya istenilen değişiklikleri kolayca entegre edebilmeyi sağlar,
  • Domain driven development'ın önünü açar.

 

Repository Pattern Uygulaması

Şimdi örnek bir proje üzerinden Repository Pattern nasıl uygulanır görelim. Projeyi geliştirirken projenizde EntityFramework kurulu ve SampleDbContext adında bir database context'inizin olduğunu varsayarak ilerliyor olacağız.

1.Adım - IRepository adında CRUD işlemleri yapabilmemizi sağlayacak Generic bir interface metodlarını tanımlama.

public interface IRepository<T>  where T : class
    {
        IEnumerable<t> SelectAll();
        T SelectByID(object id);
        void Insert(T obj);
        void Update(T obj);
        void Delete(object id);
        void Save();
    }

2.Adım - BaseRepository adında Generic IRepository interface'inden implement olan class'ı oluşturma.

public abstract class BaseRepository<T> : IRepository<T> where T : class
    {
        private SampleDbContext db = null;
        private DbSet<t> table = null;
        public BaseRepository()
        {
            this.db = new SampleDbContext();
            table = db.Set<T>();
        }
        public BaseRepository(SampleDbContext db)
        {
            this.db = db;
            table = db.Set<T>();
        }
        public IEnumerable<T> SelectAll()
        {
            return table.ToList();
        }
        public T SelectByID(object id)
        {
            return table.Find(id);
        }
        public void Insert(T obj)
        {
            table.Add(obj);
        }
        public void Update(T obj)
        {
            table.Attach(obj);
            db.Entry(obj).State = EntityState.Modified;
        }
        public void Delete(object id)
        {
            T existing = table.Find(id);
            table.Remove(existing);
        }
        public void Save()
        {
            db.SaveChanges();
        }
    }

3.Adım - Employee adında örnek bir Entity tanımlama

public class Employee
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

 

4.Adım - BaseRepository den inherit olan Employee entity si için EmployeeRepository class'ını tanımlama

  public class EmployeeRepository : BaseRepository<Employee>
    {

    }

5.Adım - Yazmış olduğumuz EmployeeRepository'yi kullanmak

  void Main(string[] args)
        {
            var empRepository = new EmployeeRepository();
            empRepository.SelectAll();
        }

Projemiz hazır. Bundan sonra tanımlayacağınız entity'ler için EmployeeRepository de olduğu gibi Generic olarak yazmış olduğumuz BaseRepository'den türeyen Repository'ler tanımlayarak projeyi geliştirmeye devam edebiliriz.

Not : Bir rivayete göre Repository Design Pattern, Design Pattern ailesi içerisinde en çok kullanılan pattern olduğu söylenir.

 

PostSharp Kullanarak Metot Parametre Null Kontrolü

Daha önceki Aspect Oriented Programming'den ve Postsharp tool'undan bahsetmiştik. Postsharp ile Log, Exception Handling ve metot bazlı Authentication kontrolü gibi işlemleri yapabildiğimizden bahsetmiştik. Bu yazımızda ise Postsharp kullanarak metot bazlı parametre kontrolü (null mı değil i vs. gibi) nasıl yapabiliriz inceleyeceğiz.

Server side geliştirmesi yapmış arkadaşlar bilirlerki metotlarda gelen objeler için validation kontrolü yapmak bazen bizi çok yorabilir veya tahmin ettiğimizden daha fazla zaman aldırabilir. Postsharp ın OnEntry() metodunu kullarak gelen parametler için null mı değil mi diye kolayca kontrol edebiliriz.

Bunun için ilk olarak NullParamsControllingAspect adında OnMethodBoundaryAspect ten inherit olan class'ı oluşturalım ve içeriği aşağıdaki gibi olacaktır. Metoda yollanan null parametleri tespit edip string message olarak client'a ArgumentException fıraltarak bilgilendirme mesajını dönecektir.

[Serializable]
    public class NullParameterControllerAspect: OnMethodBoundaryAspect
    {
        public override void OnEntry(MethodExecutionArgs args)
        {
            var messages = new StringBuilder();

            for (int i = 0; i < args.Arguments.Count; i++)
            {
                if (args.Arguments.GetArgument(i) == null)
                {
                    messages.AppendFormat(args.Method.Name +" metodunda bulunan \"{0}\" parametresi null olamaz.\n", args.Method.GetParameters()[i].Name);
                }
            }

            Console.WriteLine(messages);

            if (messages.Length > 0)
            {
                throw new ArgumentException(messages.ToString());
            }
        }

Yukarıda görüldüğü gibi OnEntry() metodunda gelen parametreyi alıp null mı diye kontrol ediyoruz.

Test için aşağıdaki gibi Prgram.cs class'ını oluşturalım. TransferRequest adında bir class'ımız olsun ve bu class'ı null set ederek ve MoneyTransfer metodunu çağıralım.

 class Program
    {
        static void Main(string[] args)
        {
            TransferRequest req_null = null;
            MoneyTransfer(req_null, "Test");//null obje kullanarak metot çağırımı
        }

        [NullParameterControllerAspect]
        public static void MoneyTransfer(TransferRequest request, string param)
        {
            //transfer işlemleri
        }

        public class TransferRequest
        {
            public decimal Amount { get; set; }
            public string SenderIBAN { get; set; }
            public string ReceiverIBAN { get; set; }
        }
    }

 Projenizi çalıştırdığınızda ekran çıktısı aşağıdaki gibi olacaktır.