.NETin Temelleri -1

.NETin Temelleri 1 .NETin Temelleri 1

Daha önce Windows 2000 ve Com+ başlıklıl yazıda kısaca değinmeye çalıştığımız konular aslında Microsoft un yıllar boyu geliştirmekte olduğu teknolojilerin sadece bir kısmına ait kısa bir özet halindeydi. Windows programcıları tarafından aslında en iyi bilinmesi gereken konulardan birisi COM ve onu takip eden teknolojilerdir. Sebebi nedir derseniz, zaten bu yazılar da bu sebebi anlatacak :) Bu yazı ile başlayan bir dizi makale ile elimden geldiğince COMdan .NET e gelene kadar yazılım geliştirmede yaşanan gelişmeleri ve .NET ile gelen yepyeni sistemi sizlere açıklamaya çalışacağım.

Bugünkü yazılımların ve çalışan kodların da uzunca bir süre kullanılacağını düşünerek, COM ve onu izleyen gelişmeleri de incelemek gerektiğine inanıyorum. Her ne kadar, bu yazıda üzerinde duracağımız konular COM dan öncesine de dayansa bile, biz bir parça derli topu çalışabilmek için teknoloji miladımızı COM olarak alacağız.O zaman sıkı durun, yazılarımız başlıyor: 

Bundan çok zaman önce de,  programcıların birbirlerinin kodlarından faydalanabilmesi, şimdi de olduğu gibi, herkesin işini kolaylaştıran, ve programlamayı hızlandıran bir uygulamaydı. Hatasız veya çok az hatayla çalışan, denenmiş  bir kodu kullanmak sizi bir sürü olası bugdan koruduğu gibi, ortak kodu kullandığınız diğer kullanıcılarla yardımlaşmanızı ve onların deneyimlerinden faydalanmanızı sağlar.

İşin içine bir başka çok önemli faktör olan zaman da girince, bu paylaşımın önemi daha da artıyor. Başkalarının yazdığı kod sayesinde çok daha hızlı yazılım geliştirme olanağı bu işlemi destekleyen teknolojilerin hızla yayılmasına neden oldu.

Eskiden beri bu işle uğraşanların da hatırlayacağı gibi bir zamanlar kral assembly dili idi. Onu izleyen yıllarda C kraliyet tahtını uzunca bir süre elinde tuttu, ve zaman geçtikçe C++, Java, ve diğer diller gittikçe kalabalıklaşan programlama dilleri sahnesinde yerlerini aldılar. Bu süreç içinde  işletim sistemleri , ve programlama teknikleri de doğdu, ve bazıları gelişip güçlenirken bazıları da öldü..

Kod paylaşımı da bu süre içinde değişik aşamalardan geçti, ve gittikçe daha  karmaşık ve güçlü bir hale geldi.

Windows API ile boğuşan c programcılarının büyük kısmı bir süre sonra Object Oriented programlama ve MFC ile tanışıp Microsoft un onlara verdiği bu kod kütüphanelerini kullanmaya başladılar. Ancak iş bu kadarla kalmadı, çünkü yazılım sektörünün ihtiyaçları doğultusunda Microsoft, kendi  platformu (ları) üzerinde  programlamayı daha ileri taşımak için OLE ve sonrasında COMu yarattı.

1990ların başlarında ilk OLE Proffessional Developers Conference i takip eden yıllarda, COM doğdu. İlk olarak 1993 de gün ışığına çıkan COM ile birlikte Windows programlama alanında yeni bir dönem açıldı.

İlk başlarda COM sadece C++ ile kullanılabilen bir teknoloji iken yıllar geçtikçe başka diller tarafından da kullanılır hale geldi ( mesela Vbasic ) ve Microsoft un son noktasına .NET ile ulaştığı bu teknolojiler yavaş yavaş evrimleşti.Şimdi bu satırlara gelene kadar adını sıkça duyduğunuz COMa biraz daha yakından bakalım :

Herşeyden önce şunu söylememiz gerekir ki , COM son derece geniş bir teknoloji ve hakkını vererek COMu anladığını iddia eden çok fazla insan da yok . Ancak COMun temelinde yatan fikirleri ve onun varoluş nedeni olan problemleri nasıl çözmeye çalıştığının anlamanız bile sizin için çok önemli bir adım olacaktır. Koskoca kitaplarla anlatılan bir konuyu burada bir iki makale ile eksiksiz vermek tabii ki mümkün değil, o nedenle rahatlayın ve burada sadece Comun en önemli noktalarına kısaca değineceğimizi unutmayın lütfen.

Nesneye yönelik programlama ile birlikte yazılım geliştirme teknikleri de gittikçe component based , yani bileşen tabanlı bir seyir izlemeye başladı.

Bu sayede bir programın değişik kısımları bir çok programcı tarafından ayrı ayrı geliştirilebilir hale geldi.Ancak bu projeler sırasında belli programcıların projenin belli kısımlarını kendi istedikleri dillerle daha hızlı ve verimli yazdığı gerçeği de unutulmadı. Basit bir ayarlar ekranı, veya kullanıcı kayıtlarını gireceğiniz bir ekran için Vbasic ile çalışabiliyorsanız, neden C++ ile boğuşacaksınız. Öte yandan bu uygulamanın veritabanı ve belki de internet sunucusu üzerinde çalışan bazı kısımları da C++ ile daha yüksek performans sağlayacak şekilde yazılabilir.

Şimdi daha da karmaşık bir sorunumuz var. Birden fazla dili kullanan, bir sürü programcının yazdığı kısımları bir araya getirerek tek bir programı ortaya çıkarmaya çalışıyoruz !! Yani başımız ciddi biçimde belada.

Detaylarına birazdan gireceğimiz bir başka sorun da şu : aynı dili kullanan programcılar bile aynı compilerı kullanmak zorunda değil. E ne olur ki derseniz, inanın çok kötü şeyler olur...

 

İşleri biraz daha karıştırmadan önce somut bir örnek üzerinde ilerlemeye çalışalım.Diyelim ki yetenekli bir programcı olarak siz oturup muhteşem bir mail componenti yazdınız. Bu component de bir C++ classından oluşuyor. ( eğer class kelimesi size çok yabancı ise pes etmeyin, C# bölümünde C# ve Object Oriented programlama üzerine yazdığım yazının yardımı olabilir ...) 

İlk teknik: Statik Bağlama ( static linking) 

Bu kodu dağıtmak için ne yapacaksınız peki ? Eğer bileşeninizi , yani mailcomponent classını bir kütüphane olarak dağıtırsanız kullanıcılarınız, yeni diğer programcılar sizin verdiğiniz kütüphaneyi programlarına derlerken dahil edeler ve kendi programları ile birlikte dağıtırlar.

Eh, fena değil, ama siz bu bileşenin yeni versiyonunu çıkarırsanız ne olur ? Sizin bu kütüphaneniz pek bir kıymetli olduğu için, onu kullanan tüm yazılımların bu yeni versiyon ile yeniden derlenmesi gerekir!!! Peki ya sizin bileşeninizi kullanan birden fazla yazılım aynı bilgisayara kurulursa ne olacak ? O zaman da aynı kod parçası değişik programlar yüzünden tekrar tekrar hard diskte yer kaplayacak. O harcanan yere güzel güzel Quake 3 kurabilirdik halbuki..Tek bir bileşen çok fazla yer israfına sebep olmaz gibi görünse bile, aynı mantıkla çalışan devasa kütüphaneler bu sorunu çok ciddi hale getirebilir. ( MFC yi duyanlar parmak kaldırsın :) Eğer her yazdığınız programa, ama her farklı programa MFCyi static olarak, yani derleme sırasında eklerseniz, bir süre sonra bir sürü tosun gibi yazılımınız olur.

İkinci deneme : Dinamik Linking ( Dynamic Linking ) 

Hemen yukarıdaki soruna çözüm olarak üretilen dynamic linking, Windows işletim sisteminin çok yoğun kullandığı bir tekniktir. Anlı şanlı DLL ( Dynamic Link Library ) kavramı bu sayede ortaya çıkmıştır.  DLLler güzel güzel sizin çağırmanızı bekleyen kod parçalarıdır. Siz kendi yazdığınız bir programla programınız çalışırken ihtiyacınız olan DLLi çağırırsanız , o DLL içindeki kodu program çalışırken, yani dinamik olarak kullanabilirsiniz. Böylece programınız gerekli kodu kendi içine derleme sırasında dahil etmek yerine, çalışırken kendisine yardımcı olacak bir dllin adını yanına alarak yola çıkar. Biraz daha somut bir anlatımla, tüm paranızı yanınıza almak yerine, sadece kredi kartınızla evden çıkarak bayağı bir hafiflersiniz.

Hmm, bu daha iyi görünen bir çözüm, şimdi classımızı , dolayısıyla mail componentimizi bir dllin içine koyarak hizmete açıyoruz . Bu sayede 10 program bu kodu kullanacak olsa bile hepsi tek dll dosyası sayesinde çalışabilir. Yer kaplama porblemini çözdük gibi..

Ama maalesef yeni sorunlarımız var !!!

Siz visual C++ ile yazdığınız bir C++ classını bir dll içine güzelce yerleştirdiniz diyelim.Bir başka programcı da geldi, kendi visual c++ ı ile o dll içindeki classı kullandı. Ne güzel, her şey yolunda. Peki ikinci  programcı başka bir compiler ile çalışıyorsa ne olur ? Maalesef dllinizin içindeki classı kullanamaz !!! Nedeni de şu : C++ type safe linking denilen bir tekniği kullanır. Yani bir class , obje kodu olarak derlendiğinde, içindeki fonksiyonların isimleri, döndürdüğü değerler gibi önemli bildiler dlle yazılır. Bu oldukça güzel bir şey, ama sorun şu ki, C++ standartı sadece bu bilgilerin yazılmasını istiyor, hangi derleyicinin bu bilgiyi dlle nasıl yerleştireceği ile ilgilenmiyor ...Bu bilgilerin yazılması işine "mangling" diyoruz.

Daha da ötesi, herkese aynı compilerı silah zoruyla kullandırsak bile ( hatta o compilerın yeni versiyonu da çıkmasın !) biz mail component olarak yazdığımız class da bir değişiklik yaptığımız anda, bu classın eski versiyonunu içeren dlli kullanan programlar bizim vereceğimiz yeni dll yüzünden çakılacaktır... Yani yine başladığımız noktaya geri döndük . Bu  sefer de bu dlli kullanan tüm programlar kendi başladıkları versiyonu kullanmak zorundalar. İşte bu yüzden makinanızda MFC30.DLL, MFC40.DLL gibi aynı kütüphaneleri içeren değişik DLLler var.

COMun getirdiği çözüm: Interface Based Programming

COMun bahsettiğimiz sorunlara getirdiği çözüm Interface Based Programming denilen bir teknikle program yazmak üzerine kurulu. (Interface Based Programming gerçekten sağlam bir altyapı gerektiren bir konu, ve C++ veya C# ile ayrı bir yazıda açıklamayı düşünüyorum). Burada işleri çok karıştıracağı için şunu söyleyerek bu kısmı kapatalım : COM, paylaşılacak olan kodu, classlar içersininde paketledikten sonra bu classları DLLler vasıtasıyla dağıtmanızı ve temlde kullandığınız Interface Based Programming tekniği ile, dağıtmak istediğiniz  kodun bir çok dil ve programcı tarafından kullanılmasını sağlar. 

Eğer derleyip toparlarsak, COM un amacı kod dağıtımı ve yeniden kullanımını en kolay ve verimli şekilde geçekleştirmektir. Ancak bu işi yapmak için COMun da kırk  dereden su getirdiği durumlar vardır. 

COM  paylaşılacak olan bir classı bir program çalışırken çağırabilsin diye, o classı Windows Registryde tanımlar. Yani makinanızdaki DLLler programınız çalışırken  ona ulaştıramadıkları bazı bilgileri regsity yazmak zorundadılar. İşte bu durum da , başka bir iki teknik sorunla birleşince ortaya yıllarca programcılar tarafından "DLL HELL" olarak adlandırılan durumu çıkarır.

Daha önce registrye yolunuz düştüyse, HKEY_CLASSES_ROOT kısmına rastlamış olmalısınız. İşte bu kısımdaki CLSID ( yani class id :) kısmı makinanızda tanımlanmış olan paylaşılmış classları listeler.

Gerçek hayatta size zorluk çıkaran bir sürü durumun temelinde bu bahsettiğimiz işleyiş vardır. Mesela web developerların nefret ettiği bir zorunluluk, kullanmak istedikleri bazı dllleri active server pages içinden çağırmak için sunucu üzerinde register etmek zorunluluğudur.

Şimdi neden bu işleme mecbur kaldığınızı anladınız umarm. Bir program çalışırken bir COM DLL içinde bulunan bir classdan faydalanmak isterse, o class için aradığı bazı bilgileri registryden almak zorundadır. Sizde o DLLi kullanacaksanız registryde o bilgilerin olduğunu garantilemelisiniz.

Yani COM, kodumuzu daha kolay paylaşılır hale getirmek için bizden belli kurallara uymamızı ister.

Bu noktada alıştığımız anlamda bir windows programının makinanızda kurulumu sırasında ne gibi prosedürler izlediğini anladığınızı umuyorum. Yani belli işleri yapacak kodlar, DLLler içine konuyor, ve gerektiğinde çağırılabilmeleri için registryde gerekli kayıtları yapılıyor.

Temelde normal görünen bu prosedür, binlerce DLL ve bunlar arasındaki bazı ilişkiler bir çok kullanıcının sırma saçlarına mal oldu.  Her ne kadar başından beri Microsoft bu durumu mümkün olduğunca ortadan kaldırmaya çalıştıysa da , Windows 2000 ile azalan bu soruna en büyük darbeyi .NET vurdu . O nasıl oldu diyenler, bu yazının ikinci bölümünde .NET ile ilgili detaylı bir girişi, ve .NETin kod paylaşımına getirdiği yepyeni anlayışı bulacaklar . Hepinizi bekliyorum :)

Döküman Arama

Başlık :

Kapat