Konu: Entity Framework ile Gerçek Hayat Örnekleri-1
Tarih: 12 Aralık 2011 Pazartesi – 21:00
Link: https://www.livemeeting.com/cc/mvp/join?id=Z3THGT&role=attend
Konuşmacı: Burak Selim ŞENYURT

Konu: Entity Framework ile Gerçek Hayat Örnekleri-2
Tarih: 13 Aralık 2011 Salı – 21:00
Link: https://www.livemeeting.com/cc/mvp/join?id=8FPTD6&role=attend
Konuşmacı: Burak Selim ŞENYURT

Konu: CRM 2011 Programlama Teknikleri
Tarih: 19 Aralık 2011 Pazartesi – 21:00
Link: https://www.livemeeting.com/cc/mvp/join?id=9N5553&role=attend
Konuşmacı: Barış KANLICA

Konu: Cambaz Debugger – C# Uygulamalarında Hata Ayıklama
Tarih: 24 Aralık 2011 Cumartesi – 21:00
Link: https://www.livemeeting.com/cc/mvp/join?id=SP7FZ9&role=attend&pw=5%2BK7Hd5cW
Konuşmacı: Fatih BOY

Konu: C#’ın Geleceğine Bir Bakış
Tarih: 26 Aralık 2011 Pazartesi – 21:00
Link: https://www.livemeeting.com/cc/mvp/join?id=NJD5T2&role=attend&pw=3%229Z%3CTp%2CW
Konuşmacı: Fatih BOY

Kısaca benim neler en çok hoşuma gitti onlardan bahsetmek isterim, belki daha cazip gelir bu haber bu sayede (:

Benim en çok hoşuma giden yenilik MEF Part’larını belirtmek için kullandığımız attribute’ları yeni gelen RegistrationBuilder ile sayesinde farklı bir şekilde belirtebiliyor olmamız. Mesela belli bir sınıfta belirtilen Part’larımızdan türüyen export edilecek diğer sınıflarımız için [Export] attribute’unu tanımlamak gerekmekteydi. Hem kendini tekrarlayan bir yapı oluşmasıns sebep olan hem de bazen unutulabilen ve  runtime’da fark edilebilen bir durum oluyordu. Yeni gelen RegistrationBuilder ile aşağıdaki gibi Export edilecek Part’larımı daha kolay ve anlaşılır bir şekilde tanımlayabiliyoruz.

 //ForTypesDerivedFrom() metodu ile BaseModule gibi kendi sınıfımızdan
 //türümiş tüm objelerin export edilebileceğini söylüyoruz.
 var builder = new RegistrationBuilder();
 builder.ForTypesDerivedFrom().Export();

//MEF kataloglarına da RegistrationBuilder objemizi verebiliyoruz
 var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly(), builder);
 

Generic olan sınıfları artık Export edebiliyoruz. Yani IGenericType<T> gibi bir arayüzümüz olduğunda ve bundan türeyen sınıflarımızı Export etmek istediğimiz de [Export(IGenericType<>)] şeklinde attribute’u güncellemek yeterli olacak.

Ayrıca Exception mesajlarında ki iyileştirmeler de Run-time’da alınan hataları biraz daha açıklayıcı hala getiriyor. Bu da hata tespiti için çok can kurtaracak.

Bu arada MEF 2.0 versiyonu, .NET Framework 4.5′ün içinde de geliyor olacak. Ama tabi ondan önce çıkar mı bilemiyorum…Çıkarsa ne ala…Neyse şimdilik bu kadar…

IObservable<T> ve IObserver<T> yeni gelen arayüzlerimizden…Bu arayüzler “push-based notifications” diye literatürde yer alan sistemler oluşturmamız için faydalanabileceğimiz arayüzler. “push-based notifications” nedir ile başlasak sanırım daha kolay olacak bazı şeyler. Artık bir çok kişinin kullandığı sosyal paylaşım sitelerinden örnekler verebiliriz daha iyi anlamak için. Facebook’da örneğin, sayfa ile her hangi bir etkileşim olmadan zaman zaman sağdan soldan “1 tane mesajınız var”, “X kişisi Y’nin fotoğrafını beğendi” gibi bildirimler alıyoruz. Bu tarz bildirimlere “push-based notifications” diyoruz. Türkçeleştirmek için kasamadım açıkcası ama basitçe bir nesnenin, kendisine bağlanan ya da üye olan parçalara bildirimler göndererek, kendinde olan değişimleri bildirmesi olarak açıklayabiliriz. Gözlemci ve gözlenen olarak düşünürsek biraz daha netleşebilir sanırım. Bütün bu kavramlar aslında mevcut event yaklaşımı ile üstü kapalı olarak bize sunulmakta tüm yazılım geliştirme dillerinde. Ayrıca “Observer” tasarım kalıbı şeklinde de literatürde yerini uzun süredir korumakta.

IObservable ve IObserver arayüzleri de bu tasarım kalıbının .NET Framework’de ki yansıması. Peki neden yeni olarak .NET Framework 4.0 ile geldi ya da mevcut event yapısı zaten bu kavramları karşılamıyor mu sorularını sorabilirsiniz…Gelişen ihtiyaçlar ve kullanıcı eğilimlerinden dolayı asenkron çağrılar ve dağınık olay bazlı(distrubted events) yaklaşımları kendi sistemlerimizde, kendimize özgün yöntemler ile kullanmamız gerekebiliyor. Bundan dolayı bu iki arayüz ile daha kontrollü bir şekilde kendi “push-based notification” tarzı uygulamalarımızı .NET Framework ile daha kolay geliştirebiliyoruz. Bir örnek ile devam edip biraz daha netleştirelim.Yabacağımız örnek basit bir konsol uygulaması olup, doların yükselişini simule eden ve bu yükselişi takip eden bir uygulama olacak. Oldukça basit…Yine standart olarak kod üzerinden açıklamalar ile anlatmaya çalışacağım. O zaman başlıyoruz…

    //IObservable arayüzünden gözlemnecek nesnemizin sınıfı yaratıyoruz.
    //T tipindeki nesne yarattığımız nesne ya da daha temel bir nesne olabilir.
    //IObservable arayüzünden türüyen sınıf, arayüzden gelen Subscribe()
    //metodunu tanımlamak durumda. Bu metod ile bu nesnemizi gözleyecek
    //nesneleri tanımlıyoruz.
    public class Dolar : IObservable
    {
        //Nesnemizi birden fazla gözlemci gözleyebileceği için
        //List tipinde bir nesne ile gözlemcileri saklayabileceğimiz
        //bir koleksiyon tanımlıyoruz.
        private List> _subscribers;
        private int _amount;

        public Dolar()
        {
            _subscribers = new List>();
        }

        public int Amount
        {
            get
            {
                return _amount;
            }
            set
            {
                _amount = value;
                //Nesnemizde oluşacak değişiklikleri gözlemcilere,
                //gözlemcilerin(-ki bunlar IObserver arayüzünden
                //yaratılan sınıflar) OnNext() metodu ile bildiriyoruz.
                foreach (var item in _subscribers)
                {
                    item.OnNext(this);
                }
            }
        }

        //Subscribe metodu IObservable arayüzünden gelen bir metod.
        //Bu metod ile nesnemizi gözlemleyecek diğer nesneleri belirtebiliyoruz.
        //Bir başka deyişle nesnemize abone olacak ve onun değişikliklerinden
        //etkilenecek olan nesneleri alıyoruz.
        //IDisposable tipinde bir dönüş değeri olmasının sebebi, gözlemcilerin
        //gerektiği zaman aboneliklerini iptal ettirebilmelerini sağlıyor.
        //Bu örnekte bu konuya değinmedim.Belki ileride
        public IDisposable Subscribe(IObserver observer)
        {
            if (!_subscribers.Contains(observer))
                _subscribers.Add(observer);

            return null;
        }
    }

Gözlenecek nesnemizin sınıfı oluşturduktan sonra, bu nesne üzerindeki değişiklikleri takip ve kontrol edeceğimiz, gözlemci nesnelerimizin sınıflarını aşağıdaki gibi yazabiliriz.

    //Aşağıdaki örnek sınıfta, IObserver arayüzünden yarattığımız nesne
    //CurrencyTracker nesnesi, Dolar tipinde ki nesneleri gözlemleyecek.
    //IObserver arayüzünden gelen 3 tane zorunlu metod var.
    //OnNext() metodu ile değişen datayı gözlemciye bildiriyoruz,
    //OnError() metodu ile hata oluştuğu durumları gözlemciye bildirebiliyoruz,
    //OnCompleted() metodu ile de bildirimlerin tamamlandığı bilgisini verebiliyoruz.
    public class CurrencyTracker : IObserver
    {
        public CurrencyTracker()
        {

        }

        public void OnCompleted()
        {
            Console.WriteLine("İşlem Tamamlandı");
        }

        public void OnError(Exception error)
        {
            Console.WriteLine("Hata oluştu");
        }

        public void OnNext(Dolar value)
        {
            Console.WriteLine("Dolar'ın değeri:{0} ",value.Amount);
        }
    }

    //Bu örnek için, yukardaki diğer gözlemciye benzeyen başka bir
    //gözlemci, aynı mantıkla çalışmakta.Ek olarak OnNext() metodunda
    //gelen veri değerini kontrol ediyor.
    public class LimitTracker : IObserver
    {

        public LimitTracker()
        {

        }

        public void OnCompleted()
        {
            Console.WriteLine("İşlem Tamamlandı");

        }

        public void OnError(Exception error)
        {
            Console.WriteLine("Hata oluştu");
        }

        public void OnNext(Dolar value)
        {
            if(value.Amount>70)
                Console.WriteLine("Dolar'ın değeri çok yüksek: {0} .Kriz olabilir.", value.Amount);
        }
    }

Son olarak ise yazdığımız kodların nasıl çalıştığını görmek adına aşağıdaki gibi basit bir konsol uygulaması yazıyoruz.

    class Program
    {
        static void Main(string[] args)
        {

            Dolar d = new Dolar();
            CurrencyTracker ct = new CurrencyTracker();
            LimitTracker lt = new LimitTracker();

            //Dolar nesnemize abone oluyoruz ve gözlemlemeye başlıyoruz
            d.Subscribe(lt);
            d.Subscribe(ct);

            //1000 milisaniye de bir Dolar tipindeki nesnemizin Amount değerini
            //değiştiriyoruz.
            Timer t = new Timer((s) =>
            {
                d.Amount = new Random().Next(100);
            }, null, TimeSpan.FromMilliseconds(1), TimeSpan.FromMilliseconds(1000));

            Console.ReadLine();
        }
    }

Örnek uygulamamızın çıktısı da aşağıdaki gibi olacaktır…

Şimdilik bu kadar…Oldukça basit bir örnekle .NET 4.0 ile gelen IObserverve IObservableaçıklamaya çalıştım, umarım biraz olsun faydası olur.

Örnek projeyi buradan indirebilirsiniz…

CTP versiyonu bu adresten indirebilirsiniz…

Performans, yazılımın kalitesini etkileyecek bir etken olabiliyor bazen. Belki ilk geliştirme aşamasında değil ama sonradan kalitesini direk belirleyen bir faktör olabiliyor. Bundan dolayı geliştirme aşamasında uygulamamızın performansını nasıl kontrol eder ve gözlemleriz bunu örneklendirmeye çalışacağım. Tabi ki bunu Visual Studio 2010 ile yapıyor olacağız…

Öncelikle çok basit bir konsol uygulaması yapalım. Performansını gözlemleyeceğimiz uygula olarak bu uygulamayı düşünebiliriz.

    public class DummyClass
    {

        public void DoSomething()
        {
            string s = "";

            for (int i = 0; i < 10000; i++)
            {
                s += "Performance test:" + i;
                s += "\r\n";
            }
            Console.WriteLine(s);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            DummyClass dummy = new DummyClass();
            dummy.DoSomething();

            Console.ReadLine();

        }
    }

Fark etmiş olduğunuz üzere çok komplike bir yapı yok…10.000 kere çalışan bir döngü içerisinde bir string değişkenine değer atıyoruz…Şimdi bu yazdığımız kodun performansını gözlemleyelim. Bunun için Visual Studio’nun Analyze menüsünden Launch Performance Wizard… seçeneğini seçmemiz gerekte.

Bu seçeneği seçtikten sonra çeşitli performans ölçümleri için seçenekler karşımıza çıkacaktır.

• CPU Sampling: Uygulamanın işlemci üzerinde ne kadar yük oluşturduğunu ölçmek adına bu seçeneği kullanabiliriz.
• Instrumentation: Uygulamanın içerisinde ki metodlar kaç kere çağrılmış ve bir metodun işlemini ne kadar sürede yapmış gibi bilgileri gözlemlemek için bu seçeneği seçebiliriz.
• .NET Memory Allocation: Uygulamanın bellek kullanımı ile ilgili performansını gözlemlemek için seçeceğimiz seçenek de bu seçenek olmalı.
• Concurrency: Eğer multi-thread bir uygulamamız var ise thread’lar arasında ki ilişkileri bu seçenek ile gözlemleyebiliriz.

Bu yazı için CPU Sampling seçeneğini seçip Next diyoruz…Daha sonra aşağıdaki gibi bir ekran ile performans analizi yapacağımız projeyi ya da uygulamayı seçmemiz gerekiyor. Açık projeler var ise onlar listede çıkıyor olacaktır.

Projemizi seçip yine Next diyoruz. Bir sonra ki ekranda artık performans analizini çalıştırmak için son adımı tamamlıyoruz,yani bu ekranları kapattıktan sonra analiz operasyonunu başlat seçeneğini seçiyoruz. Eğer analizi daha sonra çalıştırmak istersek bu seçeneği seçmeyip, direk Finish diyebiliriz.

Finish dedikten sonra uygulamamız kendiliğinden çalışacaktır. Ve arka tarafta analiz işlemi de uygulamamız ile paralel çalışıyor olacaktır.

Uygulamamızı kapattıktan sonra performans analizide tamamlanmış olacaktır. Tabi ki kapatmadan önce uygulamamızda ne yapmak istiyorsak, o operasyonları yapmamız daha mantıklı veriler içeren bir analiz raporu oluşmasını sağlar. Aşağıdaki gibi bir rapor analiz sonunca karşımıza çıkacaktır.

Bu rapor ile uygulamızda performans adına ne gibi iyileştirmeler yapabiliriz bunları tespit etmek mümkün. Raporda ilgili metodlara tıklarsak bu metodların içerisinde, kodun hangi satırında, hangi metod kaynak kullanmış bu bilgiye de ulaşabiliyoruz.

Basit bir örnek oldu gerçi ama umarım bir uygulamanın performansını Visual Studio ile nasıl gözlemleyebiliriz sorusuna biraz olsun cevap vermiştir. Ama daha bitmedi…(:

Bu basit performans analizinden sonra, sorunu görebilmiş olduk. Bildiğiniz üzere string tipindeki değişkenlere bu şekilde bir döngü içerisinde değer atamak hem bellek hemde işlemci açısından oldukça maliyetlidir. Şimdi isterseniz bunu düzeltip raporumuza tekrar göz atalım. Ama bunun için öncelikle bu raporu kaydetmemiz lazım. Daha sonra aşağıda ki gibi kodumuzu değiştirdikten sonra raporumuzu tekrar çalıştırıyoruz aynı şekilde…

    public class DummyClass
    {

        public void DoSomething()
        {
            //string s = "";
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < 10000; i++)
            {
                //s += "Performance test:" + i;
                //s += "\r\n";
                sb.Append("Performance test:" + i);
                sb.Append("\r\n");
            }
            //Console.WriteLine(s);
            Console.WriteLine(sb.ToString());
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            DummyClass dummy = new DummyClass();
            dummy.DoSomething();

            Console.ReadLine();

        }
    }

Yukarıdaki düzeltmeden sonra raporumuz aşağıdaki gibi olacaktır. Dikkat edersiniz ki işlemci açısından ilk rapordaki gibi bir durum söz konusu değil. string değişkeni yerine StringBuilder sınıfını kullanarak işlemci yükünü azaltmış olduk. Burada Console.WriteLine() metodunda %100 gibi bir değerin olması sizi şaşırtmasın. Normal bir değer bu. Uygulama işlemci açısından konsola yazdırmak için kullanmış tüm gücünü. Bu da aslında gayet normal…Bu noktada bu raporlarda toplam değerin mutlaka %100 olacağını belirtmekte fayda var.

Bir önceki rapor ile bu son raporu bir biri ile karşılaştırmakta mümkün. Rapor ekranından Compare Reports… seçeneği ile bir önceki raporu seçtiğinizde iki rapor arasında ki gelişmeyi görebilirsiniz.

Bu tarz performans kontrollerini uygulama geliştirme aşamasında sık sık yapmakta fayda olacağına inanmaktayım. Bu şekilde uygulama tamamlanmadan önce performans sorunlarını tespit etmek çok daha kolay olacaktır.

Şimdilik bu kadar, bir sonra ki yazıda görüşmek üzere…

1. ‘Aspect Oriented’ programlama mı…Nedir ki?
2. Peki ama neden ‘Aspect Oriented’ programlama…
3. ‘Aspect Oriented’ programlamaya başlıyoruz…Bölüm I

Bu yazıda bir önceki kod alt yapısını üzerinden giderek, AOP kavramında ki Aspect’leri yaratıyor olacağız. Özellikle “Aspect” şeklinde belirtmek istiyorum ki, yarattığımız bazı örnek sınıfları bu şekilde düşünmeye çalışmak, konunun bütününü anlamak adına yardımcı olacaktır. Hatırlarsanız bir önceki yazıda Person diye bir sınıf oluşturmuştuk örnek olarak ve bu sınıfı bir tane konsol uygulamasında kullanarak methodlarını çağırmadan önce nasıl araya girebileceğimize değinmiştim. Yine aynı sınıf üzerinden, onu biraz daha geliştirerek gidiyor olacağız. Bunun için sınıfımızı aşağıdaki gibi yenilememiz yeterli olacaktır şimdilik. Yeni bir özellik ve metod dışında aslında fazla bir şey de yok.

    [Controller]
    public class Person : ContextBoundObject
    {
        private int _age = 0;
        private string _name = "";

        public string Name { get { return _name; } }

        public Person(string name) : base() { _name = name; }

        public int Age
        {

            get
            {
                return _age;
            }
            set
            {
                _age = value;
            }
        }

        public string DoSomething()
        {

            string logMessage = "Person sınıfının DoSomething() methodu çalıştı";
            Console.WriteLine(logMessage);

            return "";
        }
        public void DoAnotherThing(int parameter1, string parameter2)
        {
            Console.WriteLine("Person sınıfının DoAnotherThing() methodu çalıştı");
        }

    }

AOP, yazılımda ki kesişen ilgileri ayırmak için kullanabileceğimiz bir yöntemdi demiştik. Bu ilgiler her yazılım ürününde bir şekilde olan Logging,Exception Handling gibi kavramlar olabileceği gibi, iş kuralları ve bu kuralların işletildiği methodlar da olabilir. Ama genellikle bir biri ile çakışan ilgiler Logging,Exception Handling, Security gibi kavramlar için daha karmaşık olur. Oluşan Exception için uygun kaydı tutmak, ya da bir metod çalıştığında bu metodun çalışmasına dair bazı bilgileri kayıt altına alabilmek bir çok kavramın iç içe girmesine sebep olur. Bu yazıda bu ilgilere biraz daha yer vererek, bu ilgileri AOP yaklaşımı ile nasıl ayırabileceğimizi anlamaya çalışacağız. Örnek olabilecek bir kaç ilgiyi oluşturup, bunu Person sınıfımızda kullanacağız. Bu ilgileri .NET Framework’ünde bulunan Attribute‘lar ile yaratıp, nesnelerimize,metodlarımıza ve nesnelerin özelliklerine bağlayacağız. Aşağıdaki gibi bir kaç nesne, örnek olması adına yeterli olacaktır diye düşünüyorum.

    //Aspect'lerimiz için ortak bir yapı oluşturuyoruz.
    //Bu örnek için oldukça basit bir yapı oluşturmak
    //şimdilik yeterli olacaktır.
    //Attribute sınıfından türeyen bir BaseAspect sınıfı
    //oluşturuyoruz.
    public abstract class BaseAspect : Attribute
    {
        //abstract anahtar kelimesi ile tanımladığımız bu metodu
        //BaseAspect sınıfından türeyen tüm sınıflar yaratmak durumunda.
        //Bu method bu Aspect'in yapmakla yükümlü olduğu metodu simule ediyor
        //olacak...
        public abstract void Process(ref IMethodCallMessage message);
    }

    //Uygulamamızda Log'lama gerektiren yerlerde kullanabileceğimiz bir
    //ilgiyi bu şekilde tanımlayabiliriz.Bu Log'lama için ne yapılması gerekiyorsa
    //kendi içinde yapıyor olacak. BaseAspect sınıfımızdan gelen Process methodunun
    // message parametresinden istediğimiz özellikleri ihtiyacımıza göre alabiliriz.
    //Eğer kendi Log'lama için kullandığımız arayüzler varsa onları message parametresinden
    //çekip kullanmak mümkün.Bu örnekte konsola kayıt mesajı yazdıracağız.
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Method)]
    public class Logger : BaseAspect
    {
        public Logger()
        {

        }

        public override void Process(ref IMethodCallMessage message)
        {
            StringBuilder sb = new StringBuilder();
            if (message.Args != null)
            {
                //Metoddan gelen parametreleri yazdırıyoruz.
                for (int i = 0; i < message.Args.Length; i++)
                {
                    sb.Append(String.Format("{0}={1}\r\n\t\t\t\t",message.GetArgName(i),message.Args[i]));
                }
            }

            Console.WriteLine("##LOG## "+DateTime.Now.ToString()+" - "+ message.MethodName + " methodu çalışacak.\r\n\t\t\t\t" + sb.ToString() );
        }
    }

    //CanDrive adındaki Aspect'imiz aslında bir iş kuralını temsil ediyor
    //Aldığı parametre ile bir yaş sınırı belirlediğimiz bu ilgimiz
    //beraber kullanıldığı parametrenin yaş özelliğini kontrol ediyor.
    //Bu örnekte önemli olan nokta message parametresinden bize lazım olan bir
    //nesneyi kullanabilmemiz. Bu noktada altını çizmek isteyeceğim bir nokta var.
    //CanDrive kuralı kavram olarak hangi nesneler ile ilgili olacaksa bunların çok iyi belirlenmesi
    //gerekmekte. Buna göre içerisinde ki iş kuralı ve metodları dikkatlice yazılmalı.
    //Bu örnekte CanDrive, Person sınıfını kullanıyor. Çünkü CanDrive'ın ilgisi Person ile...
    //İlk yazımda da dediğim gibi AOP'i ilgileri ayırmak ve ayrıca yönetmek içinde kullanabiliriz.
    [AttributeUsage( AttributeTargets.Parameter)]//Sadece parametrelerde kullanabiliriz bu ilgiyi...
    public class CanDrive : BaseAspect
    {
        private int _age;

        public CanDrive(int age)
        {
            _age = age;
        }

        public override void Process(ref IMethodCallMessage message)
        {
            Person p = (Person)message.GetArg(0);
            if (p.Age < _age)                 throw new Exception(String.Format("{0} araba süremez.Yaşı küçük.{1}", p.Name, p.Age));         }     }     //Bu seferde belli yaş aralığını kontrol eden ilgimiz var.     //CanDrive'a kavram olarak benziyor. Ama uygulama konusunda farklılık var.     [AttributeUsage(AttributeTargets.Property | AttributeTargets.Method)]     public class AgeValidation : BaseAspect     {         private int _age;         public AgeValidation(int age)         {             _age = age;         }         public override void Process(ref IMethodCallMessage message)         {             int ageValue = -1;             if (message.Args != null && message.Args[0] != null)                 ageValue = (int)message.Args[0];             if (ageValue > _age)
            {
                throw new Exception(String.Format("Yaş en çok {0} olabilir.{1} geçerli bir yaş değil.", _age, ageValue));
            }

        }
    }

Bu yaratmış olduğumuz ilgileri bir önceki yazıda oluşturduğumuz alt yapının algılayabileceği şekilde bir kaç değişiklik yapmamız gerekecek. Bunun için aşağıdaki değişikliği Control sınıfımıza eklememiz yeterli olacaktır.

    public class Control : IMessageSink
    {

        private IMessageSink _messageSink;

        //İçeriğe dahil olan nesneler üzerinde kontroller yapabileceğimiz
        //nesneyi yaratmak için kullanacağımız yapıcı metodu,
        //alıcısını alacak şekilde tanımlıyoruz.
        public Control(IMessageSink sink)
        {
            _messageSink = sink;
        }

        //SyncProcessMessage metodu gelen alıcı mesaj aldığı zaman
        //çalışan bir metod. Bu metod ile alıcıya mesaj geldiği zaman
        //çeşitli kontrollerin yapılmasını sağlayabiliriz.
        //Burada mesaj diye tanımladığım operasyon aslında içeriğe dahil olan
        //nesnenin bir metodunun çalışması ya da bir özelliğinin çağrılması.
        //Bu örnekte şimdilik konsola bir mesaj yazdırıyor olacağız.
        public IMessage SyncProcessMessage(IMessage msg)
        {
            if (msg is IMethodCallMessage)
            {
                IMethodCallMessage preCall = (msg as IMethodCallMessage);
                this.BeforeMessageCall(ref preCall);//BeforeMessageCall diye bir metod yaratıyoruz.

            }
            return _messageSink.SyncProcessMessage(msg);
        }

        //AsyncProcessMessage metodu da SyncProcessMessage metodu ile aynı.
        //Sadece asenkron çağırımlarda çalışan versiyonu
        public IMessageCtrl AsyncProcessMessage(IMessage msg,
           IMessageSink replySink)
        {
            Console.WriteLine("Heyyy, önce bir dur bakalım...");
            return _messageSink.AsyncProcessMessage(msg, replySink);
        }

        //BeforeMessageCall metodu ile nesne yaratmadan önce,metod çağırmadan önce
        //ya da bir özelliği çağırmadan önce yapacağımız işlemleri çağırıyoruz.
        //Burada BaseAspect diye Attribute'ten türetilen kendi nesne tipimizi kontrol ediyoruz.
        //Eğer gelen mesajın özellikleri bu BaseAspect tipindense onun Process methodunu çağırıyoruz.
        //Burada hem metod hem de metod'un parametreleri var ise ve parametrelerde de BaseAspect tipi
        //olabilir mi diye kontrol ediyoruz.
        //-----------------------------------------------
        //Burada sadece method ve parametrelerini kontrol ediyoruz. Burada ki yapıyı genişleterek
        // daha güzel bir içerik yapabiliriz.
        private void BeforeMessageCall(ref IMethodCallMessage msg)
        {
            //Methodun
            BaseAspect[] attributes = msg.MethodBase.GetCustomAttributes(typeof(BaseAspect), true) as BaseAspect[];
            foreach (BaseAspect item in attributes)
            {
                item.Process(ref msg);
            }

            //Metodun parametrelerini alıyoruz.
            ParameterInfo[] parameters = msg.MethodBase.GetParameters();
            foreach (ParameterInfo item in parameters)
            {
                //Parametre değerlerinde BaseAspect'ten türeyen bir Attribute var mı kontrol ediyoruz.
                //Var ise metod çağrılmadan önce sahip olduğu Attribute çağırılıyor.
                attributes = item.GetCustomAttributes(typeof(BaseAspect), true) as BaseAspect[];
                foreach (BaseAspect parameterAttribute in attributes)
                {
                    parameterAttribute.Process(ref msg);
                }
            }

        }
   }

Bütün bunları yaptıktan sonra elimizde ne var kısaca bir özetleyelim; metodlarımızı, nesnelerimizi ve nesnelerin özelliklerini çağırmadan araya girebileceğimiz bir alt yapı, bu alt yapı içerisinde çeşitli sınıfları çalıştırmamızı sağlayacak metodlar ve çeşitli sınıflarımız(ilgilerimiz ya da “Aspect”lerimiz)

Şimdi bu yarattığımız ilgileri Person sınıfında kullanalım. Bunun için aşağıdaki gibi eklentiler yapmamız gerekmekte. Bu eklentiler aslında bir yazılım projesinde her kısımda ortak olarak kullanılabilecek ilgileri temsil ediyor. Log’lama gibi…Ya da belli bir değerleri kontrol eden validasyonlar gibi…Aşağıdaki örnek bu iki kavram için yeterli olur umarım.

    [Controller]
    public class Person : ContextBoundObject
    {
        private int _age = 0;
        private string _name = "";

        public string Name { get { return _name; } }

        public Person(string name) : base() { _name = name; }

        public int Age
        {

            get
            {
                return _age;
            }
            [Logger]//Age özelliğine değer ataması yapmadan önce yine kayıt tutuyoruz
            [AgeValidation(150)]//Atanacak değerin kontrolünü AgeValidation ile kontrol ediyoruz
            set                 //Bu noktada bir insanın 150 yaşından büyük olamayacağını düşünüyoruz.
            {
                _age = value;
            }
        }

        //DoSomething metodu çağrılmadan önce metod ile ilgili kayıt tutuyoruz...
        [Logger]
        public string DoSomething()
        {

            string logMessage = "Person sınıfının DoSomething() methodu çalıştı";
            Console.WriteLine(logMessage);

            return "";
        }

        //DoAnotherthing metodu çağrılmadan önce yine kayıt tutuyoruz.
        //Bu sefer metodun 2 tane parametresi olduğuna dikkat edelim.
        [Logger]
        public void DoAnotherThing(int parameter1, string parameter2)
        {
            Console.WriteLine("Person sınıfının DoAnotherThing() methodu çalıştı");
        }

    }

Aşağıdaki gibi basit bir konsol uygulaması ile Person sınıfımızı kullanabiliriz. Dikkat edersiniz ki herhangi ekstra bir ilgi yok.

    class Program
    {
        static void Main(string[] args)
        {

            Person arda = new Person("Arda Çetinkaya");
            arda.Age = 16;
            arda.DoSomething();
            arda.DoAnotherThing(5, "Test parametresi");

            Console.ReadLine();

        }
    }

Çalıştırdığımız zaman bu kodu, aşağıdaki gibi bir çıktı alıyor olacağız. Çıktıyı kontrol ettiğimizde metod çağrımlarından önce ilgilerin çalıştığını göreceğiz.

Uygulamada küçük bir deşiklik yaparak, başka bir çıktıyı da görelim isterseniz. Bunun için aşağıdaki Person sınıfındaki Age özelliğine 200 yazdığımızda programın çıktısı aşağıdaki gibi olacaktır ve yarattığımız AgeValidation ilgisine takılıp Exception fırlatacaktır.

Bu yoğun kodlar içerisinde umarım çok kaybolmamışınızdır ve biraz da olsa bazı şeyleri anlamaya yardımcı olmuştur umarım bu yazı…Ama henüz bitmedi…(: Bir küçük örnek ile AOP biraz daha iyi anlayacağız. Hatırlarsanız önce ki yazılarda nesnelerin bulunduğu duruma göre farklı özellikler kazanabileceğini söylemiştim. Aşağıdaki örnekte buna örnek veriyor olacağım.

    //Car adı altında arabayı simule eden bir nesnemiz var
    //Aldığı Person tipinde ki parametre ile Drive() metodu
    //sınıfın içeriğini oluşturuyor.
    [Controller]
    public class Car : ContextBoundObject
    {
        //Dikkat ederseniz CanDrive() Aspect'i ile parametrenin
        //bu metod için uygun olup olmadığını kontrol ediyoruz.
        //18 yaşını doldurmuş olmak şeklindeki bir iş kuralını
        //bu şekilde uygulayabiliriz.
        //Ama bildiğiniz üzere bu iş kuralı çeşitli ülkelerde
        //değişik bir şekilde çalışır.Bunun için de aşağıdaki
        //sınıfa göz atmakta fayda var...
        public virtual void Drive([CanDrive(18)]Person driver)
        {

            Console.WriteLine("Bas gaza...");
        }
    }

    //Car'dan türeyen yeni bir sınıfımız var. Amerikan arabasını
    //temsil eden bu sınıf türediği sınıfın Drive() metodunu eziyor.
    public class AmericanCar : Car
    {
        //Burada dikkat edecek olursanız CanDrive() Aspect'inin aldığı
        //değer 16...Malum ABD'de araba kullanabilme yaşı 16...
        public override void Drive([CanDrive(16)]Person driver)
        {

            Console.WriteLine("Amerika'da 16 yaşında araba kullanılabiliyor...Bas gaza...");
        }
    }

Yukarıdaki nesneleri canlandırabilecek şekilde konsol uygulamamızı günceliyor ve daha sonra çalıştırıyoruz…

    class Program
    {
        static void Main(string[] args)
        {

            Person arda = new Person("Arda Çetinkaya");
            arda.Age = 17;
            arda.DoSomething();
            arda.DoAnotherThing(5, "Test parametresi");

            AmericanCar cadillac = new AmericanCar();
            cadillac.Drive(arda);

            Car anadol = new Car();
            anadol.Drive(arda);

            Console.ReadLine();

        }
    }

Dikkat ederseniz anadol adındaki değişkenimizin Drive() metoduna kadar sorunsuz çalışacaktır. cadillac tipindeki değişkenin Drive() metoduna parametre olarak verdiğimiz nesnemiz, Drive() metodu için gerekli ön şartı sağladığından onda bir sorun olmadığının altını çizmek isterim. Bu örnekte nesnelerin bulundukları duruma göre sahip oldukları Aspect’lerin değişebileceğini gördük. 17 yaşındaki bir insan Türkiye’de araba kullanamazken, ABD’de araba kullanabilir. Ama insan özellikleri aynıdır (: Bu şekilde nesnelerin özelliklerinin değişebileceği sistemlerde AOP yaklaşımlarını kullanmak, sistem içerisinde ki karmaşıklığı minimuma indirecektir.

Neyse çok daha fazla saçmalamadan bitiriyorum. Umarım bazı şeyler biraz daha netleşmiştir. Biraz karmaşık bir konu ve aslında daha çok konuşacak şey var. Burada bahsetmiş olduğum kodların sadece bir örnek olduğu lütfen aklınızdan çıkarmayın. Geliştirin,hatta geliştirirken benle de paylaşırsanız sevinirim. Bir de .NET tarafında şu anda tam olarak bir AOP desteğinin olmadığı hatırlatmak isterim. Ama .NET’de AOP yaklaşımlarını uygulayabileceğiniz alt yapıyı biraz olsun yaratabileceğinizi unutmayın. Unity’i bu bağlamda kurcalamakta fayda olabilir. Tam olmasa da yaklaşımları AOP ile hemen hemen aynı…

Şimdilik bu kadar…Lütfen her türlü düşünce ve sorunuzu paylaşmaktan çekinmeyin…

Edit: Bu yazıda geçen örnek kodları buradan indirebilirsiniz…

• Paralel Programlamada İstisna Yönetimi
• ASP.net Nitelik(Attribute) Bazlı Veri Doğrulama(Validation)
• WCF İstemcinizin Bağlantı Değerlerini Değiştirerek Performansını Arttırın
• Windows Phone 7 Push Notification Types
• jQuery İçerisinden Bir WCF Servisini Kullanmak
• C# 5, Async ile Kolaylaşan Asenkron İşlemleri

• WPF ile Model View ViewModel yazı dizisi
• ASP.NET MVC 3 ve Razor View Engine
• WCF Öğreniyorum video dizisi (Yeni başladı takip edin derim)
• ASP.NET 4.0-URL Routing
• Internet Explorer 9–Sabitlenmiş Siteler
• Visual Studio 2010 Mimari Araçlar yazı dizisi

Başlıyoruz…

Asp.Net MVC uygulaması olarak, Visual Studio’da proje olarak gelen Asp.Net MVC projesini kullanıyor olacağız. Baştan bir MVC uygulaması yazmaya şimdi gerek yok, hazır yazılmışı olduğunu farz ederek bu proje şimdilik işimizi görecektir.

Aşağıdaki gibi bir proje yapımız olduğuna göre, tam olarak ne yapacağız buna geçelim. Amacımız MEF’in esnekliğini kullanarak Asp.Net MVC uygulamamızı esnetmek. Yani takıp çıkarabileceğimiz, bir birinden bağımsız bileşenler ile uygulamamıza genişletebilir bir yapı yapmak. Bu noktada takıp çıkarabileceğimiz bileşenler derken bunların “Controller”lar olduğunu belirtmekte fayda var sanırım.

“Controller”ların takıp çıkarılması olayını biraz daha açıp, “Controller”ların ayrı *.dll’ler şeklinde Asp.Net MVC uygulamamıza entegre olabilen bileşenler demek sanırım daha açık olacaktır.

Önce “Controller”ımızı yapalım…

Takıp çıkarılabilen bir “Controller” için Visual Studio’da yeni bir “Class Library” projesi yapmamız gerekmekte. Bu projenin çıktısı bizim MVC uygulamamıza dışardan ekleyebileceğimiz “Controller”ımız olacak. Projemizin aşağıdaki gibi bir yapısı olması gerekmekte. (Not: Poll ismini bu örnekte anket yaptığımızı farz ederek koydum)

Index.asp’miz View tarafımız *.cs dosyamız ise “Controller”ımız olacak. Aşağıdaki kod örneği de şimdilik yeterli olacaktır.

using System.Text;
using System.Web.Mvc;
using System.ComponentModel.Composition;
using Common;

namespace Plugins.Poll
{
    [Export("MVCController",typeof(IController))]
    [PluginMetadata("Poll", "1.0", "Arda")]
    [PartCreationPolicy(CreationPolicy.NonShared)]
    public class Poll : Controller
    {
        public ActionResult Index()
        {
            return View("~/Plugins/Views/Poll/Index.aspx");
        }
    }

}

Export ve Metadata kavramlarını önceki yazılardan tanıyoruz zaten. Aslında çok da farklı bir şey yok, şu aşamaya kadar…Burda altını çizmek istediğim nokta, bu “Controller”ı IController tipinde bir arayüz ile “export” ediyor olmamız. Bu arayüz Asp.Net MVC Framework içerisinde bulunan bir yapı ve MVC Framework’ünde ki tüm “Controller”lar bu arayüzden türüyor. Dolayısıyla, Asp.Net MVC uygulamamızın bu geliştirdiğimiz “Controller”ı algılayabilmesi için bu arayüz tipiyle “export” etmemiz çok önemli.

Bu projenin için de, artık nasıl bir operasyon gerçekleştirmek istiyorsan onları yapmamız yeterli olacaktır.

Şimdi sıra Asp.Net MVC uygulamamızda…

Bunun için Asp.Net MVC uygulamamızda kendi geliştirdiğimiz bu yapıdaki “Controller”ları yükleyecek yapıyı oluşturmamız lazım. Bir önceki yazımda bahsettiğim Controller Factory yaklaşımını, gerçekleştiriyor olacağız ve kendi “Controller” fabrikamızı basitçe yazıyor olacağız.

Asp.Net MVC uygulamamızda da PluginControllerFactory sınıfını yaratmamız lazım. Bu kodu daha iyi anlayabilmek için MEF ile ilgili daha önceki yazılara bakmakta fayda var.

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
using System.Globalization;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Common;

namespace MvcApplication2
{

    //IControllerFactory arayüzü MVC Framework'de Controller' yaratılmasında
    //gerekli olan bir arayüz. Geliştirilen tüm Controll fabrikalarının bu
    //arayüzden türemesi gerekiyor.
    public class PluginControllerFactory : IControllerFactory
    {
        private string _pluginPath;
        private DirectoryCatalog _catalog;
        private CompositionContainer _container;
        private DefaultControllerFactory _defaultControllerFactory;

        [ImportMany("MVCController", typeof(IController))]
        private IEnumerable<Lazy<IController, IPluginMetaData>> _plugins;

        public PluginControllerFactory(string pluginPath)
        {
            this._pluginPath = pluginPath;
            this._catalog = new DirectoryCatalog(_pluginPath);
            this._container = new CompositionContainer(_catalog);
            this._defaultControllerFactory = new DefaultControllerFactory();

        }
        //IControllerFactory arayüzünün iki tane metodu var.
        //Bunlardan biri CreateController metodu.
        //Bu metod gelen Routing talebini ve hangi
        //controller'ın yaratılması gerektiği bilgisi alıp,
        //"Controller"ın yaratılmasını sağlar. Dolayısıyla ne yapacaksak
        //bu metod içerisinde yapıyoruz. MVC uygulamamız için kendi
        //geliştirdiğimiz "Controller"ı bulup bu "Controller"ı MVC
        //uygulamıza gönderiyoruz.
        #region IControllerFactory Members
        public IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
        {
            _container.ComposeParts(this);
            if (_plugins != null || _plugins.Count() != 0)
            {
                foreach (var item in _plugins)
                {
                    if (item.Metadata is IPluginMetaData)
                    {
                        IPluginMetaData metadata = item.Metadata as IPluginMetaData;
                        if (metadata.Name == controllerName)
                        {
                            IController controller = item.Value as IController;
                            return controller;
                        }
                    }

                }
            }

            return this._defaultControllerFactory.CreateController(requestContext, controllerName);
        }

        //Bu metod da IControllerFactory arayüzünden
        //gelen bir metod.Bu metod yaratılan "Controller"ların
        //yok edilmesini sağlıyor.
        public void ReleaseController(IController controller)
        {
            IDisposable disposable = controller as IDisposable;
            disposable.Dispose();
        }
        #endregion
    }
}

Şimdi tek yapmamız gereken Asp.Net MVC uygulamızın “Controller” yaratırken kendi “Controller” fabrikamızı kullanmasını söylemek. Bunun için global.asax dosyasında aşağıdaki gibi bir değişiklik yapmamız yeterli olacaktır.

        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            RegisterRoutes(RouteTable.Routes);

            //Asp.Net MVC uygulamasının kendi yarattığımız "Controller"
            //fabrikasını kullanmasını ControllerBuilder sınıfının
            //Current özelliğinin SetControllerFactory metodu ile sağlıyoruz
            //"Plugins" parametresi ile de kendi yarattığımız "Controller"ların
            //hangi dizinde olacağını belirtiyoruz.
            ControllerBuilder.Current.SetControllerFactory(new PluginControllerFactory(
                Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugins")));
        }

Artık Asp.Net MVC uygulamamız, kendi yarattığımız “Controller” fabrikası sayesinde, farklı “Controller”ların çok rahat bir şekilde sisteme dahil olmasını sağlıyor olacaktır.

Oldukça basit bir şekilde Asp.Net MVC Framework’de MEF’i nasıl uygulayabiliriz bunu anlatmaya çalıştım. Umarım biraz olsa da faydalı olmuştur.

Not: Yazıda geçen kodları ve projeyi buradan indirebilirsiniz.