Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…

MEF(Managed Extensibility Framework) ile ilgili geçenlerde küçük bir soru ile karşılaştım. Burada da bahsetmek isterim. Ama önce MEF nedir, ne değildir hatırlamak isteyenlere önceki yazılara bir göz atmalarını tavsiye ederim…

  1. MEF ile esneklik kazanıyoruz…
  2. MEF’de “Part”lara kendi “metadata” bilgilerimizi nasıl ekleriz acaba?
  3. MEF’i basit bir WPF uygulaması ile daha iyi anlıyoruz…
  4. Managed Extensibility Framework(MEF)’de ki kataloglar…
  5. Asp.Net MVC Framework’de MEF ile Controller eklentileri…

Neyse gelelim, soruya… MEF alt yapısını kullanarak, uygulamalarızı genişletirken, “Part”ları [Export] özelliğini kullanarak belirtiyoruz. MEF’in olmazsa olmaz, en önemli özelliği aslında. Bununla ilgili olarak,  “Her geliştirilen “Part” bu şekilde [Export] özelliğine sahip olmalı mı,tek bir ortak yapı ile olmaz mı?” manasında bir soruydu gelen. Hemen bakalım…

MEF alt yapısı ile uygulamalarımızı genişletmek için kullandığımız parçaları mutlaka tanımlamamız lazım. MEF’deki kataloglar ve konteynırlar bu tanımlamalara göre oluşturduğumuz parçaları yaratıyor ve ayağa kalkmasını sağlıyor. Bildiğiniz üzere de [Export] bunu sağlayan özellik. Ama her parçaya bunu yazmak pek tercih edilen bir yöntem olmayabilir. Bu da aslında temel olarak iki sebepten olabilir. Bir tanesi MEF alt yapısını dışarısı ile paylaşmak istememek, bir diğeri de tüm koduna müdahele edemediğimiz uygulamaları genişletme ihtiyacı…

Öncelikle normalde nasıl yaptımızı hatırlayalım. Aşağıdaki kod örneği sanırım bunun için yeterli olacaktır.


    public interface IPlugin
    {
        void Execute();
    }

    [Export(typeof(IPlugin))]
    public class PluginA : IPlugin
    {

        public void Execute()
        {
            throw new NotImplementedException();
        }
    }

    [Export(typeof(IPlugin))]
    public class PluginB : IPlugin
    {

        public void Execute()
        {
            throw new NotImplementedException();
        }
    }

Burada her IPlugin arayüzünden geliştirilen, “Part”a, [Export] özelliğini yazmak yerine, BasePlugin şeklinde bir temel sınıf olup, “Part”ların o sınıftan türemesi istenebilir. Böylece “PlugX” şeklinde geliştirilen her sınıf, hem belli standart özellikleri sağlıyor olur, hem de [Export] özelliği o sınıf tarafından yönetilebilir. Ayrıca tüm koduna müdahele edemediğimiz, ama belli bir sınıftan türeyen sınıfların, MEF Part’ları olarak yorumlanmasını da istersek, bu belli sınıfa sadece bir özellik ekleyerek, yazılımcıdan “Part” kavramını soyutlayabiliriz.

MEF’de bunun için [InheritedExport] özelliği sunuyor.  Sadece bir sınıf ya da arayüze [InheritedExport] özelliği eklemek, bunlardan türetilen tüm sınıfların “Part” olarak yorumlanmasını sağlayacaktır. Bu sayede Export özelliği tek bir yerden yönetmek mümkün olacaktır.


    [InheritedExport(typeof(IPlugin))]
    public abstract class BasePlugin : IPlugin
    {

        public void Execute()
        {
            Process();
        }

        public abstract void Process();
    }

    public class PluginA : BasePlugin
    {

        public override void Process()
        {
            throw new NotImplementedException();
        }
    }

    public class PluginB : BasePlugin
    {

        public override void Process()
        {
            throw new NotImplementedException();
        }
    }

Bu basit ama bir o kadar da anlamlı özellik, kodun kirlenmesinin de önüne geçiyor diye düşünüyorum. MEF ile çalışmayı düşünen ya da çalışanlar için umarım faydalı olur.

4 Nisan 2015, Cumartesi günü 9.su düzenlenecek olan .Nedirtv Yazılım Teknolojileri etkinliği bu sefer biraz daha yoğun geçecek…Yok yok, o derece… Yine ücretsiz gerçekleşecek olan etkinlikte, bu sene paralel oturumlar ile, Big Data’dan, uygulama güvenliğine, TDD’den, Mobile uygulama geliştirmeye kadar farklı bir çok konu var. Oldukça keyifli bir ortamın olacağı garantisini de şimdiden verebilirim…Kaçırmayın derim…

Etkinlik ile ilgili ayrıntıları ve katılmak için kayıt işlemini http://nedirtv2015.eventbrite.com/ adresinden gerçekleştirebilirsiniz.

afisnedirtv

 

 

15 Mart‘da İstanbul’da şahane bir teknoloji etkinliği var… Women Techmakers Istanbul 2015 adı altında, GDG Istanbul grubunun ön ayak olduğu bu etkinliğin oldukça geniş bir içeriği var. Tek gün olmasına rağmen, paralel oturumlar ile bir birinden değişik, özel ve güncel konuları bulabileceksiniz. Bu etkinliğin bir diğer önemli noktası da, anlatılacak konuların, konusunda uzman kadınlar tarafından aktarılacak olması. Keşke bunun özel bir durum olmadığı bir dünyada, özellikle ülkede yaşıyor olsaydık. Cinsiyet ayrımı olmadan, farkındalığı insanların yarattığı bir ülke için, teknoloji sektöründe olan herkese bu etkinliği tavsiye ederim. IBM’den, Turksat’a, Monitise’dan, ThoughtWorks’e kadar bir çok farklı şirketten çok farklı şeyler duyacağınızı garanti ediyorum…

Ayrıntılı bilgi, program ve kayıt için http://wtmistanbul.com/ adresini ziyaret edebilirsiniz.

womentechWomen Techmakers Istanbul 2015
15 Mart 2015 @ 8:30
Yer: Bahçeşehir Üniversitesi,Beşiktaş
KAYIT OL

 

Programa kısaca göz atmak isterseniz, aşağıdaki resime tıklamanız yeterli…Program

“Agile yöntemlerden beklediğimiz faydayı alamıyoruz. Agile yöntemlerden maksimum düzeyde nasıl kazanç sağlarız?”

13-14-15 Mayıs tarihlerinde İstanbul’da, Agile Fluency™ Model ile ilgili oldukça güzel bir workshop var. Scrum Turkey‘in düzenlediği bu workshop ile yukarıdaki sorunun cevabını, en doğru kişiden, Diana Larsen’den alma şansına sahip olacaksınız. Diana Larsen ve Steve Holyer‘ın katılımı ile gerçekleşecek bu 3 dolu gün ile ilgili ayrıntıları bu adresten takip edebilirsiniz. Oldukça profesyonel ve dolu bir içeriğe sahip olacak bu etkinliğin ücreti Nisan ayının başına kadar indirimli. Bu indirimden faydalanmak ve kısıtlı sayıdaki katılımcılardan biri olmak için elinizi çabuk tutun derim… Açıkcası biraz reklam gibi oldu ama konusu itibari ile ve Türkiye’de Agile yöntemlerin yeni yeni anlaşılıyor ve kabul ediliyor olması açısından, oldukça faydalı ve önemli bir workshop olduğunu düşünüyorum. Agile Transformation süreçine giren firmalara şiddetle tavsiye ederim…

 

 

Nisan ayında İstanbul’da oldukça güzel bir etkinlik haberim var. 27 Nisan günü Kadir Has Üniversitesi‘nde paralel oturumlar ile gerçekleşecek Istanbul Tech Talks, içerik olarak oldukça farklı ve zengin bir içeriğe sahip. SoundCloud, Facebook, Coursera gibi firmalardan gelen katılımcılar ile bütün gün sürecek etkinliğin katılım ücreti 15 Mart’a kadar 25$. Etkinliğe katılmak için bu adresten kayıt olabilirsiniz.

Etkinlik sitesi : http://www.istanbultechtalks.com

Istanbul Tech Talks Agenda

“Implicit” ve “Explicit” kelimeleri, C# ile geliştirme yapan herkesin zaman zaman oldukça kullandığı kavramlar. Tipler arası çevrimler için tercih ettiğimiz iki farklı yöntem aslında…”Implicit Conversion” ve “Explicit Conversion”. Hatırlamak adına aşağıdaki kod örneği yeterli olacaktır sanırım. Syntax olarak aralarındaki fark, Explicist Conversion’da “(type)” şeklinde cast operatörünün olması.

Implicit Conversion

            int number = 3;
            double doubleNumber = number;

Explicit Conversion

            double average = 4;
            int avg = (int)average;

Oldukça basit ve tanıdık, değil mi… Bu noktadan itibaren bu cast işlemlerini, operatör overloading’e benzer bir şekilde nasıl kendi objelerimiz için yapabiliriz bundan bahsetmeye çalışacağım. Açıkçası çok tercih edildiğini düşünmüyorum, ama yeri geldiğinde bir kaç problemi çözmede yardımcı olabilir.

Geliştirilmesine müdahale edemediğimiz ve artık geliştirilmeyen kütüphaneler ile geliştirilmiş legacy sistemlere müdahale etmemiz gerektiğini düşünelim. Her yazılımcının rüyası…Daha doğrusu kabusu. Neyse…Bu kütüphanelerdeki tipleri, kendi geliştirdiğimiz yeni tiplere çevirmemiz gerektiğinde, çeşitli Helper sınıfları ve metodları ile “conversion” işlemlerini yapabiliriz. Buna ek olarak, conversion(cast) operatörünü kullanarak da basitçe yapabiliriz.

Aşağıdaki gibi bir birinden bağımsız iki tane sınıfımız olsun. Burada bağımsız derken Dolar sınıfı, XYZ assembly’sinde, TL sınıfı da ABC assembly’sinde olsun…Ve TL sınıfı bizim geliştirdiğimiz yeni bir sınıf olsun. Yani biraz daha kontrolü bizde. Bu şekilde bir senaryo ile çözüm sağladığı nokta daha iyi anlaşılabilir diye düşünüyorum.

    public class Dolar
    {
        public double Value { get; set; }
        public string Sign { get; private set; }

        public Dolar(double v=0)
        {
            Sign = "$";
            Value = v;
        }
    }

    public class TL : Currency
    {
        public double Price { get; set; }
        public string Sign { get { return "₺"; } }
    }

    public abstract class Currency
    { 

    }

Dolar sınıfından yarattığımız bir nesneyi, TL sınıfından bir nesneye çevirmek istediğimizde aşağıdaki gibi bir cast işlemi ile yapabiliriz. Ama tabi ki Dolar sınıfı, TL sınıfından türemediği için hata alırız.

    class Program
    {
        static void Main(string[] args)
        {
            Dolar dolar = new Dolar(250);
            TL test = (TL)dolar;

        }
    }

Burada yapmaya çalıştığımız aslında “Explicit Conversion”. Ama cast operatörü diyebileceğim “(type)” operatörü bu tipler için geçerli olmadığından, “Cannot convert type” hatasını alıyoruz.

cast

Devam

Geçtiğimiz sene .NET Core adı altında, .NET Framework’ün bir kısmı yeniden düzenlenip açık kaynak olarak yayınlandı. Cloud platformuna daha uygun, scale edilebilecek modüler bir framework olması, farklı platformlarda da çalışabilmesi(Linux, Mac OS X) ve açık kaynak olabilmesi için böyle bir düzenlemeye gidildi. Öncesindeki .NET Framework’ün client-server versiyonları ve PCL(Portable Class Library) yaklaşımları bu amaçlara kısmen hizmet etmeye çalışsa da, “tek” bir kod alt yapısı üzerinde olmuyor olması yönetmeyi zorlaştırıyordu. Kısacası, temel olarak açık kaynak olabilmesi, cloud’da modüler bir şekilde çalışabilmesi, tek bir kod alt yapısı olması ve farklı OS ortamlarında da çalışması için .NET Core oluşturuldu. Burada özellikle belirtmek isterim ki, .NET Core != .NET Framework

Bahsetmiş olduğum ihtiyaçlar, .NET Framework ilk çıktığında ortada olan kavramlar olmadığından dolayı, bu ihtiyaçları mevcut .NET Framework tarafında yapmanın zorlayıcı olacağından böyle bir yaklaşım ortaya çıkıyor. .NET Core’u,  bir nevi .NET Framework’ün refactor edilmiş hali olarak da düşünebiliriz.

.NET Core’dan önce Windows uygulamaları, mobil uygulamalar ve Asp.Net uygulamaları, teoride aynı .NET Framework alt yapısını kullansada pratikte böyle değildi. .NET’in içindeki PCL, Code Contracts gibi kavramlar ile framework içindeki kodlar çeşitli durumlara göre ayrışıyordu. #if Mobile #endif gibi ifadeler ile aynı kod içinde farklı ihtiyaçlara karşılık veriliyordu. Bu da modülerlik problemine yol açıyordu. .NET Core ile beraber bu ortadan kalkıp, tüm uygulamalar için, yukarıdaki bahsettiğim ihtiyaçları da karşılamak adına, BCL(Base Class Library) tarafında da iyileştirmeler ile tek bir ara katman sağlanıyor artık.

bcl

Bütün bunlar tabi .NET Framework’ün artık atıl kalacağı anlamına gelmiyor. .NET Framework hala temel uygulama platformu. Mesela WPF,Windows Forms,WF,WCF gibi kavramlar .NET Framework’ün içerisinde olup, .NET Core tarafında olmayan parçalar.
net2015

.NET Core ve .NET Framework’ün bir diğer önemli farkı da, .NET Core’un, modülerlik ihtiyacından dolayı NuGet paketleri üzerinden yayınlanıyor olması. Bu noktada tek bir paket olmadığını, .NET Core içerisindeki çoğu bileşenlerin ayrı ayrı NuGet paketleri olarak yayınlanacağının da altını çizmek isterim. Yaşasın modülerlik… Ama tabi ayrıca offline installer’lar ile de bu paketlere belli versiyonlar ile ulaşmak mümkün olabilecek.

.NET Core’un en büyük özelliği de cross-platform olayının, bu sayede resmi olarak desteklenmesi. Mono sayesinde, Mac OS X ve Linux platformalarında .NET uygulamalarını çalıştırmak kısmen mümkün olabiliyordu. Ama bunların geleceği net olmadığı için, bu platformlarda .NET teknolojilerine pek yatırım yapılmıyordu. .NET Core’un iyice olgunlaşım bu plaftormlar için Microsoft tarafından resmi olarak destekleniyor olması, uzun vadede bu yatırımları arttıracaktır diye düşünüyorum.

Ve açık kaynak…

.NET Core’un ihtiyaçlara daha çabuk adapte edilebilmesi adına, bu oluşumu direkt olarak açık kaynak bir proje olarak yayınladı Microsoft. Bu sayede, herkes kodlara göz atıp, istediği şekilde düzenlemeler,geliştirmeler yapabiliyor artık. GitHub üzerinden yayınlanan kodlara katkıda bulunmak için tabi, uyulması gereken bazı kurallar ve sonrasında da denetlemeler var.

.NET CoreCLR

.NET Core’un çalışması için de parallelinde CoreCLR diye de bir runtime modeli de oluşturuldu haliyle. .NET Framework’deki Common Language Runtime(CLR)’a benzer olarak düzenlenen CoreCLR, .NET Core ile geliştirilen uygulamaların çalışmasını sağlayan temel bileşen. Ve dün bu bileşen de açık kaynak olarak yine GitHub üzerinden yayınlandı. Açıkcası runtime’ın bu şekilde yayınlanıyor olması çok önemli. Farklı platformlardaki gelişmelerin önünü açacağına inanıyorum. Bekleyip göreceğiz.

2015, .NET tarafında bir çok değişikliğe ev sahipliği yapacak bir yıl olacak. Bakalım bu değişiklikler bize neler getirecek, bizden neler götürecek…

Bu arada tüm bu değişiklikleri aşağıdaki GitHub adreslerinden takip edebilirsiniz.

.NET Core – https://github.com/dotnet/corefx
.NET CoreCLR – https://github.com/dotnet/coreclr