.NET Framework 4.0’a kadar, Microsoft, .NET’in içine koymuyor, “preview” adı altında sürekli geliştirmeler yapıyordu. .NET 4.0 ile beraber artık “MEF”i gönül rahatlığı ile kullanabiliyor olacağız.

Bu kısa girişten sonra, biraz daha derinlere inelim ve “MEF”in bize neler sağladığına ve neden kullanmamız gerektiğine bakalım. Öncelike “MEF” gibi bir framework’e neden ihtiyacımız var bunu anlamamız lazım. Tekrar kullanılabilirlik(Reusability) ve esneklik(extensibility), bir yazılımın yaşam sürecinde mutlaka bir şekilde karşımıza çıkan iki kavram. Geliştirdiğimiz yazılımlar çeşitli ihtiyaçlardan dolayı, ek özellikler ile genişletilmek istenebilir. Ya da geliştirdiğimiz yazılımı başka bir konfigürasyon ya da modüller ile başka bir şekilde kullanmamız da gerekebilir. Bu iki kavramı yazılımlara uygulamak oldukça zor ve sıkıntılıdır. Hele ki mimari tasarım sırasında bu iki kavramı göz ardı ettiysek sıkıntı çok daha büyük olur. Tabi ki bir yazılım illa ki esnek ya da tekrar kullanılabilir özelliğinin olması gerekmiyor. Ancak kişisel görüşüm, yazılımın yaşam süresinin uzun olabilmesi için bu iki kavramı karşılayabiliyor olması gerekmekte.

Esneklik ve tekrar kullanılabilirlik özelliklerine sahip bir yazılım ihtiyacı çok iyi bir tasarım gerektirir. Tasarımdan sonra ki geliştirme sürecini de bu iki kavram oldukça zorlar. Bu noktada “MEF”, .NET ile uygulama geliştirenlere bu süreci biraz daha kolaylaştırmak için elinden geleni yapıyor diyebilirim.

Bir PC’yi düşünelim…Anakartı ve bu kartın üzerine takılabilen ek kartlar ile çalışabilir bir sistem…X ekran kartı ile oynayamadığımız oyunları, X ekran kartını çıkartıp, Y ekran kartını takarak oynayabiliyoruz.Bunu ekran kartlarının, anakart ile belli bir arayüz standartı ile iletişim kurabilmesinden dolayı yapabiliyoruz.

“MEF” ile de bu tarz,“plug-in” yaklaşımı olan uygulamalar geliştirebiliyoruz. Run-time’da çıkarılıp, takılabilen “plug-in”ler ile uygulamalarımızı genişletebiliyoruz. Ve bütün bunlar System.ComponentModel.Composition.dll altında bulunan metod ve arayüzler sayesinde…

Kod üzerinden gidip ilk “MEF” uygulamamızı yaparsak sanırım bazı şeyler daha anlaşılır olur.Az önce yukarıda bahsetmiş olduğum PC örneği üzerinden gidiyor olacağım. Öncelikle aşağıdaki gibi 3 tane proje yaratıyoruz. Bunlardan biri ana uygulamamız(CustomPC,konsol uygulaması), biri arayüzümüz(DisplayAdapter) ve diğeri de ana kartımız(Xvidia). (:

Bu aşamada CustomPC ve XVidia projelerine System.ComponentModel.Composition.dll’i referans olarak eklememiz gerekmekte.

Öncelikle ana uygulamamız ve ekran kartımızın iletişim kuracağı arayüzümüzü oluşturalım. DisplayAdapter projesinde IDisplay.cs isimli aşağıdaki kodu içeren bir dosya yaratıyoruz;

Bu arayüz sayesinde ana uygulamamız, “plug-in” olarak geliştirdiğimiz diğer bileşenleri çalıştırabiliyor olacak. Bundan sonra bu arayüzden yaratılan “plug-in”i geliştirebiliriz. Bir bakıma “ekran kartı”nı…(:

Bunun içinde XVidia projesinde aşağıdaki kodu yazmamız gerekmekte;

Bu noktada “Export” özelliği dikkatimizi çekmiş olmalı. “MEF”‘de “Composable Parts” diye adlandırılan ve “MEF”in temel taşı olan bir kavram var. “Composable Parts” belli servisleri(metod) dışa sunan ve belli servisleride(metod) kullanan birimler. Ana uygulamalar ve “plug-in”ler bu birimlere göre çalışmakta. Yukarıdaki kod bloğunda “Export” özelliğini kullarak, XVidia sınıfını “IDisplayAdapter” arayüzünün metodlarını dışa sunduğunu göstermiş olduk.

Şimdi sıra “plug-in”leri çalıştıracak ana uygulamamıza geldi. Bunun için CustomPC projesinde aşağıdaki kodu içeren bir dosya yaratmamız yeterli.

Ve işte bu kadar…Hemen özetliyelim ne yaptık. Bir tane “plug-in” desteği olan ana uygulama yaptık(CustomPC) ve bu ana uygulama üstünde çalışacak bir tane “plug-in” yaptık. Yaptığımız “plug-in” benzeri başka “plug-in”ler yaparak, uygulamamızı çeşitlendirebiliriz. Mesela XTI diye yeni bir ekran kartı, pardon “plug-in”….(:

Yukarıdaki CustomPC projesini çalıştırdığımız zaman hata alıyor olacağız. Peki ama neden? Bunun nedeni “XVidia” projesinin çıktısı olan *.Dll’in ana uygulama tarafına yüklenmemiş olması. CustomPC projesinin dizininde, “debug” klasörü altında “plugin” diye bir klasör açıp, “XVidia” projesinin çıktısı olan *.Dll’i kopyaladığımız zaman uygulamamızın sorunsuz bir şekilde çalıştığını göreceğiz.

“XVidia” projesinin çıktısı olan *.Dll yerine, benzer bir yapı ile oluşturulmuş bir *.Dll koyduğumuz zaman uygulamanın o *.Dll’i çalıştıracağını görüyor olacağız.

Çok basit ve güzel değil mi… .NET 4.0′ın bence en güzel yeniliği “MEF” ile entegre olması…İlerleyen yazılarda “MEF”in çok daha derinlerine dalıyor olacağım…Şimdilik bu kadar…

Ayrıntılar: http://tr.sonispherefestivals.com/

Biletler: http://www.biletix.com

Oturumlardan tek tek bahsetmeyi planlamıyorum ama genel olarak Microsoft’un çoğu ürünü ile ilgili oturumlar olduğunu söyleyebilirim. Teknik olarak çok daha güçlü bir içerik bekliyor olsamda, şu zamana kadar ki oturumlardan oldukça memnun kaldım. Bildiğim konuları pekiştirdim, bilmediğim konuları öğrendim ve öğrenmeyi öğrendim…”Öğrenmeyi” öğrendim diyorum çünkü bu tarz etkinliklerden açıkcası ilk olarak bunu bekliyorum. Konularda uzman kişiler tarafından doğru bir şekilde 1 saat boyunca yönlendiriliyor olmak bence en doğrusu…Yani sonuçta oturumlarda anlatılan konuların hiç birini bu kadar kısıtlı zamanda yalayıp yutmak imkansız…

S.Hanselman gibi(:)), Microsoft bünyesinde konularında uzman olan kişiler ile tanışmış olmak, sorularınıza cevap almak ise bu tarz etkinliklerin sanırım diğer bir güzel yanı. Problemlerinizi, düşüncelerinizi böyle bir ortamda paylaşabiliyor olmak zaten sanırım etkinliğin dayandığı temellerden biri…

Türkiye’den de katılım oldukça fazlaydı.Sanırım yaklaşık 50 kişi gelmiş…İsimlerini ne yazık ki hatırlayamadığım bir çok kişi ile tanıştım ve bilgi paylaşımında bulundum, mutlu oldum…Ama açıkcası konuşmacı olarak Türkiye’den de daha fazla isim görmek isterdim.(Konuşmacı olarak sadece Daron Yöndem vardı)

Son olarak imkanı olan herkesin ileride mutlaka bu tarz etkinliklere katılıyor olmasını tavsiye ederim. Özellikle uluslararası düzeyde olanlara şiddetle tavsiye ederim…Neyse bu şimdilik bu kadar, ilerleyen zaman içerisinde TechEd Dubai ile ilgili başka şeyler daha yazıyor olacağım… Yani umarım…(:

If you want to try it, just download it from http://www.ieaddons.com/en/details/other/Find_on_Lastfm/

And please feel free to send your feedbacks to me…

Belki benden tecrübeli meslektaşlarım biraz kızacak ve hatta ne saçmalıyorsun falan diyecektir. Ama açıkcası “Design Patterns”(Tasarım kalıplarının) direk olarak mimari yaklaşımlar ile alakalı olduğunu düşünmüyorum, aslında düşünmediğim gibi, kendi tecrübelerimden,okuduklarımdan, öğrendiklerimden görüyorum da…

“Design Patterns”(Tasarım kalıpları) hakkında internette bir çok kaynak var. Çoğunda belli kod parçacıkları ile örnekler ile ne amaçla kullanacağımızı falan anlatılıyor.Süper, mükemmel…Ama erken…Daha kod yazmaya başlamadık ki…

Madem böyle kalıp falan başladık bahsetmeye, bu yazının amaçı olan “Architecture Patterns(Sytles)”’e(Mimari Kalıplara) geçelim.Çeşitli kaynaklarda mimari sitiller, bazılarında da mimari kalıplar şeklinde geçer, ama yazılımcıların bakış açısından daha kolay anlaşılacağını düşündüğüm için bende kalıp olarak kullanacağım. Önceki yazılarda da bahsettiğim ihtiyaçlar doğrultusunda şekillenecek(şekillenmesi gereken) mimarimizi, belli tecrübelerden, teknolojik açılardan ve belli limitlerden dolayı belli kalıplar dahilinde şekillendirmemiz bize yardımcı olabilir. Kurabiye yaparken kullanılan kalıplar ya da kumdan kaleler yaparken kullandığımız kovalar gibi…

Bu bağlamda, ne olduklarının çok farkında olmadığımız ama sık sık kullandığımız kavramlar ortaya çıkıyor. Mimari kalıplar…

Mimari kalıplar, geliştireceğimiz sistemlerin ya da yazılımların ihtiyaçlarımız doğrultusunda çok daha etkili çalışabilmesini sağlayacak ve mimarimizi geliştirirken bize yol gösterecek kalıplardır. Çok daha iyi anlaşılması adına aşağıdaki gibi bir liste yaparsam daha iyi olur sanırım.

• Bileşen tabanlı mimari
• Katmanlı mimari
• P2P mimari
• UI tabalı mimari
• Mesaj bazlı mimari
• Servis tabanlı mimari
• Event tabanlı mimari

Yukarıda bazı popüler mimari kalıplardan örnekler var. Daha çeşitlenebilir tabi ki. Bunları tek tek şuan için açıklamayı düşünmüyorum. Bu noktada mimari kalıpların neden önemli olduğunu anlatmak istiyorum. Mimari kalıplar, ihtiyaçlarımızı daha net bir şekilde karşılamamızda bize yol gösterir. Ayrıca ihtiyaçlarımızı karşılarken, hangi yöntemleri kullanabiliriz bunları sunar. Bu kalıpları ayrı ayrı düşünüyor olmak biraz hatalı olabilir. Direk olarak kesiştirmek de hatalı olur. Mimari tasarımı yaparken, ihtiyaçlarımızı bu kalıplar doğrultusunda çerçeveleyip tasarımımızı yapmak çok daha sağlıklı sonuçlar getirecektir. Ayrıca bu kalıpların kendi içlerindeki kanıtlanmış yöntemler, sizi bir çok şeyden kurtarıyor da olacaktır.

Son olarak tekrardan “Design Patterns”-tasarım kalıplarının, mimari tasarımla direk alakası olmadığını söylemek istiyorum. Bu karıştırmadan dolayı kavramların da karıştığını görüyorum. İlerleyen yazılarda yine bu konulardan bahsediyor olacağım…Şimdilik bu kadar…

“Software Design” ve “Software Architecture Design” iki farklı kavram aslında. Bu iki kavramın karıştırılıyor olması, mimari kavramların kaybolmasına neden oluyor ne yazık ki. Bundan dolayı “Tasarım”(Design) ve “Mimari”(Architecture) kavramlarının arasındaki sınırı çok iyi anlamamız gerekmekte. Tüm mimari yaklaşımlar aslında bir tasarımdır. Ama bu tasarım, “Yazılım Tasarımı”(Software Design) daki tasarım değil. Mimari olarak yaklaştığımız zaman, “tasarım” kavramı çok daha yukarıdan bakmamızı gerektiren bir kelime olarak karşımıza çıkıyor. Bir yazılım ya da sistemdeki bileşenlerin nasıl organize olduğu ve ilişkilendirildiği, o sisteme ya da yazılıma “Mimari” açıdan yaklaşımı gösterir. Bu bileşenlerin nasıl sınıflandırıldığı ve ayrıştığı ise “Tasarımı” olarak açıklanabilir. Biraz daha basite indirgememiz gerekirse, yazılım geliştirirken bileşenlerimizi  “sınıf”(class)’lara ayırmamız, bu “sınıf”lar arasında ilişkileri belirlememiz “tasarım” kavramının konusu. Ama bileşenlerimizin(component) nasıl ilişkilendirileceği de “mimari” kavramının konusu.

Açıkcası kendi geliştirdiğim yazılımlarda, bu iki kavramın ayrımını fark ediyor olmak geliştirme sürecini daha sağlıklı hale getiriyor.Bir yazılım geliştirmeden önce hepimizin yapmış olduğu bir tasarım mutlaka vardır. İşte bu tasarım süreci  mimari tasarıma denk geliyor aslında. Ve yazılım geliştirme sürecinde herkesinde bildiği gibi çok önemli bir yer kaplıyor. Bu süreçte dikkat edilmesi gereken bir çok önemli nokta var.Bunlardan bence en önemlilerini kendimce anlatmaya çalışacağım;

• Sınırlar: Tasarım sürecinde, geliştirmemiz gereken yazılımın ya da sistemin ihtiyaçları ve neden gerekli olduklarını kesinlikle unutmamak lazım. Ve ihtiyaçtan fazlasını düşünmememiz lazım. Açıkcası bunu sürekli yaşıyorum. İster istemez yazılımın olabildiğince geniş bir kapsamı olması, ya da “genişletilebilir” kalite özelliğinin hem tasarım hemde geliştirme sürecinde öne çıkması kötü tasarımlara yol açıyor. İş gereksinimleri dışında, tasarımı karmaşıklaştıracak etkenleri tasarıma sokmamak ve ihtiyaçlarımız doğrultusunda sınırlarımızı aşmamak lazım.
• Bileşenlerin Ayrılması: Tasarımı yaparken, bir birinden farklı tüm fonksiyonel özellikleri belli bileşenler olarak ayırmak tasarımın karmaşıklığını önleyecektir, ayrıca ihtiyaçların gerçekten karşılanabiliyor olmasının gözlemlenmesine ve bileşenlerin tek başlarına ne işe yaradıklarını da anlamaya yardımcı olacaktır.Literatürde “Separation of Concerns” olarak yer alan bu kavram, geliştirme sürecindeki tasarım kalıpları ile ne kadar önemli olduğunu zaten belli edecektir.  Dolayısıyla geliştirme sürecinde sonradan fark etmek yerine, başlangıçta bu yaklaşıma göre yapılacak tasarımlar faydalı olacaktır.
• Bileşim(Composition) ve Kalıtım(Inheritance): Bu iki kavramın çok iyi anlaşılıyor olması gerekmekte. Çünkü geliştirilecek sistemin ya da yazılımın bileşenleri üzerinde bu iki kavramın çok büyük etkisi olacaktır. İhtiyaca göre bu iki yaklaşım doğru çizilmelidir.”Kalıtım”(Inheritance) bileşenler üzerinde bağımlılığı artıracağından, hangi bileşenlerin bir birleri ile alakalı olacağı ilişkisinin çok iyi tanımlanması gerekmekte. Öte yandan “Bileşim”(Composition) bileşen kavramını daha netleştirecektir.
• Katmanlar(Layers): Geliştirilen sistem ya da yazılım da, bileşenler arasındaki ilişikileri görmek ve yönetmek adına sistemi ya da yazılımı katmanlara ayırmak tasarımı kolaylaştıracak ve temelini güçlendirecektir. Bu şekilde katmanlara ayırmak sistemdeki akışın yolunuda görmenize yardımcı olacaktır.

Mimari tasarımı yaparken bu tarz şeylere dikkat ediyor olmak, cidden bazı şeyleri çok daha net ortaya çıkarıyor ve sağlıklı bir geliştirme sürecinin ilk ışıklarını gösteriyor. En azından kendi tecrübelerime dayanarak bunu söyleyebilirim.Kendi tecrübelerim ve bilgilerim dahilinde “Mimari Tasarım” ve “Yazılım Tasarımı” arasındaki farkı anlatmaya çalıştım. Hatta biraz da “Mimari Tasarım”a daldım…Umarım faydalı olmuştur.İlerleyen zamanlarda bu konular hakkında daha çok yazıyor olacağım. Her türlü eleştiriniz ve düşüncenizi lütfen paylaşmaktan çekinmeyin. Bu kavramlar böyle böyle ortaya çıkıyor ve gelişiyor…Haydi görüşmek üzere…

Ayrıntıları buradan okuyabilirsiniz…

Edit: http://code.google.com/apis/buzz/ adresinden de API’si ile ilgili bilgileri takip edebilirsiniz…

Yazılımda mimari yaklaşımlar, yazılım mimarisi, mimari modeller, mimari tasarım bu olayların içerisinde olduğumdan beri en çok ilgili çeken konular. Genellikle çözülmesi gereken olaylara, sebeplerini, oluşum süreçlerini ve nasıl çözülürse ne olur gibi yaklaşımlarla yaklaştığım için sanırım bundan dolayı da yazılım mimarisi kavramına olan ilgim arttı;üniversite de bu konu ile ilgili aldığım derslerin de etkisi yok değil.
Peki nedir bu yazılımda ki mimari ya da yazılım mimarisi?

Yazılım mimarisi en basit ve temel şekilde, bir sistemi oluşturan yapılar ve bu yapıların birbiri ile olan ilişkileri olarak tanımlanabilir. Ancak çok ucu açık ve geniş bir tanım olduğundan biraz daha derinlere inip kurcalamakta fayda var. Bu noktada L. Bass, P. Clements, ve R.Kazman beraber yazdığı “Software Architecture in Practice“(bu kitabı şiddetle tavsiye ederim.Mutlaka okunmalı.) kitabından bir alıntı yaparak başlamak istiyorum.(-ki bir çok kaynakta da zaten bu alıntı vardır.) Bu tanımlama bence yazılım mimarisinin en açık ve anlamlı tanımı.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.

Kendimce biraz daha anlayabileceğim şekilde yorumlamak açıkcası bu kavramları daha iyi anlamama yardımcı oluyor.Bu bağlamda bende “Yazılım mimarisi: bir yazılımın(sistemin); teknik tüm ihtiyaçlarını, iş kuralları dahilinde, operasyonel tüm ihtiyaçlarını belli kalite gereksinimlerini de göz önüne alarak ortaya çıkmış yapı ya da yapıların ilişkiler halinde bulunduğu bütünüdür” diyebilirim. Bu yapıları ele alırken aralarındaki ilişki(ler) ise mimarinin temelini ve modelini oluşturur. Ve bu noktada bu ilişkilerin ne yazık ki göz ardı edildiğini ve mimari yaklaşımdan uzaklaşmamıza sebep olduğunu düşünüyorum. Ne demek istediğimi ileride netleştireceğim.
Peki cidden gerekli mi?Olmazsa ne olur?

Aslına bakarsanız gerekliliğinin sorgulanabileceğini bir kavram olduğuna inanmıyorum yazılım mimarilerinin. Yani yukarıda bahsettiğim tanımlamaları düşünmeden bile bir yazılım ortaya çıkarmaya çalışabilir ve hatta başarılı olabiliriz. “Yapmadan” kelimesi yerine “Düşünmeden” kelimesini seçmemin önemli bir noktası var. Bir yazılım geliştirirken her ne kadar mimari açıdan fazla kurcalamasakta, yazılımın var oluş sebepleri, mimari yaklaşım içerisinde olduğundan ortaya çıkacak yazılım sistemlerinin mimarisi yok diyemeyiz. Kısaca geliştirilen her türlü yazılımın bir mimarisi zaten doğası gereği var. Bu noktada yazılım mimarisinin gerekliliğinden çok, neden ihtiyaç duyduğumuzu düşünürsek daha anlamlı sonuçlara varabiliriz.
İyi…Peki o zaman, neden ihtiyaç duyuyoruz?

Bir yazılım geliştirmeye neden ihtiyaç duyuyorsak aynı sebepten. Biliyorum biraz karışık oldu ama aslında temelinde bu yatıyor. Belli ihtiyaçlarımızdan dolayı gereksinim duyduğumuz yazılımları geliştirirken, bu ihtiyaçları elimizden geldiğince yazılım için anlamlaştırmamız(soyutlaştırmamız) ve kesinleştirmemiz gerekmekte. İhtiyaçlarımızı, yazılım açısından daha belirgin hale getirmek için mimariye bu noktada ihtiyaç duyuyoruz. Bu noktada mimari modeller ve mimari sitiller zaten karşımıza çıkıyor. İhtiyaçlarımızdan farklı olarak da operasyonel veya teknik anlamda bazı kavramları da daha net görmek adına mimari yaklaşıma ihtiyaç duyuyoruz. Aşağıdaki gibi maddelendirip özetlemek biraz daha yardımcı olacaktır.

• Sistemimizi oluşturan yapıları daha net görmek için ve hangi yapılara ihtiyaç var belirlemek için
• Sistemi oluşturan yapılar arasındaki ilişkileri sağlıklı kurabilmek için
• Sistem ihtiyaçlarını karşılamak için
• Sistem maliyetini düşürmek için
• Oluşturabileceğimiz sistemi başka sistemler ile ilişkilendirebilmek için
• Sistemi paylaştırebilmek için

Uzun zamandır takıntılı olduğum bu konularda, kendi düşüncelerim ve tecrübelerimi paylaşmaya çalışacağım. Öğrendiğim, takip ettiğim tüm kaynakları da buradan paylaşacağım. Ve lütfen bu konulardaki tüm düşüncelerinizi sizde paylaşıyor olun, ya da zaten paylaşım içindeyseniz beni de dahil edin .Açıkcası bu tarz şeylere dikkat ettiğimizi ve bu açılardan yaklaşarak geliştirme yaptığımızı pek sanmıyorum bundan dolayı da bu tarz kavramların bu şekilde gelişeceğine inanıyorum. Şimdilik bu kadar…