Microsoft .NET çalışma mimarisi
Burada bahsedeceklerim ".NET mimarisi" konusunda yapacağınız araştırmalarda karşılaşacağınız metinlerden çok da farklı olmayacaktır. Buradaki amacım Visual Studio çalışma ortamında C#'da yazdığınız bir console uygulamasındaki console.writeline("merhaba dünya"); kod satırını çalıştırırken arka planda dönen senaryoyu kavramak ve bundan sonra yapacağımız çalışmalarda neyi ne için yazdığımızın ve nasıl çalıştırıldığının farkında olmak. Bu konu geliştirici (developer) adayları için yaptıkları işe hakim olmaları açısından önemlidir diye düşünüyorum. .NET Frameworkün temelleri ile ilgili bilgilere yer verirken programlama dillerinin kısa bir tarihine ve bir yazılımın taşınabilirliği konusuna değinmekte yarar görüyorum.
1960 ve 1980'li yıllar arasında (Java'dan önce) yazılan programların sadece o makinaya ve işlemciye özgü yazıldığı ve programın başka bilgisayara taşınıp, farklı sistemlerde çalıştırılmasının mümkün olmadığı yıllardı. C dilinin geliştirilmesi ve nesne yönelimli programlama düşüncesine uygun olarak geliştirilen C++ uzun yıllar programlama dünyasında kendisinden söz ettirecekti ve 80'li yıllarda C++'ın ortaya çıkışı programlama dünyasına yeni bir soluk kazandırmıştı. Ancak platformdan bağımsız hareket etmek hala mümkün değildi. Sun Microsystems bu duruma el koymuş, JAVA'yı ortaya çıkarmıştı. Artık yazılımların işletim sistemlerinden bağımsız çalışması mümkündü. "Bir defa yaz her yerde çalışsın" sloganı heyecan vericiydi. Tabi Java Virtual Machine kurulması şartıyla.
Peki JVM neydi ? Java'da hazırlanmış bir uygulamanın kodları öncelikle her işletim sistemi için aynı olan "byte code" lara dönüştürülüyordu. Bu "byte code" ları işletim sistemine göre yorumlayacak bir mekanizmaya ihtiyaç vardı. İşte JVM bu "byte code"ları çalıştırılan işletim sistemine göre dönüştürme işlemini yapıyordu. Buradan çıkarılan sonuç da JVM'nin kurulu olduğu her sistemde yazılan JAVA uygulamasını çalıştırabiliyor olunmasıydı. Ancak farklı diller için böyle bir çözüm paketi yoktu. Projeniz Java dışında bir dilde hazırlanıyorsa bu projenin farklı platformlarda çalışması için ne yapmak gerekiyordu ? Peki Sun Microsystems JVM ile bir çözüme giderken Microsoft 1990'lı yıllarda ne yapıyordu ? Windows işletim sistemleri için yazılımlar nasıl üretiliyordu ve nasıl dağıtımı yapılıyordu ?
1990'lı yıllardan 2000'e kadar olan zaman döneminde windows için yazılım geliştirmek isteyenler COM teknolojisini kullanıyordu. .NET Framework yapısı oluşmadan önce başlangıçta yalnızca C++'da geliştirilen ve object oriented yapısına uygun olarak hazırlanan "bileşen tabanlı" bir yazılım geliştirme mimarisi yapısı vardı. Buna göre farklı programlama dilleri ile hazırlanacak olan kütüphaneler ve çalışmalar bir projeye dahil edilip derlenip, dağıtılabilirdi. Aynı kütüphaneyi kullanan birden fazla yazılım aynı makinaya kurulurken de o kütüphaneyi tekrar tekrar program ile birlikte yüklenmesi anlamına geliyordu. Bu da diskin verimsiz bir şekilde kullanılması anlamına geliyordu. Bu sorunun çözümü dynamic link library ile çözülmüştü. DLL olarak ifade ettiğimiz bu program dosyalarını yazılım projesi ile birlikte tamamen derlemeyip ihtiyaç duyulduğunda çağırılıp içindeki kod parçaları çalıştırılıyordu. Ancak burada bir başka problem her programcının aynı derleyici ile çalışmamasından dolayı ortaya çıkıyordu. Çünkü C++'ın farklı farklı derleyicileri obje olarak derlenen bir classın içindeki fonksiyon isimleri ve döndürdüğü değerlerin dll'e nasıl yerleştirileceği ile ilgilenmiyordu. Oysaki bunun belli bir standartta olması gerekir ki C++ ile çalışan bir başka programcı bu uygulamayı projesine dahil edip çalıştırabilsin.
Sorunlar bunlarla sınırlı değildi tabi. Windows95 ve 98 döneminde programların kurulum yapılarını hatırlayacak olursak kurulum sonrası klasörlerini açıp baktığımızda pek çok dll dosyasının diske kaydedildiğini görürdük. Ayrıca windows klasörü altında da bu dll dosyaları kopyalanırdı ve içlerinden birinin silinmesi durumunda ya da zarar görmesi durumunda program çalışamazdı. Hatırlarsanız bu programların klasörlerini kopyalayıp başka bir bilgisayara taşıdığımızda da çalıştıramaz; dll hataları alırdık. Sebebi de dll dosyalarının sisteme register edilmemiş olmasıydı. O dll dosyalarını taşısak bile işletim sistemi onları tanımıyordu. İşte bir yazılımın taşınabilirliği ve dağıtımı konusundaki sorunlar da tam bu noktada başlıyordu.
Peki .NET tam bu noktada bize ne vaad ediyor buna bakalım.
.NET Framework'ün en önemli iki yapısı : Comman Language Runtime (CLR) ve .NET Framework Class Library'dir (CL). CLR ile birlikte önemli iki yapı daha var bunlar Common Language Specification (CLS) ile Common Type Systemdir (CTS). CLS .NET platformunda çalışacak dillerin ortak yapılarını belirler. CTS'de programlama dilinde kullanılan tiplerin çerçevesini çizer. Tam bu noktada MSIL kavramı ortaya çıkıyor. Intermadiate language denilen bir bölgede ister C#'da yazalım ister VB'de MSIL bölgesinde, yazılan kodlar ortak bir dile çevrilir. Tam bu sırada da CLS ve CTS'nin çizdiği çerçeve içinde kodlar denetlenir. Uygunsa CLR'a gönderilir değilse hata fırlatır. Burada değişken tanımları, metotların nasıl çalışacağı, hafıza kullanımı gibi durumlar açıklanır. MSIL'de bir de metadata kavramı vardır. Metadata'larda programın kullanacağı veri tipleri, namespaceler, metotlar saklanır. MSIL'de bütün dillerde yazılan kodlar tek bir potada eritilir diyebiliriz. Ve elde edilen sonuç CLR'a servis edilir. CLR bölgesinde de JIT derleyicileri ile çalıştırılan bu kod en son native code a dönüştürülür ve program çalışır. Çalıştırılan bu kod önbellekte tutulur. Tekrar propgram çalıştırıldığında önbellekten okunmaya başlar bu da performansda büyük bir artış sağlar. Bu işleri yöneten de CLR birimidir.
.png)
Peki bu senaryo bize ne tür avantajlar sağlamaktadır ve yazının başlangıcında bahsettiğimiz olumsuzluklar nasıl giderilmektedir şimdi bunlara bakalım. Öncelikle birbirinden farklı programlama dillerinin tek bir potada eritiliyor olması çok büyük avantajları beraberinde getiriyor. Bir yazılım projesinde farklı programlama dilleri kullanan programcılar ve hazırladıkları dll bileşenleri kullanılabilir. Çünkü her programlama dilinde yazılacak değişkenler ve nesneler CTS ve CLS'nin istediği özellikleri taşıdığından birbiri ile ortak özellikler taşıyacak ve haberleşeceklerdir.
Bugün modern programlamada sadece kullanılan programlama dili değil kullanılan kütüphaneler de giderek önem kazanmaya başlamıştır. .NET Framework ile birlikte gelen kütüphane de içerdiği onbinlerce class ile programcılara büyük kolaylık sağlamaktadır. Bu class yapılarına farklı programlama dilleri ile erişiyor olabilmek de verimliliği son derece arttıran bir özelliktir.
Makaleyi destekleyici Slideshare.com'dan beğendiğim bir sunumu da eklemek istiyorum.
Kaynaklar : Her yönüyle C# - Sefer Algan Sayfa 22-24-26, wikipedia, CeTurk, YazGelistir
Not : Eksik, hatalı veya yanlış ifadeleri lütfen bildiriniz.
27 Ağustos 2009 Perşembe akşam 22:49
Mesajınızı yazabilirsiniz
Mesajlar
siraykut
28 Ağustos 2009 Cuma öğleden sonra 14:2
Gayet güzel bir yazı olmuş ellerine sağlık diyorum. sende Yazmışsın tabi ama hatırlatmadan geçmek istemiyorum. platform bağımsızlık 90 lardan önce mümkün gibi görünüyordu fakat c++ içinde çeşitli kütüphaneler oluşmaya başladıktan sonra bu olasılık yerini platforma bağımlılı doğurdu. ancak burada bahsi geçen platformlar temelde farklı medialar olmakta yani mobil,web,windows form lar vb. tabi asılsorun "bir sefer yaz her yerde çalışsın" sloganın altını doldurmaya geldiğinde yukarıda yazdığım aygıtlar için farklı kurallar demekti wap için ayrı bir şeyler bilmek , web için ayrı kurallar felan gibi. ozaman sloganı destekleyen bir alt yapının olmadığının farkına varıyoruz. bu noktadan sonra devreye DotNet giriyor. tümleşik yapılar, uyumlu ortamlar developer araçlarından tutunda işletim sistemi kurallarına kadar uyum. buda toplam satın alma maliyetini aşşağılara çeken bir unsur olarak karşımıza çıkıyor. aslında anlatmaya çalıştığım şey temelde "insan bilmediğine düşmendır" sözünden başkası değil. bir JAVA developer ile DotNet Developer ın piyasada aldığı paralar hiç bir zaman aynı olmadı. efsanevi java , kıytırık Dotnet ön yargısı tüm Yazılım ve IT camiasında kasıp kavuran bu pazarlama stratejisi, çaresiz kalan işverenlerin developer ların kaprislerine bir son verme isteği ile son bulmaya başladı. şartlar ne olursa olsun bir developer ın yazdığnı diğeri okuyabilmeli ve hemen gidenin yerine birileri geçmeli. ben ulusal veritabanından bir web servisi ile sorgu almak için 100 bin dolar isteyen ve bunu vermek zorunda olan kurumlar biliyorum. DotNet Kolay öğrenilebilen , araçlarını kolaylıkla temin edebildiğimiz , web de kolaylıkla kaynaklara erişebildiğimiz bir derya olarak karşımızda duruyor. tabiki seçim meselesidir. microsoft u bir öcü gibi görenler yarın ülke veya çalıştıkları kurumların uygulamalarında çıkacak sorunlar için muhattap bulamayıncada acaba bu kadar radikal davrana bileceklermi. tüm bu yazdıklarıma rağmen rekabeti ve onun dünyaya kazandırdıkları taktirle karşılıyorum. bu piyasada olmaktan ve bende bir şeyler yazmaktan inanılmaz zevk duyuyorum