İlkay İlknur

Nedirtv Şubat Webinerleri (Level 300 Özel) ve C# 5.0 Webinerim

ilkayilknur — Fri, 03 Feb 2012 09:37:00 +0200

Merhaba Arkadaşlar,

Çektiğim görsel dersler ile katkıda bulunduğum nedirtv'nin bu ay düzenlemiş olduğu Level 300 webinerlerinde 23 Şubat'ta "Tüm Yönleriyle C# 5.0 Asenkron Programlama" isimli bir webiner düzenliyor olacağım. Webinerlerin teması level 300 olsada webiner başında en basit örnekler ile başlayıp C# 5.0'ı temelden incelemeye başlayacağız ve seviyemizi yavaş yavaş arttıracağız. Bu nedenle webinere her seviyeden developerlar katılabilir ;)

Şubat Webinerlerinin Programı Şu Şekilde

Konu: Veritabanı Yerine Cache'deki Verilerle Çalışmak

Zaman: 6 Şubat 2012 Pazartesi 21:00

Konuşmacı: Uğur UMUTLUOĞLU

Link: https://www.livemeeting.com/cc/mvp/join?id=TF2CJN&role=attend

Konu: Dynamics CRM'e Plugin Yazma

Zaman: 13 Şubat 2012 Pazartesi 21:00

Konuşmacı: Barış KANLICA

Link: https://www.livemeeting.com/cc/mvp/join?id=T8DDJ7&role=attend

Konu: Entity Framework - Migration

Zaman: 20 Şubat 2012 Pazartesi 21:00

Konuşmacı: Burak Selim ŞENYURT

Link: https://www.livemeeting.com/cc/mvp/join?id=P4P5JG&role=attend

Konu: Tüm Yönleriyle C# 5.0 Asenkron Programlama

Zaman: 23 Şubat 2012 Perşembe 21:00

Konuşmacı: İlkay İLKNUR

Link: https://www.livemeeting.com/cc/mvp/join?id=7H5R69&role=attend

Konu: Masaüstü Uygulamasından ASP.NET Sayfalarıyla Etkileşim

Zaman: 27 Şubat 2012 Pazartesi 21:00

Konuşmacı: Fatih BOY

Link: https://www.livemeeting.com/cc/mvp/join?id=68WBPH&role=attend

23 Şubat'ta Görüşmek Üzere,

Roslyn - Scripting API ve C# Interactive Window

ilkayilknur — Wed, 01 Feb 2012 10:51:00 +0200

Merhaba Arkadaşlar,

Bir önceki yazımızda sizlerle Compiler As a Service konseptini inceleyerek Roslyn projesinin temelini oluşturan kavramları ve servisleri kısaca ve tamemen teorik olarak incelemiştik. Bu yazımızdan itibaren Roslyn ile derinlere dalmaya başlayacağız ve uygulamalı olarak Roslyn’i kullanmaya başlayacağız.

Önceki yazımızda Compiler içerisindeki servislerin birer API ile dışarıya açılmasının getireceği yeniliklerden bahsederken ilk sırada programlama dillerinin scripting özelliği kazanmasını söylemiştik. Scripting özelliği ile aslında uygulamalar içerisinde C# veya VB kodlarının dinamik olarak çalıştırılmasından söz etmekteyiz. Özellikle IronPython gibi dinamik programlama dillerine baktığımızda bu şekilde scripting özellikleri programlama dilinin yapısından dolayı mümkün olabilmekte. Hatta C# 4.0 ile beraber gelen dinamik programlama yenilikleri ve DLR (Dynamic Language Runtime) ile uygulamalarımız içerisinde şu anda Dinamik Programlama dillerinin kodlarını çalıştırabilmekteyiz.

Ancak konu C# ve VB kodlarının dinamik olarak çalıştırılabilmesine geldiğinde Roslyn öncesine kadar böyle bir şeyi gerçekleştirmek bizler için çok kolay değildi. Bunun için Reflection ve CodeDom tarafında bir takım derleme işlemleri yapmak gerekmekteydi.

Roslyn içerisinde bulunan Scripting API ile artık C# ve VB kodlarını uygulamalar içerisinde hızlı bir şekilde işletip sonuçlarını alabilmekteyiz. Şimdi ilk olarak bir Console uygulaması yaratalım ve bu uygulama içerisinden kodlarımızı dinamik olarak çalıştıralım.(Makale boyunca görmüş olduğunuz kodları çalıştırabilmek için Roslyn.Compilers ve Roslyn.Compiler.CSharp dll’lerini referans olarak eklemeniz gerekmekte.)

ScriptEngine engine = new ScriptEngine();

engine.Execute(@"System.Console.WriteLine(""Hello Roslyn !!!"");");

Yukarıdaki kodu doğrudan çalıştırdığımızda string olarak yazmış olduğumuz kodun C# compilerı tarafından işletildiğini ve Console uygulamamızın ekranına "Hello Roslyn !!!” yazdığını görüyoruz.

Şimdi biraz daha ileri gidelim ve değişken tanımlayıp bu tanımladığımız değişkeni bir alt satırda yazmış olduğumuz bir başka dinamik kod içerisinde kullanalım.

ScriptEngine engine = new ScriptEngine();

engine.Execute(@"int x = 5;");

engine.Execute(@"System.Console.WriteLine(x);");

Yazmış olduğumuz kodu çalıştırdığımızda bakalım ne ile karşılaşacağız :)

Compiler tarafından ilk olarak yaptığımız tanımlama işletildikten sonra 2. sırada yazmış olduğumuz tanımladığımız değişkenin değerini Console’a yazdıran kod işletildiği sırada yukarıdaki exception fırlatılmakta ve x değişkeninin context içerisinde bulunmadığı söylenmekte. ;)

Buradan da çıkaracağımız sonuç şu olmalı ki ScriptEngine tipi içerisinde bulunan Execute metoduna sadece string olarak verdiğimiz C# veya VB kodları işletildikten sonra bu kodlar içerisinde yapılmış olan tüm tanımlamalar compiler tarafından unutulmakta. Peki bu tanımlamaların unutulmaması için ne yapmamız gerekiyor ?

Execution Context

C# veya VB kodlarının dinamik olarak işletilmesi sırasında daha önceden işletilen kodlarının compiler tarafından unutulmaması için kodların içerisinde çalıştırılacağı bir context belirlememiz gerekmekte. Bunun için de Roslyn tarafında kodumuzun içerisinde işletileceği bir Session belirlememiz gerekmekte ve Execute metoduna parametre olarak vereceğimiz kodun yaratmış olduğumuz Session içerisinde işletilmesi gerektiğini bildirmemiz gerekmekte.

ScriptEngine engine = new ScriptEngine();

Session session = Session.Create();

engine.Execute(@"int x = 5;", session);

engine.Execute(@"System.Console.WriteLine(x);", session);

Şimdi biraz daha ileriye gidelim ve session içerisinde bir metot tanımlayalım ve daha sonra bu metodu çağıralım.

ScriptEngine engine = new ScriptEngine();

Session session = Session.Create();

engine.Execute(@"void Print (object x){ System.Console.WriteLine(x);}",session);

engine.Execute(@"int x = 5;", session);

engine.Execute(@"Print(x)", session);

Şu ana kadar Roslyn tarafında dinamik kod işletme ile ilgili olarak temel kısımları inceledik. Ancak incelememiş olduğumuz bir nokta kaldı. O da dinamik olarak işletmiş olduğumuz kodun aslında çalıştırılmış olduğu host uygulama ile nasıl iletişimde olacağı.

Host Object

Host uygulama ile iletişimde bulunmak için Roslyn tarafında Host Object yapısını kullanmamız gerekmekte. Host Object dediğimiz yapı aslında herhangi bir tip olabilmekte. Bu tip, tanımlamış olduğumuz session içerisine dahil edilmekte ve böylece biz de dinamik olarak işleteceğimiz kodlar tarafında bu host object içerisinde bulunan tüm public üyelere erişebilmekteyiz ve istediğimiz işlemleri gerçekleştirebilmekteyiz. Örnek olarak host uygulama içerisnde şu şekilde içerisinde sayıları tutan ve bir takım işlemler gerçekleştiren bir sınıf tanımlayalım.

public class NumberList

      List<int> numbers = new List<int>();

      void Add(int i)

           numbers.Add(i);

      void PrintNumbers()

           for (int i = 0; i < numbers.Count; i++)

                 Console.WriteLine("{0}- {1}", i + 1, numbers[i]);

Yukarıda tanımlamış olduğumuz tip host uygulama olan Console uygulamamızda yer almakta. Şimdi sıra geldi bu tipi nasıl kullanacağımıza. Eğer bir tipi host object olarak kullanmak istiyorsak öncelikli olarak bu tipi ilgili Script Engine ve Session tiplerine bildirmemiz gerekmekte.

NumberList numberList = new NumberList();

ScriptEngine engine = new ScriptEngine(new[]

                                  { typeof(NumberList).Assembly.Location });

Session session = Session.Create(numberList);

engine.Execute("Add(3);", session);

engine.Execute("Add(5)", session);

engine.Execute("PrintNumbers()", session);

Uygulamamızı çalıştırdığımızda aşağıdaki gibi bir çıktı ile karşılaşmaktayız.

C# Interactive Window

C# ve VB programlama dillerine Scripting özelliğinin gelmesiyle beraber yapılabilecekler düşünüldüğünde aklımıza ilk olarak REPL(Read-Eval-Print-Loop) uygulamaları gelmekte. Yukarıda yapmış olduğumuz örneklere baktığımızda aslında bir REPL uygulaması yapmak için hemen hemen tüm parçalar elimizde. Bu nedenle REPL uygulaması kısmını tamamen size bırakıyorum ;) Ancak yine de takıldığınız noktalar olursa zaten internette Roslyn ile yapılmış pek çok REPL uygulaması bulunmakta bunlardan yararlanabilirsiz ya da İletişim bölümünden bana ulaşabilirsiniz.

Makalemizin sonlarına gelirken makalenin bu bölümünde aslında yine Roslyn ile beraber gelen ve Visual Studio içerisine entegre edilen bir REPL uygulamasından bahsediyor olacağım. Roslyn paketini bilgisayarınıza yükledikten sonra Visual Studio içerisinde View => Other Windows yolunu izlediğinizde burada “C# Interactive Window” seçeneğini görüyor olacaksınız. Buraya tıkladığımızda karşımıza gelen aslında C# kodları ile çalışan bir REPL uygulaması. Bu uygulama ile hızlı bir şekilde istediğimiz kodu yazıp sonucunu görebilmekteyiz.

Şimdi isterseniz buraya bir takım kodlar yazalım ve sonuçlarını inceleyelim.

Gördüğünüz gibi aslında bir C# uygulaması içerisinde yapabileceğimiz pek çok şeyi bu Window içerisinde yapabilmekteyiz ve sonuçlarını hemen görebilmekteyiz. Peki diğer dil özellikleri bu Window içerisinde destekleniyor mu diye soracak olursanız aslında compiler tarafından sağlanan bilgiler ile çalışan outlining, colorizer, intellisense gibi özellikler de bu window içerisinde çalışmakta. Burdan da anlıyoruz ki aslında compiler tarafından sağlanan farklı farklı API’lar birbirlerinden bağımsız olarak beraberce çalışabilmekteler. ;)

C# Interactive Window içerisinde bilmemiz gereken en önemli komutlardan biri de library referansı ekleme komutudur. #r “LibraryName” komutu ile Interactive Window içerisinde çalıştıracağınız kodlar ile ilgili gerekli referansları ekleyebilirsiniz.

Bunun yanında Interactive Window içerisindeki en güzel özelliklerden biri de yazmış olduğunuz uygulama içerisindeki kodları hızlı bir şekilde işletebilme ve sonuçlarını inceleyebilme şansı vermesi. Bunun için çalıştırmak istediğiniz kodu seçip Ctrl+Enter yapmanız yeterli. Yazmış olduğunuz kod Interactive Window içerisine kopyalanmakta ve işletilmekte. ;)

Eğer bir takım referanslar Interactive Window içerisinde tanımlı değilse kopyalamış olduğunuz kod Interactive Window içerisinde çalıştırılamayabilir. Bu nedenle öncelikle uygulama içerisinde referansların Interactive Window içerisinde referans olarak eklendiğinden emin olmamız gerekmekte. Bunun için de ilgili Project’e sağ tıklayarak “Reset Interactive Window From Project”’i seçmemiz gerekmekte.

Bu noktadan sonra ise artık yapmamız gereken ilgili kodu seçip Ctrl+Enter ile C# Interactive Window içerisinde işletmek.

Not : Interactive Window şu anda sadece C# için bulunmaktadır. İlerleyen sürümlerde VB için de Interactive Window duyurulacaktır.

Gördüğünüz gibi Compiler As a Service (CaaS) konsepti oldukça geniş ve bir o kadar da eğlenceli bir konu :) Bu yazımızda her ne kadar sadece Scripting API’yi incelemiş olsakta sırf bu API’yı kullarak bile yapabileceğimiz pek çok şey bulunmakta. Bu yüzden bir C# veya VB developer olarak herkese Roslyn projesini takip etmesini öneriyorum.

Umarım sizler için faydalı bir makale olmuştur.

Not: Makale içerisindeki kodlar Roslyn CTP-1 ile yazılmış ve test edilmiştir.

The Roslyn Project - 5N1K (Ne,nerede,ne zaman,nasıl,neden,kim)

ilkayilknur — Wed, 25 Jan 2012 13:34:00 +0200

Merhaba Arkadaşlar,

C# 4.0 ve VB.NET 10 programlama dili sürümleriyle beraber Microsoft tarafında bu iki programlama dilini geliştiren ekipler tek bir çatı altında toplandı. Tek bir çatı altında toplanmasının temel nedeni de aslında programlama dillerini kullanan developerların benzer ihtiyaçlarının olması ve programlama dillerinin özelliklerinin birbirlerinden farklı olmasının önüne geçilerek ortak temalar üzerinden ilerlenmesi idi.

Tüm bu çalışmalar kapsamında C# 4.0 sürümünün release olmasından sonra programlama dili ekipleri 2 ayrı takıma ayrılarak geliştirmelere devam etmekteler. Bir ekip şu anda C# 5.0 ve VB.NET 11 ( programlama dilleri arasındaki farklılıkları gidermek amacıyla VB 11 ile beraber C#’ta uzun zamandır bulunmakta olan Iterators özelliği geliyor olacak. ) dediğimiz programlama dillerinin bir sonraki versiyonu olan ve ana teması Asenkron Programlama olarak belirlenen geliştirmelere devam ederken bir diğer ekipte daha uzun soluklu bir proje olan Roslyn kod adlı projeye devam etmekteler.

Özellikler C# programlama dilinin geleceği ile ilgili araştırmalar yaptıysanız Compiler as a Service(CaaS) konseptiyle mutlaka karşılaşmışsınızdır. İşte Roslyn projesinin temel amacı da bu. Compiler as service, yani compiler’ın bir API vasıtasıyla servis olarak dışarıya açılması.

Şu anda C# ve VB compilerının yapısına baktığımız zaman compilerların tam bir kara kutu olduğunu söyleyebiliriz. Çünkü compilerlar yazmış olduğumuz kaynak kodu input olarak alırlar , içeride sihir gerçekleşir ve output olarak .NET assemblyleri üretirler. Compiler aslında bu sihrin gerçekleşmesi sırasında yazmış olduğumuz kod ile ilgili pek çok analiz yapar ve bir takım yapılar oluşturur. Ancak .NET assemblysi üretilmesiyle beraber compiler yaratmış olduğu bu yapıları tamamen siler ve unutur.

Ayrıca syntax highlighting, go to definition, formatting veya refactoring gibi üretkenliğimizi arttıracak olan özelliklerde de baktığımız zaman IDE tarafından sağlanan bu özelliklere sıkı sıkıya bağlı olduğumuz görmekteyiz. Developer olarak kendi ihtiyaçlarımızı karşılayacak olan refactoring mekanizmalarını gerçekleştirmemiz oldukça zor. Aslında syntax highlighting, go to definition, formatting veya refactoring gibi özellikleri incelediğimizde tüm bu özellikler arka planda compiler’ın kodu derleme ve Assembly üretme sırasında kullanmış ve yaratmış olduğu yapıları kullanmakta.

Tüm okuduklarımızı düşündüğümüze Roslyn projesi ile amaçlanan compilerın kara kutu olmaktan çıkarılarak ve içerisinde bulunan bilgilerin bir API vasıtasıyla developerlara sunulmasıdır. Bu doğrultuda da C# ve VB compilerları kendi dillerinde !!! yani managed programlama dilleriyle yeniden implemente edilemekte. Evet yanlış okunmadınız :) Bir takım tarihsel nedenlerden dolayı C# ve VB compilerları C++ programlama dili ile yazılmıştır. Ancak Roslyn projesinden C# ve VB compilerları kendi dillerinde yeniden yazılmaktalar.

Compiler içerisindeki yapıları bir API ile dışarı sunulması peki developerlar için neler sağlayacak ? Aslında yapılabilecek pek çok şey bulunmakta. İlk aklımıza gelen, özellikle dinamik programlama dillerinde gördüğümüz Read-Eval-Print Loop’lar artık implemente edilebilir durumda olacak. Programlama dili içerisindeki scripting yeteneğinin bu şekilde hayata geçtiğini görüyor olacağız. Bunun yanında Meta-Programming dediğimiz aslında program yazan program olarak Türkçe’ye çevirebileceğimiz mekanizmalarda artık gerçekleştirilebiliyor olacak. Ayrıca Language-Object-Model’a sahip olarak, yazılan kod üzerinde tüm analizleri yapabiliyor olacağız. Kendi yazacağımız extensionlar veya uygulamalar ile çok çeşitli kendimize özel refactoring mekanizmalarını hayata geçirebiliyor olacağız. Ayrıca DSL(Domain – Spesific –Languages) Embeding dediğimiz kendi uygulamamıza has bir takım komutlar arasına C# veya VB kodu yerleştirebiliyor ve bu kodları da istediğimiz zaman işletebilir durumda oluyor olacağız.

Roslyn APIs

Yazmış olduğumuz kodların .NET assembly’si haline çevrilmesi süreci aslında compiler içerisinde 4 farklı süreci içerisinde barındırmakta.

Bunlar,

Parser : Kaynak kodu geçmiş olduğu ilk süreçtir. Bu süreç içerisinde kaynak kod parse edilerek kod tokenlara ayrılır. Ayrılan tokenlar aynı zamanda yapısal bir veri yapısına getirilirler. (Syntax Tree)
Symbols & Metadata Import : Bu aşamada kaynak kod içerisindeki tanımlamalar bulunur ve analiz edilir. Daha sonrasında ise sembol tabloları oluşturulması amacıyla bu tanımlamalar ile ilgili metadatalar okunarak sembol tabloları oluşturulur.
Binder : Bu aşamada da sembol tablosundaki tanımlamalarla kod içerisinde yapılmış olan tanımlamalar eşleştirilir.
IL Emitter : Son aşama olan bu aşamada ise tüm oluşturulan yapılar ve bilgiler birleştirilerek .NET Assembly’si oluşturulur.

Peki Compiler API’ları tam olarak bu süreçlerin neresine oturmakta ?

Compiler API’larını incelediğimizde aslında her bir süreci ayrı olarak içerisinde barındıran farklı API’ları görmekteyiz. Parsing süreci içerisinde Syntax Tree API bulunurken bu API ile Parsing işlemi sürecinde üretilen Syntax Tree üzerinde işlemler gerçekleştirilebilmekte. Aynı şekilde Symbol API, Binding and Flow APIs ve Emit API da geri kalan süreçler ile ilgili işlemleri içerlerinde barındırmakta.

Önceki paragraflarda IDE içerisinde bulunan ve developerların özellikle üretkenliklerini arttıran özelliklerin aslında compiler tarafından üretilen yapıları kullandığından bahsetmiştik. Peki hangi özellikler hangi aşamadaki bilgileri ve API’ları kullanmakta ?

Formatting, colorizer ve outlining gibi özelliklerin Parsing işlemi sonrasında üretilen Syntax Tree’yi kullandığını görmekteyiz. Navigate To ve Object Browser özellikleri de Symbol API tarafından sunulan Sembol Tablosuna dayanmakta. Intellisense, Rename, Extract Method, Go To Definition gibi IDE içerisinde bulunan pek çok özellikte Binding işlemi sonucunda üretilen yapılara dayanmakta. Edit and Continue ise Emit API tarafından gerçekleştirilmekte.

Compiler as Service konsepti aslında oldukça geniş ve içerisinde pek çok bilgiyi barındıran bir konsept. Roslyn projesinin tamamlanmasıyla beraber pek çok özelliğin geleceğini ve çok yaratıcı uygulamaların ortaya çıkacağını söylemek sanırım yanlış olmaz. Bu uzun soluklu projeyi en başından itibaren takip etmenizi şiddetle öneriyorum.

Roslyn projesinin ne zaman tamamlanacağını soracak olursanız açıkcası bunun için süre vermenin çok doğru olacağını düşünmüyorum. Ancak şunu söyleyebilirim ki C# 5.0 ile gelmiyor olacak :)

Roslyn projesinin şu anda CTP sürümü bulunmakta. Bu sürümü buradaki adresten indirip kurabileceğiniz gibi aynı zamanda NuGet Package Manager’a Roslyn yazarak ta projenize ekleyebilirsiniz ;) .

Bir sonraki yazımızda Roslyn ile derinlere dalıyoruz ;)

Object,Collection ve Dictionary Initializers

ilkayilknur — Sat, 21 Jan 2012 15:34:00 +0200

Merhaba Arkadaşlar,

Bu yazımızda sizlerle C# 3.0 sürümünden itibaren bizlerle olan ve C# tarafında object’lerin ve collection’ların yaratılması sırasında developerlara oldukça kolaylık sağlayan Object & Collection & Dictionary Initiliazers konusunu inceliyor olacağız.

İlk olarak Object Initializers tarafına bakarsak Object Initializer yapısı basit olarak biz developerların özellikle object yaratımı sırasında objectlerin propertylerine ilk değerleri atamamız konusunda syntax bakımından oldukça kolaylık sağlamakta. Bunun yanında Object Initiliazers özellikle LINQ sorgularında ve anonymous type yaratımında da hayati önem arzetmekte.

Şimdi öncelikle basit bir sınıf tanımlayalım ve daha sonra Object Initializer mekanizmasıyla yaratmış olduğumuz object’in propertylerini ilk değerlerine set edelim.

class MyClass

     public int Property1 { get; set; }

     public string Property2 { get; set; }

     public MySecondClass Property3 { get; set; }

class MySecondClass

     public int MyProperty { get; set; }

Şimdi object initializer kullanarak MyClass tipinden bir nesne örneği yaratalım.

MyClass myClass = new MyClass()

     Property1 = 1,

     Property2 = "Property2",

     Property3 = new MySecondClass()

          MyProperty = 3

};

Gördüğünüz gibi oldukça basit bir şekilde nesnemizi yarattık. Peki arka planda neler oluyor ? Öyleyse hemen arka plana geçelim ve bakalım neler oluyor.

Farklılıklar aslında yaratılan IL tarafında gerçekleşmekte.

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 3
    .locals init (
        [0] class ConsoleApplication2.MyClass myClass,
        [1] class ConsoleApplication2.MyClass <>g__initLocal0,
        [2] class ConsoleApplication2.MySecondClass <>g__initLocal1)
    L_0000: nop
    L_0001: newobj instance void ConsoleApplication2.MyClass::.ctor()
    L_0006: stloc.1
    L_0007: ldloc.1
    L_0008: ldc.i4.1
    L_0009: callvirt instance void ConsoleApplication2.MyClass::set_Property1(int32)
    L_000e: nop
    L_000f: ldloc.1
    L_0010: ldstr "Property2"
    L_0015: callvirt instance void ConsoleApplication2.MyClass::set_Property2(string)
    L_001a: nop
    L_001b: ldloc.1
    L_001c: newobj instance void ConsoleApplication2.MySecondClass::.ctor()
    L_0021: stloc.2
    L_0022: ldloc.2
    L_0023: ldc.i4.3
    L_0024: callvirt instance void ConsoleApplication2.MySecondClass::set_MyProperty(int32)
    L_0029: nop
    L_002a: ldloc.2
    L_002b: callvirt instance void ConsoleApplication2.MyClass::set_Property3(class ConsoleApplication2.MySecondClass)
    L_0030: nop
    L_0031: ldloc.1
    L_0032: stloc.0
    L_0033: ret
}

Akışa baktığımızda aslında bizim yaptığımız işlemleri compiler arka planda açarak, teker teker tüm işlemleri gerçekleştirmekte ve yaklaşık olarak aşağıdaki kod örneğine çevirmekte.

MyClass myClass = new MyClass();

myClass.Property1 = 1;

myClass.Property2 = "Property2";

MySecondClass second = new MySecondClass();

second.MyProperty = 3;

myClass.Property3 = second;

Şimdi yukarıdaki kod ile bir önceki object initializer kullanarak yazdığımız kodu karşılaştırdığımızda özellikle okunulabilirlik bakımından oldukça büyük farklar bulunmakta. İlk kullanımda kodu okuyan developer hemen hızlı bir şekilde set edilen değerleri okuyup geçerken diğer örnekte ise tek tek referansları kontrol etmek zorunda kalmakta ve daha çok zaman kaybetmekte. Bunun yanında kodu yazan developer da ikinci kullanımda birinci kullanıma göre daha çok zaman kaybetmekte.

İşte bu noktadaki problemi çözmek için compiler devreye girmekte ve developerlara oldukça kolay bir tanımlama syntax’ı sağlarken arka planda da bu syntax’ın kullanıldığı kısımları yeniden yazarak aslında arka planda yine klasik kullanımı muhafaza etmekte ;)

Collection Initializers

C# 3.0 ile beraber gelen bir diğer syntax kolaylığı ise Collection Initializers’dı. Collection Initializers ile yarattığımız koleksiyonlar içerisine elemanları hızlı bir şekilde yerleştirebilmekteyiz.

Örneğin,

List<int> list = new List<int>()

      1,2,3,4,5,6,7

};

yukarıdaki gibi bir kullanımla bir List<T> tipinden biri koleksiyon örneği yarattıktan sonra içerisine 1’den 7’ye kadar elemanları ekleyebilmekteyiz. Bu kullanım aslında C# 3.0 öncesinde array’ler için geçerliydi. Ancak C# 3.0 ile beraber bu kullanım kolaylığı collection tipleri için de getirildi.

Peki collection initializers kullandığımızda arka planda neler oluyor ? :)

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] class [mscorlib]System.Collections.Generic.List`1<int32> list,
        [1] class [mscorlib]System.Collections.Generic.List`1<int32> <>g__initLocal0)
    L_0000: nop
    L_0001: newobj instance void [mscorlib]System.Collections.Generic.List`1<int32>::.ctor()
    L_0006: stloc.1
    L_0007: ldloc.1
    L_0008: ldc.i4.1
    L_0009: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_000e: nop
    L_000f: ldloc.1
    L_0010: ldc.i4.2
    L_0011: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_0016: nop
    L_0017: ldloc.1
    L_0018: ldc.i4.3
    L_0019: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_001e: nop
    L_001f: ldloc.1
    L_0020: ldc.i4.4
    L_0021: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_0026: nop
    L_0027: ldloc.1
    L_0028: ldc.i4.5
    L_0029: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_002e: nop
    L_002f: ldloc.1
    L_0030: ldc.i4.6
    L_0031: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_0036: nop
    L_0037: ldloc.1
    L_0038: ldc.i4.7
    L_0039: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
    L_003e: nop
    L_003f: ldloc.1
    L_0040: stloc.0
    L_0041: ret
}

Burada da baktığımızda aslında yazdığımız kodun aksine compiler arka planda öncelikle bir List nesne örneği yaratmakta ve sonrasında da tüm elemanları List tipinin Add metodunu kullanarak eklemekte. Aslında bizim normalde de kullanmamız gereken bu metodu compiler arka planda kendisi kullanmış ve biz developerlara daha kısa bir syntax ile uygulama geliştirme imkanı sağlamış.

Collection Initializer mekanizmasını kullanmamız için sadece tek bir kısıt bulunmakta. O da tipimizin IEnumerable interface’ini implemente etmesi ve tip içerisinde Add metodunun bulunması. Burada aklımıza gelen bir soru bulunmakta. Bu da arka planda generate edilen IL kodlarında IEnumerable interface’inin kullanılmamasına rağmen collection initializers mekanizmasında neden zorunlu olarak IEnumerable interface’inin tip tarafından implemente edilmek zorunda olduğu. Bunun nedeni de aslında C# programlama dili tasarım ekibi tarafından alınmış bir karara dayanmakta. C# 3.0 ile ilgili araştırmalar yaparken collection Initializers yapısının destekleneceği noktalar ekip tarafından incelenmiş ve bu özellik collection tipleri ile sınırlı bırakılmış ve bu nedenle de tipin IEnumerable interface’ini implemente etmesi gerektiği zorunlu hale getirilmiştir.

Dictionary Initializers

Bu yazımızda son olarak bahsedeceğimiz konu da Dictionary Initializers. Collection Initializers ile collection tipleri içerise kolay bir şekilde eleman ekleyebilirken, aslında bu ihtiyaca benzer bir durum da dictionary tipleri için doğmakta. Bazı durumlarda yarattığımız Dictionary’ler içerisine elemanları teker teker eklememiz gerekebilmekte. Bu noktada da yine Collection Initializers’da olduğu gibi C# tarafından sağlanan kolay bir syntax ile dictionary içerisine ilk elemanları atabilmekteyiz.

Dictionary Initializers’ın kullanımı ise şu şekilde olmakta.

Dictionary<int, string> a = new Dictionary<int, string>()

      {1,"Bir"},

      {2,"İki"},

      {3,"Üç"}

};

Peki compiler arka planda ne yapmakta ?

Dictionary<int, string> <>g__initLocal0 = new Dictionary<int, string>();
<>g__initLocal0.Add(1, "Bir");
<>g__initLocal0.Add(2, "İki");
<>g__initLocal0.Add(3, "Uc");
Dictionary<int, string> a = <>g__initLocal0;

Compiler kimi zaman bu yazımızda da gördüğümüz gibi bir takım kolay syntax yapılarını developerlara sunarken arka planda aslında bu syntax yapısını klasik kullanımlara geri çevirerek developerların yazılım geliştirme sürelerini kısaltmayı amaçlamakta. Kimi zaman da keywordler veya modifierlar sunarak arka planda kurduğu generic yapılarla çok daha farklı işleri biz developerlara hissettirmeden gerçekleştirmekte. ;)

Hoşçakalın

C# 5.0 Async & Await Arka Planda Neler Oluyor ?

ilkayilknur — Wed, 11 Jan 2012 11:59:00 +0200

Merhaba Arkadaşlar,

Sizlerle şu ana kadar C# 5.0 ile beraber gelecek olan Asenkron Programlama yeniliklerini hangi noktalarda kullanabileceğimizi inceledik. Ancak bildiğiniz gibi her programlama dili yeniliği aslında arka planda yeni bir sihir yaratır. Daha önce kodumuzu neredeyse tamamen değiştirerek asenkron hale getirirken artık sadece 1-2 ufak değişiklikle kodumuzu asenkron bir şekilde çalışacak hale getirebiliyoruz. Peki gerçekten arka planda neler oluyor ? Compiler neler yapıyor da biz sadece 1-2 kod değişikliği ile kodumuzu asenkron hale getirebiliyoruz.

İlk olarak aşağıdaki gibi bir asenkron metodumuz olduğunu düşünelim.

static async Task<string> DownloadStringAsync(string Url)

    WebClient client = new WebClient();

    return await client.DownloadStringTaskAsync(Url);

Şimdi yazmış olduğumuz kodu derleyelim ve sonrasında Reflector yardımıyla açalım ve bakalım derleme sonucunda asenkron metodumuz compiler tarafından nasıl yeniden yazılmış ?

Dikkat : Yazının bu kısmından sonrası aşırı miktarda compiler tarafından üretilen kod içermektedir. Eğer compiler tarafından üretilen kodlara karşı alerjiniz varsa bu satırlar sizin için son çıkıştır. Ancak yazıyı buraya kadar okuduysanız sizinde aslında arka planda benim gibi neler olduğunu merak ediyor olduğunuzu düşünüyorum :)

private static Task<string> DownloadStringAsync(string Url)
{
        <DownloadStringAsync>d__0 d__;
        d__ = new <DownloadStringAsync>d__0(0) {
            Url = Url,
            <>t__MoveNextDelegate = new Action(d__.MoveNext),
            $builder = AsyncTaskMethodBuilder<string>.Create()
        };
        d__.MoveNext();
        return d__.$builder.Task;
}

Gördüğünüz gibi compiler, bizim yazmış olduğumuz DownloadStringAsync isimli metodu arka planda bir takım tipleri kullanarak yeniden yazdı.

Önceki yazılarımızdan da hatırlayacağımız üzere asenkron metotların dönüş tipi Task, Task<T> veya void olmak zorunda. Ancak bu dönüş tipini her zaman bizim yaratıp döndürmemiz gerekmemekte. Nitekim await kullanarak WebClient tipi içerisindeki DownloadStringTaskAsync metodunu çağırdığımızda bu metodun dönüş tipinin string olduğunu kolayca görebilmekteyiz. Ancak gördüğünüz gibi biz aslında asenkron metodumuzun dönüş tipini Task<string> olarak belirttik ve baktığımız zaman return ifadesinde de string döndürdük. Baktığımız zaman bu kullanım aslında tamamen legal. Ancak tabi ki bu işlem arka planda bir takım dönüşümler gerektirmekte. Bu dönüşümlerden ilki de Task<string> tipinin arka planda yaratılması ve metottan geri döndürülerek yazdığımız kodun arka planda da legalleştirilmesi. İşte compiler tarafından yazılan kodda görmüş olduğunuz AsyncTaskMethodBuilder tipi tam da bu işi gerçekleştirmekte.

public struct AsyncTaskMethodBuilder<TResult>
{
    public Task<TResult> Task { get; }
    public void SetResult(TResult result);
    public void SetException(Exception exception);
}

AsyncTaskMethodBuilder tipi gördüğünüz gibi içerisinde metot tarafından döndürülecek olan Task tipini ve metot işletilmesinden sonra da bu Task tipi içerisine sonucu yazmakta kullanılan SetResult isimli metodu içermekte. Bir de tabi eğer metot çalışması sırasında bir exception oluşursa bu exception’ı yine Task tipi içerisine yerleştirmek için bir de SetException metodunu bulundurmakta.

Compiler tarafından yeniden yazılan DownloadStringAsync isimli metodumuz içerisinde bir de <DownloadStringAsync>d__0 isimli bir tipin kullanıldığını görüyoruz. Bu tip te compiler tarafından yazılmış olan ve asenkron akışı tamamen içerisinde barındıran (enkapsüle eden) bir tip. Compiler tarafından yaratılmış olan bu tipin kodu ise şu şekilde.

[CompilerGenerated]
private sealed class <DownloadStringAsync>d__0
{
    // Fields
    private bool $__disposing;
    public AsyncTaskMethodBuilder<string> $builder;
    private int <>1__state;
    public string <>3__Url;
    public Action <>t__MoveNextDelegate;
    private TaskAwaiter<string> <a1>t__$await3;
    public WebClient <client>5__1;
    public string Url;

    // Methods
    [DebuggerHidden]
    public <DownloadStringAsync>d__0(int <>1__state)
    {
        this.<>1__state = <>1__state;
    }

    [DebuggerHidden]
    public void Dispose()
    {
        this.$__disposing = true;
        this.MoveNext();
        this.<>1__state = -1;
    }

    public void MoveNext()
    {
        string <>t__result;
        try
        {
            string <1>t__$await2;
            bool $__doFinallyBodies = true;
            if (this.<>1__state != 1)
            {
                if (this.<>1__state != -1)
                {
                    this.<client>5__1 = new WebClient();
                    this.<a1>t__$await3 = this.<client>5__1.DownloadStringTaskAsync(this.Url).GetAwaiter<string>();
                    if (this.<a1>t__$await3.IsCompleted)
                    {
                        goto Label_0089;
                    }
                    this.<>1__state = 1;
                    $__doFinallyBodies = false;
                    this.<a1>t__$await3.OnCompleted(this.<>t__MoveNextDelegate);
                }
                return;
            }
            this.<>1__state = 0;
        Label_0089:
            <1>t__$await2 = this.<a1>t__$await3.GetResult();
            this.<a1>t__$await3 = new TaskAwaiter<string>();
            <>t__result = <1>t__$await2;
        }
        catch (Exception <>t__ex)
        {
            this.<>1__state = -1;
            this.$builder.SetException(<>t__ex);
            return;
        }
        this.<>1__state = -1;
        this.$builder.SetResult(<>t__result);
    }
}

Compiler tarafından yaratılan tipin constructor metoduna state isimli bir int değerin parametre olarak alındığını görüyoruz. Bu state değişkeni aslında bizim asenkron metot akışımızda önemli bir yere sahip. Bu yüzden <>1__state alanını aklımızın bir köşesinde tutalım ;)

Aslında sizin de göreceğiniz üzere <DownloadStringAsync>d__0 tipi içerisinde asenkron akışı yöneten metot MoveNext metodu. Bu metot içerisinde peki neler oluyor ?

Bu metodu incelemeden önce DownloadStringAsync isimli metodumuzun içerisine geri dönelim ve yapılan değer atamalarına bir bakalım.

private static Task<string> DownloadStringAsync(string Url)
{
     <DownloadStringAsync>d__0 d__;
     d__ = new <DownloadStringAsync>d__0(0) {
          Url = Url,
          <>t__MoveNextDelegate = new Action(d__.MoveNext),
          $builder = AsyncTaskMethodBuilder<string>.Create()
      };
      d__.MoveNext();
      return d__.$builder.Task;
}

İlk olarak constructor metoda 0 değeri parametre olarak geçilmiş. Bu değer de hatırlayacağımız üzere <DownloadStringAsync>d__0 tipi içerisindeki state değişkenine atanmakta.
<>t__MoveNextDelegate isimli delegate tipine de yine <DownloadStringAsync>d__0 tipi içerisindeki MoveNext metodu atanmakta.
Daha sonra ise yukarıda incelemiş olduğumuz AsyncTaskMethodBuilder tipinin Create isimli Factory metodu çağrılarak ilgili tipten bir nesne örneği $builder değişkenine atanmakta.
Son olarak ise nesne örneği yarattıktan sonra bu örnek üzerinden MoveNext metodu çağrılmakta.

Evet şimdi MoveNext metoduna geri dönüyoruz.

MoveNext metodu içerisinde ilk çağrım sırasında state değişkenimizin değeri 0. Bu nedenle metot içerisindeki 2 if ifadesinden de geçerek aşağıdaki kod bloğu işletilmekte.

if (this.<>1__state != 1)
{
   if (this.<>1__state != -1)
   {
        this.<client>5__1 = new WebClient();
        this.<a1>t__$await3 = this.<client>5__1.DownloadStringTaskAsync(this.Url).GetAwaiter<string>();
        if (this.<a1>t__$await3.IsCompleted)
        {
             goto Label_0089;
        }
        this.<>1__state = 1;
        $__doFinallyBodies = false;
        this.<a1>t__$await3.OnCompleted(this.<>t__MoveNextDelegate);
   }
   return;

}

Çalışan koda baktığımızda bizim orjinal kodumuz içerisinde yazmış olduğumuz kodların bu kısımda olduğunu görmekteyiz. İlk olarak WebClient tipinden bir nesne örneği yaratılmakta ve akabinde de bu tip üzerinden DownloadStringTaskAsync isimli metot çağrılmakta.

Önceki yazılarımızda hatırlarsanız async & await kullanmamız için “awaitable pattern”’ı uygulamamız gerektiğinden sıkça bahsetmiştik. İşte awaitable pattern tam da kodumuzun bu noktasında devreye girmekte. Bir işlemin awaitable olması için aslında içerisinde GetAwaiter metodu ile aşağıdaki tipi döndürmesi gerekmekte.

public struct TaskAwaiter<TResult>
{
    public bool IsCompleted { get; }
    public void OnCompleted(Action continuation);
    public TResult GetResult();
}

Bu tip aslında compiler tarafında oldukça önem arz etmekte. Bunun nedeni ise compiler arka planda yani yukarıdaki kodlarda bu tip üzerinden asenkron işlemin tamamlanıp tamamlanmadığını kontrol etmekte. Eğer işlem tamamlanmadıysa OnCompleted metodunu kullanarak bir callback ataması yapmakta. Tabi birde işlemin sonucunu elde edebilmek için GetResult metodunu çağırmakta.

TaskAwaiter tipi ile ilgili açıklamamızdan sonra tekrar MoveNext isimli metoda geri dönersek artık sanırım neden GetAwaiter metodunun çağrıldığını daha fazla açıklamamıza gerek yok. :)

GetAwaiter metodunun çağrılması sonrasında elde edilen TaskAwaiter tipi üzerinden ise bir takım kontroller yapılmakta. Bu kontrollerden ilki yapılan asenkron çağrımın sonlanıp sonlanmadığı ile ilgili. Eğer işlem sonlandıysa kod akışı doğrudan Label_0089 isimli alana goto ifadesi ile yönlenmekte. Eğer sonlamadıysa öncelikle state değişkeni 1’e çekilmekte daha sonra ise TaskAwaiter tipi içerisindeki OnCompleted metodu çağrılmakta ve callback olarak ta <DownloadStringAsync>d__0 tipi içerisindeki <>t__MoveNextDelegate alanı verilmekte. Yazımızın başlarında hatırlarsanız bu alana da MoveNext metodu atanmıştı !!! . Bu da demek oluyor ki asenkron işlem tamamlandıktan sonra yine MoveNext metodu çağırılıyor olacak. Sonrasında ise return ifadesi işletilerek MoveNext metodu sonlanmakta ve kontrol çağıran koda geri dönmekte yani bizim kodumuza. Bu şekilde de aslında bizim kullanıcı arayüzümüz cevap verebilir durumda olmakta.

Şimdi asenkron çağrım sonrasında işlemin sonlandığını ve TaskAwaiter tarafından OnCompleted metoduna parametre olarak geçirilen MoveNext metodunu işlemin sonlanmış olduğunu düşünerek tekrar işletelim. Bir üstteki paragrafta state değişkenine 1 değeri atanmıştı. Bu nedenle MoveNext metodu içerisindeki if kontrolleri girmeden doğrudan devam edecek ve ilk olarak state değişkenine 0 değeri atanacak ve sonrasında da Label_0089 ismiyle etiketlenmiş kod bloğu çalışacak. Bu kod bloğu içerisinde de TaskAwaiter tipi içerisindeki GetResult isimli metot kullanılarak asenkron metodun sonucu alınmakta. Son olarak ise catch ifadesinin altında bulunan kısım işletilmekte ve state değişkenine –1 değeri atanmakta ve son olarakta AsyncTaskMethodBuilder tipi içerisindeki SetResult metodu kullanarak işlem sonucu AsyncTaskMethodBuilder tipi içerisindeki Task’ın içerisine yazılmakta.

MoveNext metoduna dikkat ettiyseniz bir de try-catch bloğu bulunmakta. Bu blok içerisinde de asenkron işlem sırasında oluşabilecek olan Exceptionlar yakalanmakta ve bir exception yakalanması durumunda state değişkeni –1’e çekilmekte ve oluşan exception da AsyncTaskMethodBuilder tipi içerisindeki SetException metodu çağrılarak AsyncTaskMethodBuilder tipinde bulunan Task’ın içerisindeki Exception alanına yazılmakta.

Genel yapıyı incelediğimizde aslında aklımıza C# dili içerisinde uzun süreden beri bulunan yield keywordünün alt yapısı gelmekte. Yield keywordü hatırlayacağınız üzere arka planda bir state machine yaratmaktaydı. C# 5.0 ile beraber gelen asenkron programlama yeniliklerinde de compiler aslında yine benzer bir yapıyı kullanarak bir state machine yaratmakta ve bu state machine içerisinde de callback atamalarını gerçekleştirmekte. Peki compiler neden bir state machine yaratmakta ? Aslında bunun durumu oldukça basit. Asenkron işlemin yönetimini kolay yapabilmek ve mevcutta bulunulan durumları saklayabilmek.

Özet olarak C# 5.0 ile gelen asenkron programlama yeniliklerinin arka planında callback tabanlı bir state machine yapısı yatmakta diyebiliriz.

Şu ana kadar Task tipinden bir nesne örneği döndüren asenkron metodun arka planını inceledik. Peki void dönüş tipine sahip olan asenkron metotlar nasıl yeniden yazılmakta ? Aslında çokta fazla bir değişiklik bulunmamakta. Bu yüzden de uzun uzadıya bir örnek yapıp incelememize gerek yok diye düşünüyorum. Aradaki tek fark AsyncTaskMethodBuilder<T> tipi yerine adından da anlayabileceğiniz üzere AsyncVoidMethodBuilder tipinin kullanımı olmakta. Compiler dönüş değeri void olduğu için herhangi bir Task tipi üretme işine girmemekte. :)

Compilerların arka olanda gerçekleştirdikleri işlemleri bilmek bazılarımıza gereksiz geliyor olsa da aslında bence oldukça önemli. Çünkü bir takım kullanımlar aslında baktığımızda bize legal olarak gözükmese de compiler arka planda bu programlama diline has özellikleri legal bir şekle sokmakta ve bu detayları da biliyor olmamız aslında bizim en doğru kullanımları yapmamızı sağlamakta. ;)

Umarım sizler için faydalı bir makale olmuştur.

Hoşçakalın,

Asenkron WCF Servis Çağrımlarında C# 5.0 ile Gelen Async & Await Kullanımı

ilkayilknur — Wed, 04 Jan 2012 22:17:00 +0200

Merhaba Arkadaşlar,

C# 5.0 ile gelecek olan Asenkron Programlama yeniliklerinin önemli bir kısmını önceki yazılarımızda inceledik. Şu ana kadar farkettiyseniz asenkron programalama yaptığımız belki de en önemli noktalardan biri olan bir konuya hiç değinmedik. Bu konu da asenkron web servis çağrıları. Özellikle Silverlight ya da Windows Phone uygulamaları gibi istemci tarafında çalışan uygulamalar geliştiriyorsanız asenkron web servis çağrısı yapmamak neredeyse imkansız. Tabi aslında asenkron servis çağrıları sadece bu teknolojiler ile sınırlı değil. WPF veya ASP.NET tabanlı web uygulamalarımızda da asenkron web servis çağrıları gerçekleştirebilmekteyiz.

Asenkron olarak yaptığımız web servis çağrılarının yanıtını almak için bildiğiniz gibi callback yöntemini kullanmaktayız. Yani asenkron olarak web servis çağrısını yaptıktan sonra kontrol bize geri dönmekte ve web servisten yanıt döndükten sonra callback olarak bildirdiğimiz kod parçası işletilmekte. Bu yöntemin dezavatajlarını, kodumuzu nasıl düzensiz hale getirdiğini ve uygulamamızın ölçeklenebilirliğini nasıl düşürdüğünü önceki yazılarımızda incelemiştik. İşte tam bu noktada web servis çağrılarında C# 5.0 ile gelen async & await ifadelerinin kullanılamayacağını sorduğunuzu duyar gibiyim :)

Bu noktada aslında web servis proxy’lerinin awaitable pattern’a göre oluşturulması bizim async & await kullanmamız için yeterli. Örnek vermek gerekirse bir web servis metodu int bir değer döndürüyorsa dönüş tipinin Task<int> tipi olması o metodun asenkron olarak işletilmesi ve yanıtının async ve await kullanılarak alınması için yeterli olmakta.

Şu anda Visual Studio içerisinde baktığımızda Add New Service Reference penceresi içerisinde yukarıda bahsettiğimiz biçimde proxy kodu üretecek bir mekanizma bulunmamakta. Bu tabi ki hiç olmayacak anlamına gelmiyor. Gelecek Visual Studio sürümünde bu özellikle geliyor olacak. Peki biz bu özelliği beklemeden asenkron web servis çağrılarımızı async ve await ile nasıl yönetebiliriz ?

Öncelikle basit bir WCF servis metodu yazalım ve ardından da bu metodumuzu WPF istemcisi tarafından çağıralım.

Yazacağımız web servis metodu oldukça basit olacak ve parametre olarak aldığı 2 sayıyı toplayarak geri döndürecek. Ancak bu işlemi yapmadan önce biz işlemi 3 saniye bekleteceğiz o şekilde metottan değeri geri döndüreceğiz. Böylece web servis metodumuz bizim için asenkron çağrı yapmak için anlamlı hale gelecek. ;) Aksi takdirde zaten 2 sayısı toplayan bir web servis metodu için asenkron çağrı yapamaya çok ta gerek yok sanki :)

İlk olarak WCF servisimizin Service Contract’ının geliştirelim.

[ServiceContract]

public interface IMathService

    [OperationContract]

    double Add(double x, double y);

Sıra geldi contract'ını belirlediğimiz WCF servisimizin implementasyonuna.

public class MathService : IMathService

{
   #region IMathService Members

   public double Add(double x, double y)

        Thread.Sleep(3000);

        return x + y;

   }
 
   #endregion

Gördüğünüz gibi metot sonucunu dönmeden önce Thread.Sleep metodunu kullanarak işlemin 3 saniye beklemesini sağladıktan sonra 2 sayıyı toplayıyıp servis metodundan geriye döndük.

WCF tarafında son olarak ise servisimizin konfigürasyonunu yapıyoruz ve servisi http://localhost/MathService endpoint’i üzerinde dışarıya açıyoruz.

<system.serviceModel>
    <services>
      <service name="MathServiceLib.MathService">
        <endpoint address="" binding="wsHttpBinding"

                              contract="MathServiceLib.IMathService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding"

                                 contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost/MathService" />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Şimdi sıra geldi WPF istemci uygulamamıza. İstemci uygulamamızın arayüzü de şu şekilde olacak.

<Grid>
   <Label Content="1. Sayı" Height="28" HorizontalAlignment="Left"

              Margin="12,12,0,0" VerticalAlignment="Top" />
   <Label Content="2. Sayı" Height="28" HorizontalAlignment="Left"

              Margin="12,44,0,0" VerticalAlignment="Top" />
   <TextBox Height="23" HorizontalAlignment="Left" Margin="81,12,0,0"

              Name="txtSayi1" VerticalAlignment="Top" Width="120" />
   <TextBox Height="23" HorizontalAlignment="Right" Margin="0,46,302,0"

              Name="txtSayi2" VerticalAlignment="Top" Width="120" />
   <Button Content="Topla" Height="23" HorizontalAlignment="Left"

              Margin="12,78,0,0" Name="btnTopla" VerticalAlignment="Top"

  Click="btnTopla_Click"  Width="75" />
   <Label  Height="28" HorizontalAlignment="Left" Margin="106,73,0,0"

             Name="lblSonuc" VerticalAlignment="Top" />
</Grid>

Arka plan kodlarına geçmeden son olarakta WCF servisimizin referansını WPF projemize ekliyoruz. Servis referansını eklerken de Add New Service Reference penceresindeki Advanced butonuna tıklayıp açılan pencere içerisindeki asenkron çağrım kodlarının da üretilmesini sağlayan checkbox’ı seçiyoruz.

Yukarıdaki gibi asenkron web servis çağrım kodlarını ürettiğimizde ilgili proxy tipi içerisinde AddAsync isimli bir metodun olduğunu göreceğiz. Bunun yanında bir de tip içerisinde AddCompleted isimli bir event bulunmakta. Şu anda elimizde var olan imkanlarla callback mekanizmasını kullanarak asenkron çağrımları gerçekleştirdiğimizi hatırlamamız gerekirse şu anda yapabileceğimiz implementasyon aşağıdaki gibi olacaktır.

private void btnTopla_Click(object sender, RoutedEventArgs e)
{

    MathServiceClient client = new MathServiceClient();

    client.AddCompleted += (_sender, _e) =>

            lblSonuc.Content = String.Format("Sonuc : {0}", _e.Result);

};

    client.AddAsync(double.Parse(txtSayi1.Text), double.Parse(txtSayi2.Text));

Peki esas konumuza geri dönersek async&await kullanarak ve callback mekanizmasını kullanmadan asenkron çağrılarımızı nasıl yönetebiliriz.

Bu noktada şu anda kullanabileceğimiz 2 yöntem bulunmakta.

Task.Factory.FromAsync

Yöntemlerimizden ilki Task tipi içerisinde bulunan FromAsync metodu. Bu metot Begin/End yapısı ile asenkronluğu sağlayan yani Asynchronous Programming Model Pattern’nına uygun olan işlemlerin Task tipi içerisine alınması ve Task tipi ile yönetilmesini sağlamakta. Böylece artık yapacağımız çağrımlarda ve diğer işlemlerde de bu metottan dönen Task tipini rahatça kullanabileceğiz.

İşte bu yöntemi kullanarak aslında proxy tipimiz içerisinde metotlara yeni bir metot ekleme imkanına sahibiz. Öyleyse hemen proxy tipimiz için bir extension metot gerçekleştirelim.

public static class Extensions

      public static Task<double> AddTaskAsync(

                         this MathServiceClient client, double x, double y)

        return Task.Factory.FromAsync<double>(client.BeginAdd(x, y, null, null),

                                        client.EndAdd);

Şimdi web servis metodumuz async & await kullanabileceğimiz duruma geldi. Yani awaitable pattern'a uydu. Öyleyse async ve await kullanarak asenkron çağrımızı gerçekleştirelim.

private async void btnTopla_Click(object sender, RoutedEventArgs e)

    MathServiceClient client = new MathServiceClient();

    double result = await client.AddTaskAsync(double.Parse(txtSayi1.Text),

                     double.Parse(txtSayi2.Text));

    lblSonuc.Content = String.Format("Sonuc : {0}", result);

Evet gördüğünüz gibi asenkron çağrımı gerçekleştirdik. Ancak uyguladığımız yönteme bakarsak bizim içim maliyetli bir yöntem olduğunu görmekteyiz. Bunun nedeni de her bir web servis metodu için yeni bir extension metot gerçekleştirmemiz. Bize aslında otomatik proxy kodu üretimi sırasında devreye girecek olan birşeyler lazım. Öyleyse gelin diğer yöntemimizi inceleyelim.

TaskWsdlImporterExtension

Visual Studio Async CTP kütüphanesini bilgisayarımıza kurduktan sonra Documents\Microsoft Visual Studio Async CTP\Samples klasörü içerisinde hem C# hem de VB ile yazılmış çeşitli asenkron programlama örnekleri gelmekte. Bu örneklerden biri de Stock Quotes isimli örnek. Bu örnek içerisinde bir istemci uygulaması tarafından WCF servis çağrılmakta ve bu servis üzerinden de hisse senedi kağıtlarının fiyatları alınmakta. Örnek içerisinde yapılan WCF servis çağrıları ise bizim örneklerimizde olduğu gibi asenkron çağrılar. Ancak burada client tarafında proxy codelarının üretilmesi sırasında bir extension kütüphanesi kullanılmış ve kullanılan extension kütüphanesi ise proje içerisine konulmuş. Bu kütüphane biz WCF servisini projemize servis referansı eklerken devreye girmekte ve proxy kodlarını async & await keywordleri ile beraber kullanılabilir biçimde yani awaitable pattern’a uygun olarak üretmekte. Şimdi bu örneği açıp derleyelim ve oluşan dll’i projemize referans olarak ekleyelim.

Şimdi bir önceki yöntemimizde projemize eklemiş olduğumuz WCF servis referansını kaldıralım ve sonrasında istemci uygulamamızın config dosyasına aşağıdaki config ayarları ekleyelim. Böylece projemize eklemiş olduğumuz extension, servis proxy kodunun üretilmesi sırasında devreye giriyor olacak.

<system.serviceModel>
    <client>
      <metadata>
        <wsdlImporters>
          <extension type="TaskWsdlImportExtension.TaskAsyncWsdlImportExtension,

                                                     TaskWsdlImportExtension" />
        </wsdlImporters>
      </metadata>
    </client>
  </system.serviceModel>

Şimdi WCF servisimizin referansını yine yukarıda yaptığımız gibi asenkron çağrım metotlarının da üretilmesi seçeneğini seçerek yeniden ekleyelim.

Referansı ekledikten sonra oluşturulan kodlara baktığımızda AddTaskAsync isimli bir servis metodu göremiyoruz. Ancak bakın AddAsync isimli metodun dönüş tipi ne oldu :)

Task<double> tipi demek bizim için awaitable demek :) Yani async & await kullanımı demek. O zaman kodumuzu yeni metot ismine göre güncelleyelim ve uygulamamızı çalıştıralım.

private async void btnTopla_Click(object sender, RoutedEventArgs e)

     MathServiceClient client = new MathServiceClient();

     double result = await client.AddAsync(double.Parse(txtSayi1.Text),

                   double.Parse(txtSayi2.Text));

     lblSonuc.Content = String.Format("Sonuc : {0}", result);

Uygulamayı çalıştırdığımızda gördüğünüz gibi uygulamamız istediğimiz gibi çalıştı. Toplama isteğini servise gönderdik ve gönderdikten sonra kontrol uygulamaya geri döndü ve sonrasında ilgili kod işletilerek yanıt ekrana yazdırıldı. Peki bu extension arka planda nasıl bir kod üretti :) Hemen metot üzerinden F12’ye basarak arka planda üretilen koda sıçrayalım :)

public System.Threading.Tasks.Task<double> AddAsync(double x, double y)

{     return System.Threading.Tasks.Task<double>.Factory.FromAsync(

          new System.Func<double, double, System.AsyncCallback,

          object,

          System.IAsyncResult>(((IMathService)(this)).BeginAdd),

    new System.Func<System.IAsyncResult, double>(((IMathService)(this)).EndAdd),

          x, y, null);
}

Siz ilk yönteme göre bir fark görebildiniz mi ? Ben göremedim :) Sadece FromAsync metodunun bir başka overload hali kullanılmış :)

Asenkron web servis çağrımları bana göre biz developerlar için en büyük sıkıntıyı oluşturan durumların başında gelmekte. Sürekli olarak callback atamaları developerlar için yönetmesi ve ölçeklendirilmesi oldukça sıkıntılı durumlar doğurmakta. Bu nedenle C# 5.0 ile beraber gelecek olan Async&Await ile artık bu sorunları da geride bırakmış olacağız.

Makalemizi sonlandırmadan Web Service Referansı ekleme sırasında bu özelliğin C#’ın 5.0 ve dolayısıyla da Visual Studio’nun bir sonraki sürümüyle beraber built-in olarak geleceğini sizlere tekrardan hatırlatmak isterim. Bu makalede işlemiş olduklarımız sadece şu anda bizlere kolaylık sağlayabilecek 1-2 trick nokta. ;)

Yazımız boyunca yaptığımız örneği aşağıdaki linkten indirebilirsiniz.

AsyncWCFCalls.zip (167,48 kb)

Bir sonraki makalemizde görüşmek üzere,

Hoşçakalın