Bu yazımızda MVC mimarisinin sunum kısmı olan View’leri inceleyeceÄŸiz.

View

Ä°lk makalemizde bahsettiÄŸimiz gibi View, MVC mimarisinin sunum kısmıdır. Controller bir action metodu iÅŸletikten sonra, kullanıcı tarafına bir ÅŸeyler göstermesi gerekmektedir. Tabi View kullanması zorunlu olmasa da genelde Controller, o action metoda ait bir View, yine zorunlu olmasa da bir model aracılığı ile verileri alarak kullanıcıya iletir. Burada bilmemiz gereken en önemli nokta View’ler Controller ve Model’ler gibi önceden derlenmiÅŸ bir dll içinde deÄŸillerdir ve dinamik olarak derlenirler. Kısaca ÅŸematize edecek olursak:

MVC Çalışma Diyagramı

Tabi gerçek bir sitede durumlar daha da karmaşık olabilir. Diyagrama bakacak olursak, gelen kulanıcı isteÄŸinin nasıl iÅŸlenip View’lere iletildiÄŸini görmüş olacağız. Her action metod farklı biçimlerde View’lere eriÅŸmektedir. Kimisi herhangi bir model yapısı kullanmadan direk olarak, kimisi model kullanarak, kimisi de entity ya da baÅŸka bir veritabanı sınıfını model olarak kullanarak View’ler ile kullanıcının karşısına çıkmaktadır.

Önceden de bahsettiÄŸimiz gibi, View’e kadar olan bütün kısımlar önceden derlenmiÅŸ assembly dll dosyaları içinde bulunmakta ve View kısmı ise kullanıcı istekte bulunduÄŸunda dinamik olarak derlenmektedir. Bu yüzden siteniz sunucuya atılırken View dosyaları (Razor için cshtml ya da vbhtml) olduÄŸu gibi atılırlar. Bununla birlikte dinamik derleme olduÄŸundan dolayı, View dosyaları içinde sunucu kodlarına ait çok fazla kod bulunmaması iyi olur. Genelde View dosyalarında kontrol yapıları(switch case, if..) ve döngüler(for, while) gibi basit kodlar bulunmalı. Daha karmaşık iÅŸlemleri Controller içinde halletmeli ve sonucu View’e yollamalıyız. Burası önemli bir nokta idi. Ayrıca her ne kadar View içinden veritabanına da eriÅŸbilseniz de bu yapmamanız gereken bir iÅŸlem olacaktır. Veritabanı iÅŸlemlerinizi de Controller içinde yapmalısınız.

MVC’de bir action metoda ait view’i çağırmak için metod sonundan ÅŸu ÅŸekilde çıkış saÄŸlarız:

public ActionResult ActionMethod1()
{
    return View();
}

EÄŸer bu action metod’a ait herhangi bir View dosyası oluÅŸturmaz ve bu kodu çalıştırırsanız, MVC sistemi size bu action’a ait View’ı nerelerde arayıp da bulamadığına dair bir hata mesajı gösterecektir. Bu hata mesajına dikkat ederseniz varsayılan konumlar ilk baÅŸta View klasöründe Controller ile aynı isimde bir klasör içindeki bir cshtml dosyasıdır. Bu dosya, view’ı çağırdığımız action metod ile aynı isme sahiptir. Yukarıdaki örnek için bu dosya ActionMehod1.cshtml olacaktır.

View() metoduile baÅŸka baÅŸka view’ler de çaÄŸrılabilir. Mesela BaskaBirView gibi bir View dosyasını çağırmak için View(“BaskaBirView”) ÅŸeklinde parametre vermeliyiz.

Åžimdi basit bir view dosyasını incelemek için ufak bir örnek yapalım. VS ya da VWD’de yeni bir MVC projesi açalım. View engine olarak Razor’u seçelim. Template olarak Empty seçelim ve formu onaylayıp kapatalım. Karşımıza boÅŸ bir MVC projesi gelecektir. Solution Explorer’dan Controller klasörüne saÄŸ tuÅŸla tıklayıp Add alt menüsünden Controller seçeneÄŸini seçelim. Ä°sim olarak HomeController girelim.  Karşımıza HomeController içindeki önceden eklenmiÅŸ bir bir action metod gelecektir. Åžimdilik ismini Index olarak bırakalım ve deÄŸiÅŸtirmeyelim. Bu metodun herhangi bir yerinde(içinde, isminin üzerinde, vs..) saÄŸ tuÅŸla tıklayıp Add View seçeneÄŸini seçelim. Karşımıza gelecek olan pencere bir MVC projesinde çokca karşılaÅŸacağımız bir penceredir. Kısaca buradaki seçeneklerden bahsedecek olursak;

“View engine”: Bu seçenek, varsayılan olarak proje için belirlediÄŸiniz görünüm motoru ayarlı olarak gelecektir. Bizim için bu seçenek tabi ki Razor olacaktır.

“Create a strongly typed view”: Bu seçenek ile önceden projeye dahil etmiÅŸ olduÄŸumuz bir modeli, View’e model olarak tanıtıyoruz. Yani view nesnemize bir modeli dayatmış oluyoruz. Yalnız unutmamanız gereken ÅŸey, bu listede yeni eklediÄŸiniz modellerinizin görünmesini istiyorsanız projeyi bir kez derlemeyi unutmamanız gerekmektedir.

“Scaffold template”: Bir proejde, özellik yönetim kısmında ekleme, silme, düzenleme gibi bir iÅŸlemler için elimizle tek tek view oluÅŸturmak yerine, buradaki template’leri seçerek daha hızlı bir çekilde bu viewleri oluÅŸturabiliriz.

“Create as a partial view”: Bu seçenek ile view dosyamızın bir partial view olduÄŸunu belirtmiÅŸ oluyoruz. Bu konu bir kaç baÅŸlık sonra karşınıza gelecek. Bu yüzden bu ksımı geçiyoruz ve boÅŸ bırakıyoruz.

“Use a layout or master page”: Buradan Layout dosyamızı belirliyoruz. Bu konuya da daha sonra deÄŸineceÄŸiz. Burayı seçili ama boÅŸ bırakın.

Bu formu onaylayıp kapattığınızda boÅŸ bir view dosyası ile karşı karşıya geleceÄŸiz. View dosyamızı incelemeden önce Solution Explorer’dan Models klasörü altına yeni bir sınıf ekleyelim ve ismine BirModel girelim. Ardından aÅŸağıdaki gibi kodlarını deÄŸiÅŸtirelim:

public class BirModel
{
    public List<int> Liste { get; set; }
}

Şimdi projemizi bir kez derleyelim ve View dosyamızı da şu şekilde değiştirelim:

@model MvcArticle3_1.Models.BirModel
@{
    ViewBag.Title = "Ana sayfa";
}

<ul>
@foreach (int sayi in Model.Liste)
{
    <li>@sayi</li>
}
</ul>

Şimdi bir sonraki adıma geçmeden önce buradaki kodlara bir göz atalım.

Ä°lk satırda view dosyamıza bir model dayatmış olduk. View oluÅŸtururken karşımıza gelen form’da “Strongly typed view” ile de seçebileceÄŸimiz bir model ile view dosyamızın kullanacağı model’i belirlemiÅŸ oluyoruz. Burada model belirlenirken, model’in tam yolunu belirtmemiz gerekiyor. Ben projeye MvcArticle3_1 gibi garip bir isim verdiÄŸimden dolayı ana namespace olarak bu gözüküyor. Ama siz buraya kendi projenize göre bir namespace’i giremlisiniz. Yani kısacası, model’in namespace’i ile beraber tam yolunu belirtmeniz gerekmetkedir.

Daha sonraki gelen, 3 satırdan oluÅŸan blok ile sayfamızın baÅŸlığı belirleniyor. Buradaki ViewBag ve ViewBag.Title ayrıntısına sonra deÄŸineceÄŸiz. Sonrasında gelen foreach döngüsü ile BirModel isimli modelimizde bulunan Liste ismindeki List<int> dizisini kullanıyoruz. Dikkat ederseniz bir view’e ait modeli kullanabilmek içni Model deÄŸiÅŸkenini kullanıyoruz.

Buraya kadar her şey güzel. Şimdi bu view dosyamızı çalışır hale getirmek için Controller sınıfımızda bir kaç satırı dğiştireceğiz. Index action metodunu aşağıdaki gibi değiştirelim:

public ActionResult Index()
{
    var birModel = new BirModel
    {
        Liste = new List<int> { 1,39,4,744 }
    };

    return View(birModel);
}

Projeyi derleyip çalıştırdığımızda <ul> , <li> ‘den oluÅŸan çıktımızı görebilirsiniz.

Åžimdi farklı bir ÅŸey yapacağız ve bu view dosyamızın derlenmiÅŸ haline göz atacağız. “C:\Windows\Microsoft.NET\Framework” klasörüne girelim ve buradan kullandığımız .net versiyonunun klasörüne girelim(makale yazılırken 4.0* idi). Bu klasörde “Temporary ASP.NET Files” isminde bir klasör göreceksiniz. Bu klasör altında bulunan root klasörüne girelim ve explorer’dan dosyaları deÄŸiÅŸtirme tarihine göre sıralayalım. En üsteki klasöre girelim ve “App_Web_index.cshtml.*.cs” ismindeki dosyayı bir editör ile açalım. Buradaki * deÄŸiÅŸken bir hash deÄŸeridir.

View dosyamız ile (Index.cshtml) derlenme esnasında oluÅŸturulmuÅŸ olan bu dosyayı karşılaÅŸtıralım. Önceden de bahsettiÄŸimiz gibi ASP.NET MVC, view dosyalarını dinamik olarak derler. Fakat view dosyası deÄŸiÅŸtirilmemiÅŸ ise önceden derlenmiÅŸ olan halini kullanır ve tekrar derleme gafletinde bulunmaz. Buradaki dosyada da gördüğünüz gibi bütün html bilgileri WriteLiteral fonksiyonu ile sarılmış durumdalar. Razor’un @ iÅŸareti ile belirttiÄŸiniz c# kodları ise direk olarak bu dosyaya dahil edilmiÅŸtir. View’in çalışma mantığını anlamak için bu karşılaÅŸtırmayı yapmanız önemli. Özellikle baÅŸka Razor gramerleri ile üretilen sonuca da göz atabilirsiniz. Aynı klasörde “App_Web_*.dll” gibi bir kaç derlenmiÅŸ assembly dosyası bulacaksınız. Bu dosyayı reflector ya da VWD içindeki object browser ile açabilirsiniz. Bu assembly’de göreceÄŸiniz gibi Index.cshtml dosyamız, dinamik olarak derlenerek bu dll altına bir sınıf olarak yerleÅŸmiÅŸtir. Bir dahaki Index.cshtml dosyası çaÄŸrıldığında, view dosyası eÄŸer deÄŸiÅŸtirilmemiÅŸse, direk olarak bu derlenmiÅŸ dll kullanılacaktır. Bu yüzden view’in ilk çalıştırılmasından sonra büyük bir performans artışı da olacaktır.

Burada dikkat etmemiz gereken diÄŸer bir husus ise bu üretilmiÅŸ olan dosyada view dosyamız bir sınıf haline dönüştürülmüş ve WebViewPage<*.BirModel> gibi bir sınıftan türetilmiÅŸtir. Ä°ÅŸte “strongly typed” deÄŸimi buradan geliyor. View dosyamız, dosyanın başında model belirteci ile belirttiÄŸimiz modeli generic parametre olarak alan bir sınıftan türetilmekte.

Tabi ki bu üretilen dosyanın çok da ayrıntısına inmemize lüzum yok. Fakat View’in çalışma mantığını anlama açısından bu kısım önemliydi.

ViewBag ve ViewData

ViewBag ve ViewData aslında aynı iÅŸi yapan ve view ile model’e alternatif olarak controller arasında iletiÅŸimi saÄŸlayan iki yöntemdir. ViewBag, C#’ın dinamik nesne özelliÄŸini kullanan bir nesnedir. ViewData ise indeksli bir Dictionary nesnesidir. Dinamik nesne desteklemeyen eski sürüm .net’lerde ViewData kullanılmaktadır. Yeni versiyonlarda hem ViewBag hem de ViewData kullanılabilir. AÅŸağıdaki kod hem controller’da hem de view dosyasında aynı ÅŸekilde kullanılabilir:

public ActionResult Index()
{
    ViewBag.BirYazi = "Diyezon";
    ViewData["BirSayi"] = 5;
    return View();
}

View dosyası içinde ise:

<p>Yazı: @ViewBag.BirYazi</p>
<p>Sayı: @ViewData["BirSayi"]</p>

Normalde ViewBag ve ViewData içinde çok fazla kompleks olmayan ve miktarı az verileri barındırmanız performans açısından daha iyi olacaktır. Bir kaç baÅŸlık sonra da görebilceÄŸiniz gibi bu nesneleri aşırı derecede kullanmak performansı düşürecektir. Bu nesnler genelde, model’de deÄŸiÅŸiklik yapamadığınız ya da yapmak istemediÄŸiniz durumlarda kullanılırlar. View içine göndereceÄŸimiz veriler için ilk önce model yapısını düşünmeliyiz.

Html Yardımcı Metodları(Html Helpers)

Ä°lk makalede de bahsettiÄŸimiz gibi MVC, WebForms’daki gibi tut taşı mantığı yerine her bir elemanın elle girilmesini ister. Ä°lk baÅŸta bu zor gibi görünse de projenin ilerleyen aÅŸamalarında, tut taşı ve viewstate mantığından çok daha verimli olduÄŸunu göreceksiniz. Özellikle üretilen html kodu, WebForms’daki gibi istemediÄŸiniz bir çok ıvır zıvır html kodları ile sarılı olmayacaktır. Bunun ayrıntısını ilk makalenin baÅŸlarında bahsetmiÅŸtik. Farkında iseniz “üretilen” html kodundan bahsettim. Evet her ne kadar MVC her ÅŸeyi bizim belirlememizi istese de bize yardımcı olacak bir çok metodu da hizmetimize sunmaktadır.

Html yardımcı metodları, System.Mvc.HtmlHelpers ismindeki statik bir sınıfta bulunan metodlardan oluşmaktadır. Bu metodlar ile dinamik olarak oluşturulması gereken bir çok işi gerçekleştirebiliriz. Şimdi ilk başta hazır yardımcı metodlardan en çok kullanacağımız bir kaç tanesini görelim ve ardından kendi yardımcı metodlarımızı nasıl oluşturacağımızı görelim.

Form OluÅŸturma

Form oluşturmak için biri çirkin ve uzun diğeri kısa ve pratik iki yöntemimiz var. Uzun yöntem:

@{ Html.BeginForm(); }
@{ Html.EndForm(); }

Bu iki kod arasına yazacağınız her şey form içinde olacaktır. Fakat bunun daha pratik yolu ise:

@using(Html.BeginForm())
{
}

olacaktır. Bu blok içine yazacağınız bütün kodlar form içinde bulunacaktır. BeginForm metodu normalde IDisposable arayüzünü tanımlayan MvcForm tipinde bir sınıf üretecektir. IDisposable olduğundan dolayı using terimi ile sardığımızda, .Net using bloğunun bitiminde bu sınıfın Dispose() metodunu çağıracaktır. Bu da EndForm metodunu tetikleyecektir.

Burada verdiÄŸimiz örnekte form onaylandığı zaman sonucu bu view’i çağıran action metoduna gönderecektir. EÄŸer baÅŸka bir action’a gönderim yapmak istersek:

@using(Html.BeginForm("BirAction", "BirController"))
{
}

yazmalıyız. BeginForm metodunun diğer parametrelerini yardım dosyasında bakabilirsiniz.

Form Elemanlarını Oluşturma

Form elemanlarını oluşturmak için iki farklı metod grubumuz var. Bu gruplardan birisi zorunlu olarak modeli kullanan diğeri ise model kullanmayan metodlardır.

Model Zorunlu Olmayanlar

İlk başta model zorunlu olmayan metodları görelim:

@Html.Label("FormElemanAdi")
//<label for="FormElemanAdi >Form elemanının texti</label>

@Html.CheckBox("CheckBoxAdi", true)
//<input checked="checked" id="CheckBoxAdi" name="CheckBoxAdi" type="checkbox" value="true" />
//<input name="CheckBoxAdi" type="hidden" value="false" />

@Html.Hidden("HiddenAdi", "HiddenDegeri")
//<input id="HiddenAdi" name="HiddenAdi" type="hidden" value="val" />

@Html.RadioButton("RadioAdi","RadioDegeri", true)
//<input checked="checked" id="RadioAdi" name="RadioAdi" type="radio" value="RadioDegeri" />

@Html.Password("PasswordAdi", "PasswordDegeri")
//<input id="PasswordAdi" name="PasswordAdi" type="password" value="PasswordDegeri" />

@Html.TextArea("TextAreaAdi", "TextAreaDegeri")
//<textarea id="TextAreaAdi" name="TextAreaAdi">TextAreaDegeri</textarea>

@Html.TextBox("TextBoxAdi", "TextBoxDegeri")
//<input id="TextBoxAdi" name="TextBoxAdi" type="text" value="TextBoxDegeri" />

(Buradaki açıklama satırları tabiki Razor için uygun bir açıklama satırı değil. Fakat sitede kullandığım syntax renklendirici için böyle yazmak zorunda kaldım.)

Farkında iseniz CheckBox ile iki adet kod üretildi. Normalde browser checkbox seçili olmadığında sunucuya bu değeri yollamaz. Bu yüzden MVC bu durumu düşünerek buraya değeri false olan bir hidden form elemanı ekleyerek checkbox seçilmediğinde değer olarak false yollanması sağlanmaktadır.

Farkında iseniz ilk değer olarak eleman adını ve ikinci değer olarak da elemanın değerini yazıyoruz. Eğer elemanın değerini girmezsek ve sadece adını verirsek:

@Html.TextBox("TextBoxAdi")

bu durumda değer olarak MVC otomatik olarak bir kaç yere bakacaktır:

ViewBag.TextBoxAdi
ViewData["TextBoxAdi"]
Model.TextBoxAdi

Tabi burada bakılan değerin tipi ile Html yardımcı metodunun değer tipi aynı olacaktır. Yani CheckBox metodu için boolean tipinde bir değer aranacaktır.

Şimdi daha ilginç bir şey yapalım ve isim olarak şöyle bir şey girelim:

@Html.CheckBox("Veriler.Secenekler.Secenek")

Bu durumda bakılacak kısımlar daha da uzayacaktır:

ViewBag.Veriler.Secenekler.Secenek
ViewBag.Veriler["Secenekler"].Secenek
ViewBag.Veriler["Secenekler.Secenek"]
ViewBag.Veriler["Secenekler"]["Secenek"]
.....

Tabi bu liste uzunca bir liste olacaktır. Gördüğünüz gibi girdiÄŸiniz isimler MVC için önemli bir deÄŸer arzediyor. Bu yöntemde her ne kadar performans düşüşü olacak gibi görünse de ViewBag ve ViewData içinde sadece bir kaçtane deÄŸer olacağı için performans düşüşü de beklenmez. Tabi önceden de bahsettiÄŸimiz gibi ViewBag ve ViewData’da çok az miktarda veri bulundurmalısınız.

Model Zorunlu Olanlar

Html yardımcı metodlarında adı  “For” ile biten metodlar, modeller için özel olarak tasarlanmıştır. Hem performans hem de kolay kullanım açısından mümkün olduÄŸunca bu tarz metodları kullanmanızı tavsiye ediyorum.

Bir önceki başlıkta verdiğimiz metodların tek tek buradaki karşılıklarını vermek yerine, basit bir örnek yapalım. Makalenin başında yaptığımız örnekte bir model oluşturmuştuk. Bu modeli aşağıdaki gibi değiştirelim:

    public class BirModel
    {
        [DisplayName("Kullanıcı Adı")]
        public string KullaniciAdi { get; set; }

        [DisplayName("Şifre")]
        [DataType(DataType.Password)]
        public string Sifre { get; set; }

        [DisplayName("Beni Hatırla")]
        public bool BeniHatirla { get; set; }

        public int BirListeDegeri { get; set; }
        public Dictionary<int,string> BirListe { get; set; }
    }

Buradaki kullanılan DisplayName, DataType gibi öznitelikleri şimdilik görmezden gelin. Çünkü bu kısım gelecek makalenin konusu. Ama ne işe yaradıklarını View dosyasını gördükten sonra tahmin edersiniz herhalde. Şimdi View dosyamızı açalım ve aşağıdaki gibi değiştirelim:

@model MvcArticle3_1.Models.BirModel
@{
    ViewBag.Title = "Ana sayfa";
}

@using (Html.BeginForm())
{
    <table>
        <tr>
            <th>@Html.LabelFor(m => m.KullaniciAdi)</th>
            <td>@Html.EditorFor(m => m.KullaniciAdi)</td>
        </tr>
        <tr>
            <th>@Html.LabelFor(m => m.Sifre)</th>
            <td>@Html.EditorFor(m => m.Sifre)</td>
        </tr>
        <tr>
            <th>@Html.LabelFor(m => m.BeniHatirla)</th>
            <td>@Html.EditorFor(m => m.BeniHatirla)</td>
        </tr>
    </table>
}

Önceki örnekte dediğim gibi model tanımlamasındaki namespace sizde farklı olabilir, bunu değiştirebilirsiniz.

Şimdi de son olarak Index action metodumuzu aşağıdaki gibi değiştirelim:

        public ActionResult Index()
        {
            return View();
        }

Derleyip çalıştırdığımızda hazırladığımız modele uygun bir form ile karşılaÅŸacağız. Åžimdilik model’deki öznitelik tanımlamaları ve bu form gönderildikten sonra iÅŸlenecek kısmı daha sonraki makaleye havale ederek burada sadece View dosyasındaki eklediÄŸimiz metodlara göz atalım.

Farkındaysanız sadece EditorFor metodunu kullanarak üç farklı form elemanı oluşturduk. EditorFor metodu, belirtilen modeldeki özelliğin tipini tespit ederek uygun bir form elemanını sayfaya render etti.

Parametre olarak girilen delegate ile model içinden herhangi bir özelliÄŸi seçebiliyoruz. Gerisini metod hallediyor. Tabi ki, bir önceki baÅŸlıkta verdiÄŸimiz CheckBox, TextBox gibi metodların CheckBoxFor, TextBoxFor metod karşılıkları da mevcut. Bunların EditorFor‘dan tek farkı, form elemanının tipinin seçimini size bırakmasıdır. Ama model üzerinde bu seçimi yapmak, projenin ilerleyen aÅŸamasında da fark edeceksiniz, daha az kullanışlıdır. Çünkü belli bir süre sonra, bir veri tipinde deÄŸiÅŸiklik yaptığınızda tüm view’leri araÅŸtırıp bu tipe ait metodu da deÄŸiÅŸtirmeniz gerekebilir. Bu yüzden tüm etiket ve tip tanımlamalarını model altında merkezi bir yerde toplamış olduk. Bu konunun ayrıntısını kısmetse gelecek makalede göreceÄŸiz.

Aynı şekilde EditorFor yerine DisplayFor metodunu kullanarak, form elemanı yerine sadece okunabilir formatta, modellin değerini kullanıcıya gösterebiliriz.

Bu metodların haricinde bir de EditorForModel gibi “ForModel” ile biten metodlar da vardır. Bu metodlar belli bir template, ÅŸema ile model’e ait tüm özellikleri ekrana basacaktır. Ä°lerleyen makalelerde bu metodlar için template hazırlamayı da göreceÄŸiz, fakat ÅŸimdilik bu konuyu es geçelim.

Devam etmek için diğer sayfaya geçiniz.

Bu yazıda, konuya kaldığımız yerden devam edeceÄŸiz ve ASP.NET MVC projesinin yapısını inceleyeceÄŸiz. Ardından ASP.NET MVC’de çokca kullanılan yönelendirme mantığından bahsedeceÄŸiz. Ki bu konu ASP.NET MVC ‘de ciddi bir proje geliÅŸtirebilmemiz için temel konuları kapsıyor.

ASP.NET MVC Projesi

VWD ya da VS’de yeni bir MVC projesi oluÅŸturmaya kalktığınızda IDE size üç ÅŸablon(template) seçeneÄŸi sunacak. Bunlardan birincisi Empty ÅŸablonu, önceki makalede kullandığımız bir ÅŸablondu. En basit haliyle bir ASP.NET MVC projesinin barındıracağı dosyalar bu ÅŸablonda bulunmaktadır. DiÄŸer ÅŸablonlar olan Internet ve Intranet ÅŸablonları ise size daha geniÅŸ baÅŸlangıç noktaları sunmaktadır. Internet ÅŸablonu ile varsayılan bir controller ve bir view dosyası projeye dahil edilcektir. Intranet ÅŸablonun Internet ÅŸablonundan tek farkı ekstradan kullanıcı iÅŸlemlerinin olmasıdır. Biz genelde Empty ÅŸablonunu kullanmaktayız. Fakat küçük bir takım iÅŸler için hazır bu ÅŸablonları kullanabilirsiniz. Mesela bu makalede bahsedilecek olan yönlendirmeler üzerinde denemeler yaparken hazır Internet ÅŸablonunu kullanabilirsiniz. Tabi ki bu ÅŸablonlara ek olarak kendiniz de bir proje ÅŸablonu oluÅŸturabilirsiniz. Fakat bu konu makalenin sınırları dışında…

Empty şablonu oluşturduğunuz bir projenin klasör yapısı aşağıdaki gibi olmaktadır:

• App_Data: Bu MVC’ye özel bir klasör deÄŸildir. Veritabanı dosyalarının tutulduÄŸu klasördür. IIS bu dosyaya eriÅŸimi kısıtlayacaktır. Kullandığınız host bu klasör altında veritabanı bulundurmanıza izin veriyorsa kullanabilirsiniz.
• bin: DerlenmiÅŸ proje dosyalarıdır. IIS bu klasöre eriÅŸim vermediÄŸi gibi VS ya da VWD de bu klasörü Solution Explorer’da gizler. Projeyi tamamlayıp hosta taşıyıncaya kadar iÅŸiniz olmaz bu klasörle.
• Content: Bu klasör ismi kabullenmedir ve zorunlu deÄŸildir. CSS ve resim gibi statik dosyalarınızı bu klasöre koyabilirsiniz. Fakat zorunlu olmadığı için istediÄŸiniz klasörü de kullanabilirsiniz.
• Controllers: Controller sınıflarını koyduÄŸumuz klasördür. Bu klasörün ismi de zorunlu deÄŸildir. Çünkü sonuçta bunlar derlenip aynı assembly içine girecekler.
• Models: Model sınıflarını yerleÅŸtirdiÄŸimiz klasördür. Bu klasörün ismi de kabullenmedir ve zorunlu deÄŸildir. Çünkü sonuçta bu sınıflar derlenip bir assembly oluÅŸtururlar ve bin klasörüne yerleÅŸtirilirler.
• Scripts: Bu da Content klasörü gibi zorunlu deÄŸildir. Javascript dosyalarını bu klasörde tutabilirsiniz.
• Views: View ve partial view dosyaları bu klasörde tutulur. Ayrıca bu klasörde bulunan Shared klasörü layout ve tüm controller’lar tarafından kullanılabilecek ortak view dosyalarını tutarlar. Bu klasör IIS tarafından servis edilmez yani eriÅŸimi kısıtlanmıştır. Bu klasörün ana dizininde bir web.config dosyası mevcuttur. Bu web.config, uygulamanın web.config dosyasından ayrıdır ve bu klasörün IIS tarafından servis edilmesini engeller. Bu klasörün ismi kabullenme deÄŸildir. Fakat MVC’nin yapısını özelleÅŸtirerek view dosyalarının baÅŸka klasörde aranmasını saÄŸlayabilirsiniz. Tabi bu makalemizin sınırları dışında bir konu…

Bu klasörler dışında ana dizinde uygulamanın bir adet web.config dosyası ve bu makalede kısmen bahsedceğimiz uygulamanın sınıfını içeren Global.asax dosyası mevcuttur. Bunlar dışında ilerideki makalelerde bahsetmek istediğim bir konu olan alanlarla ilgili olan Areas klasörü mevcut olacaktır. Yeni bir alan oluşturduğunuzda VWD bu klasörü otomatik olarak projeye dahil edecektir.

Gördüğünüz gibi çoğu klasör ismi zorunlu değildir ve her nasıl istiyorsanız klasör yapısını o şekilde şekillendirebilirsiniz. Fakat Views klasörü diğerlerinden farklı bir yapıya sahiptir.

Ä°simlendirme ile ayarlama diyebileceÄŸimiz bu yapı, Ruby on Rails’in bu kadar tutmasının nedenlerinden biridir aslında. Bu yapı sayesinde Controller sınıfları ve View dosyaları arasında ekstra bir iliÅŸkilendirme yapmak zorunda kalmıyorsunuz. Ä°ÅŸin güzel tarafı, ilgili Controller sınıfına ait bir View eklemek istiyorsanız, sadece bu Controller sınıfı ile aynı ismi taşıyan bir klasör içine View dosyanızı yerleÅŸtirmeniz yeterlidir. Mesela AnaSayfa isimli bir Controller sınıfının Index adlı bir action metodu varsa bu action metoda ait View dosyası, /Views/AnaSayfa/Index.cshtml dosyası olacaktır. Bu varsayılan isimlendirme yapısını isterseniz yeni bir Controller Factory tanımlayarak deÄŸiÅŸtirebilirsiniz. Bu makalemizin konusu deÄŸil, ama illaki incelemek isterseniz DefaultControllerFactory sınıfını ve IControllerFactory arayüzünü inceleyebilirsiniz.

Bu yapı sayesinde göstermek istediÄŸimiz bir View dosyasını action method’dan dönüş yapmamız kafidir. Mesela:

public ActionResult Index()
{
    return View();
}

ile Index metoduna ait Index.cshtml dosyasını dönderirsiniz. Eğer başka bir view dosyasını sonuç vermek isterseniz:

public ActionResult Index()
{
    return View("BaskaBirView"); //Aynı controller içindeki BaskaBirView.cshtml dosyası
}

yazmanız kafi gelecektir. Tabi bu son örnekte eÄŸer aynı controller klasöründe bu dosya bulunamazsa Shared klasörüne baÅŸvurulacaktır. Ayrıca “.cshtml” uzantısını girmediÄŸimize dikkat edin. Ä°lerideki makalelerde action method’lardan bahsetmek istiyorum. Ä°leride bu konuya daha detaylı bakabiliriz. Åžimdilik bu kadarı yeterli.

Yönlendirme (Routing)

Web Form ve PHP benzeri yaklaşımlarda varsayılan olarak bir url bir dosyaya işaret eder. ASP.NET MVC ise varsayılan olarak yönlendirme kullanmaktadır. Yani:

http://www.diyezon.com/index.php?p=365&d=07&m=08&y=2011

url’si yönlendirme kullanılmadığı vakit, sunucu index.php dosyasına eriÅŸmeyi deneyecektir. Fakat url yönlendirmesi kullandığınızda bu url:

http://www.diyezon.com/2011/08/07/asp-net-mvc-ve-razora-giris/

gibi bir hal alacaktır. Böylelikle url’den dosya bilgisine eriÅŸilemez ve seo’ya ve ziyaretçilerinize daha uygun url’ler üretmiÅŸ olursunuz.

MVC kütüphanesi, yönlendirmeye o kadar hakimdir ki, yönlendirmede yaptığınız ufak değişikliler otomatik olarak tüm sisteme uygulanır. Böylelikle url şablonunu değiştirseniz bile tüm sitede tek tek bul değiştir yapmak zorunda kalmazsınız. Üstelik url şablonu çok rahat ve zahmetsiz bir şekilde yapılandırılabilir.

MVC’de url yönlendirmenin iki temel iÅŸlevi vardır. Bu yüzden url yönlendirmeyi iki kısımda inceleyeceÄŸiz. Ä°lk kısımda url ÅŸablonları oluÅŸtururken, ikinci kısımda bunların site genelinde nasıl kullanıldığını göreceÄŸiz.

Gelen URL Ä°stekleri

Gelen url istekleri, ilgili controller ve action methoda iletilirler. Bu yönlendirme işlemi Global.asax dosyasında uygulamanın başlangıcında oluşturulmaktadır. Global.asax ile kastettiğimiz tabiki code-behind dosyası olan Global.asax.cs dosyasıdır. Yönelndirme işlemi Global.asax için şu şekilde tanımlanmıştır:

        protected void Application_Start()
        {
            ......
            RegisterRoutes(RouteTable.Routes);
            ......
        }
        public static void RegisterRoutes(RouteCollection routes)
        {
            //Route tanımlamaları burada bulunacak.
        }

Gördüğünüz gibi web uygulaması başlar başlamaz route yani yönelendirme kayıtlarımızı gerçekleştiriyoruz.

Gelen url isteklerinin hangi controller ve action method’a ait olduÄŸunu belirlemek için url ÅŸablonları(url pattern) oluÅŸturmamız gerekiyor. Bunun için tek yapmamız gereken RouteTable sınıfının Routes kolleksiyonuna yeni bir url ÅŸablonu tanıtmak olacaktır. Bunu da url ÅŸablonu oluÅŸturma yöntemlerinden en pratiÄŸi olan MapRoute metodu ile gerçekleÅŸtiriyoruz.

URL Şablonları

Yönlendirme sistemi bir çok yönlendirmeden oluÅŸan Routes kolleksiyonu ile çalışır. Bu kolleksiyonda tanımlı olan yönelndirmeler, hangi controller ve action method’un çalıştırılacağını belirler. Tek tek url’lerin nereye yönlendirileceÄŸini belirtmek yerine url ÅŸablonlarından(url pattern) faydalanıyoruz. Mesela aÅŸağıdaki url’ye bakalım:

http://www.diyezon.com/Home/Index

Url’deki ilk kısım yani domain kısmı bizi ilgilendirmiyor. Bu yüzden o kısmı gri ile belirttim. Sonrasında ise “/” slash karakteri ile ayrılmış olan iki segment(bölüm) görüyoruz. Birinci segment ile controller’ı ifade ediyoruz, ikinci segment ile çalıştırılacak olan action method’u ifade ediyoruz. Tabi biz bunu farkediyoruz fakat sisteme bunu nasıl tanıtacağız? Bu örnek için şöyle bir url ÅŸablonu oluÅŸturmamız kafi gelecektir:

{controller}/{action}

Gördüğünüz gibi iki adet segment tanımladık ve birincisine süslü parantezler ile controller değişkenini, ikinci segment ile de action değişkenini belirttik. Bu değişkenler(controller ve action) MVC yönlendirmede özel bir değere sahiptir. Yani uydurma değillerdir. Daha sonra göreceğimiz gibi url pattern içinde kendi değişkenlerimizi de tanımlayabileceğiz. Fakat isim olarak bu ikisini veremeyiz.

Gerçekte yönlendirme sistemi, bu ÅŸablonda bulunan deÄŸiÅŸkenleri sadece bir string olarak görür. Yani controller deÄŸiÅŸkenini gerçekte bir MVC controller nesnesi olduÄŸunu bilmez. Zaten yönlendirme sistemi MVC kütüphanesine deÄŸil .NET’e baÄŸlı genel bir sistemdir. Fakat bu aÅŸamadan sonra, yani url’miz bir pattern kullanarak ayrıştırıldıktan sonra, MVC controller ve action deÄŸiÅŸkenlerini alır ve iÅŸleme koyar.

Normalde url ÅŸablonları ile istediÄŸiniz kadar segment tanımlayabilirsiniz. Fakat bu örneÄŸimizde sınırlı sayıda segment almaktayız. Sadece bu ÅŸablon ile tanımlı bir yönlendirme sisteminde aÅŸağıdaki url’lerin aldıkları sonuçlara bakalım:

http://www.diyezon.com/Home/Index         => controller = Home,  action = Index
http://www.diyezon.com/Index/Home         => controller = Index, action = Home
http://www.diyezon.com/Home               => Segment sayısı az, eşleşme sağlanamaz
http://www.diyezon.com/Home/Index/Module  => Segment sayısı fazla, eşleşme sağlanamaz

Son iki örnekte eşleşme sağlanamadığından, sadece bir url şablonumuz olduğundan, kullanıcıya hata verilecektir. Önceden de dediğim gibi yönlendirme sistemi değişkenlerin içeriği ve varlığı ile ilgilenmez. Yani ikinci örnekte olduğu gibi Index isimli bir controller olmasa dahi bu yönlendirmeyi gerçekleştirir. Bu yüzden eğer segment sayısı tutuyorsa, url ne olursa olsun yönlendirmede eşleşme sağlanmış demektir.

Bu url şablonunu Global.asax dosyasında aşağıdaki gibi tanımlıyoruz:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "{controller}/{action}");
    }

MapRoute metoduna girilen ilk parametre bu yönlendirmeye vereceğimiz isim, ikinci parametre ise url pattern olmaktadır. Yönlendirmelere isim vermeye şimdilik ihtiyacımız yok. Sonraki bölümlerde isimlendirilmiş yönelndirmeleri de kullanacağız.

Varsayılan Değerler

GirdiÄŸimiz url segmentlerinden istediklerimize varsayılan deÄŸer atayabiliriz. Böylece o segmentin url’de belirtilmesi zorunluluÄŸunu kaldırmış oluruz. Mesela sitemizin ana sayfası için AnaSayfa controller sınıfını ve action method olarak Index kullanalım. Varsayılan deÄŸer kullanmazsak, sitemize girilmesi için illaki http://www.diyezon.com/AnaSayfa/Index girilmesi gerekirdi ki bu güzel bir sonuç deÄŸildir. Bu gibi durumlarda segment deÄŸiÅŸkenlerine girilmedikleri yani null oldukları vakit varsayılan deÄŸer belirleyebiliriz.

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "{controller}/{action}",
            new { action="Index" });
    }

Yukarıdaki oluşturduğumuz route ile action girmez isek yani http://www.diyezon.com/AnaSayfa gibi bir şey girersek, action değişkeni varsayılan olarak Index olacaktır. Aynı şeyi controller değişkeni için de yapabilirsiniz:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "{controller}/{action}",
            new { controller="AnaSayfa", action="Index" });
    }

Bu durumda http://www.diyezon.com şeklinde bir url girdiğimizde AnaSayfa controller sınıfındaki Index action metodu çalıştırılacaktır.

URL Sabit DeÄŸerleri

Bir url ÅŸablonuna sabit deÄŸerler ekleyebilirsiniz. Mesela:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "eski-makaleler/{controller}/{action}",
            new { controller="AnaSayfa", action="Index" });
    }

Bu pattern ancak “http://www.diyezon.com/eski-makaleler/” ile baÅŸlayan urller ile eÅŸleÅŸecektir. Sabit deÄŸerleri illaki bir segmente girmeniz gerekmez. Dilerseniz bir deÄŸiÅŸken ile bitiÅŸik bir ÅŸekilde kullanabilirsiniz:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "Eski{controller}/{action}",
            new { controller="AnaSayfa", action="Index" });
    }

Bu tanımlama ile http://www.diyezon.com/EskiAnaSayfa ÅŸeklinde girdiÄŸimiz bir url’de controller deÄŸiÅŸkeni yine AnaSayfa olacaktır, EskiAnaSayfa deÄŸil!

Yine başka bir yaklaşım ile sabit değerler ve varsayılan değerler ile bir karışım yapabilirsiniz:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(null, "Eski/{action}",
            new { controller="AnaSayfa", action="Index" });
    }

Bu durumda http://www.diyezon.com/Eski/Goster gibi bir url’de controller deÄŸiÅŸkeni yine AnaSayfa olacak ve action ise Goster olacaktır.

Makale henüz bitmedi. Sonraki sayfaya aşağıdaki linklerden geçebilirsiniz.

Yakın zamanda, benim bu tarz çekincelerimin olduÄŸunu bilen, asp.net kullanan bir dostum beni MVC ve Razor ile tanıştırdı. Ve açıkcası çok etkilendiÄŸimi itiraf ediyorum. Çünkü artık Web Forms gibi hantal olmayan, php’nin esnekliÄŸine sahip olan ve üstelik c# gibi nesne tabanlı programlamada sözü geçen bir dili kullanan bir ortam ile tanışmıştım.

Bu yazıda MVC ve Microsoft’un yeni çocuÄŸu Razor görünüm motorunu(view engine) tanıtıp, küçük bir örnek yapacağız

ASP.NET Web Forms’un Nesi Yok ki!?

Aslında kısa cevap olarak, “fazlası” bile var denilebilir. Evet belki de Web Formları ilk zamanlarda çok iyi bir fikirdi. Fakat gerçekte durum biraz daha karışık. Gerçek hayatta Web Formlarını projelerde kullandıkça bazı durumlar ortaya çıkmıştır. Tabi bu durumlar zaman içinde bir çok kullanıcının deneyimi ile ortaya çıkmış eksikliklerdir. Bu eksiklik ya da gereksiz fazlalıkları ÅŸu ÅŸekilde maddelendirebiliriz:

• View State Ağırlığı: View State olarak bilinen, istekler arasında durumları muhafaza etme mekanizması, client ve server arasında çok büyük boyutlarda veri transferine sebep oluyor. Bu veri boyutu, mütevazi bir sitede bile yüzlerce kilobayta varabiliyor. Ãœstelik bu veri, gönderilmekle kalmıyor tekrar geri geliyor ve her istekte veri iletimindeki miktar katlanarak büyüyor. Bu server üzerindeki bandwidth kullanımını artırdığı gibi, sitenin yavaÅŸ tepkilerinden dolayı site ziyaretçilerinin sinirlerinin bozulmasına da sebebiyet veriyor.
• Sayfa YaÅŸam Döngüsü: Sayfa yaÅŸam döngüsünün önemli bir parçası olan, client yani istemci tarafındaki event‘lar(olaylar) ile server tarafındaki event handler kodları arasındaki iletiÅŸim, aşırı derecede kompleks, karışık ve bir o kadar da narin, çıt kırıldım olabiliyor. Çok az geliÅŸtirici View State hataları olmadan çalışma zamanında bileÅŸenlerin(kontrollerin) üzerinde düzgün bir ÅŸekilde deÄŸiÅŸiklik yapabiliyor ya da çok az geliÅŸtirici gizemli bir ÅŸekilde çalışmayan event handler‘ları farkedebiliyor.
• Kod Ayrımı Hakkındaki Yanlış Düşünceler: ASP.NET’in code-behind modeli, HTML kodları ile uygulama kodlarını farklı bir dosyada ayırmaya yarıyor. Sunum kısmı ile uygulama kod kısmını ayırdığı için bu model, oldukça alkış getirdi ve takdir gördü. Fakat gerçekte, geliÅŸtiriciler sunum kodları(server kontrollerini deÄŸiÅŸtirmek gibi..) ile uygulama mantık kodlarını(veritabanını kodları gibi…) bu korkunç code-behind sınıflarında birleÅŸtirmeye baÅŸladılar. Bu da çoÄŸu zaman manasız ve narin, kolay bozulan bir sonuca dönüşmesine yol açmıştır ve açmaktadır.
• HTML Ãœzerinde Kısıtlı Kontrol: Server kontrolleri kendilerini HTML olarak render ederler yani bize sonuç HTML kodları olarak gelir. Fakat bu çoÄŸu zaman sizin istediÄŸiniz HTML kodundan gereksiz bir çok kod barındırır. ASP.NET 4′den önce genellikle bu çıktı kodu, web standartlarına uygun deÄŸildi veya bunlar üzerinde iyi bir CSS kullanımını zorlaÅŸtırıyordu. Ayrıca server kontrolleri Javascript tarafından ulaşılması zor olan, tahmin edilmesi zor ve karışık ID deÄŸerleri üretiyorlardı. Her ne kadar ASP.Net 4 ile bu problemler azaltılmışsa da beklediÄŸiniz HTML’yi elde etmeniz halen sıkıntılı olabiliyor.
• Zayıf Soyutlama: Web Formları mümkün olduÄŸunca HTML’yi sizden gizlemeye çalışır. Yeni ve özel bir davranışı tanımlamaya çalıştığınızda, genellikle bu soyutlamayı bozarsınız. Ki bu sizi postback event mekanizmasında ters mühendislik metodları kullanmanızı ya da istediÄŸiniz HTML’yi elde etmek için duygusuz ve absürd kodlar yazmanıza sebep olur. Ben buna amele mantığı kod yazmak diyorum . Ek olarak tüm bu soyutlama hadisesi, iÅŸin ehli web geliÅŸtiricileri için sinir bozucu bir engelden öteye gidememektedir.
• Düşük Test Edilebilirlik: Her ne kadar unit-test yani otomatikleÅŸtirilmiÅŸ testlere ilgim olmasa da, unit-test kullanan geliÅŸtiriciler için Web Formları bir çileden ibaret olmuÅŸtur. Web Formlarının bu kapalı hali unit testi için uygunsuz bir durum teÅŸkil etmektedir Projeye unit-test dahil etmenin zorluÄŸu da cabası…

Her ne kadar ASP.NET 4 ile burada bahsedilen bazı problemlere çözüm getirilmeye çalışılmışsa da halen çoğu kısıtlamalar ve eksikliker aynen durumunu muhafaza etmektedir.

Model, View, Controller

MVC başlıca şu üç ana daldan oluşan bir yazılım geliştirme tekniğidir:

• Model: Ä°letimde kullanılan ya da veritabanı gibi ortamlarda kullanılan veriyi ifade eden basit sınıflardır. Web programlamada bu genelde formun POST verileri ya da veritabanındaki bir tabloyu ifade eden bir sınıf olabilir. Sonuçta View ve Controller arasında veri iletimini Modeller ile gerçekleÅŸtirmekteyiz.
• View: Sunum kısmıdır. Yani bu web prgramlama için html sayfasıdır. Razor söz konusu olduÄŸunda dosya uzantısı “.cshtml” dir. EÄŸer Aspx görünüm motoru kullanılıyorsa bu uzantı “.aspx” olacaktır. Görünüm motorları(View Engine) ve Razor hakkında ileride daha genişçe bahsedeceÄŸiz.
• Controller: Esas iÅŸ gören uygulama kodlarıdır. Mesela bu, form verilerini veritabanına ekleyen bir sınıf olabilir. Sonuçta view katmanının kullanıcıya gösterilmesi için gerekli iÅŸlemleri controller gerçekleÅŸtirecektir.

Sizi çok terim ile boğmak istemiyorum. Daha fazla bilgi edinmek isterseniz burayı ziyaret edebilirisiniz.

Bir iletiÅŸim sayfasını gözümüzün önüne getirelim. Ne vardır basit bir iletiÅŸim sayfasında? Ad soyad, e-posta gibi bilgilerin girildiÄŸi bir textbox, mesajın yazılacağı bir textarea ve mesajın gönderileceÄŸi bir submit düğmesi. Submit düğmesine tıkladığınız anda, form post edilir ve gerekli kontroller yapılarak e-posta gönderilir ya da kullanıcıya hata verilir. MVC mantığı ile düşündüğümüzde, içinde textbox, textarea, button bulunduran sayfamız View katmanıdır. Form post olduktan sonra gelen verilerin uygunluÄŸunu test eden ve e-postanın gönderimini saÄŸlayan kısım ise Controller‘dır. Model ise bu iki katman arasında gelip giden form’un post verilerinin ÅŸablonudur. Bu örnek için textboxlardaki ad soyad ve e-posta bilgileri ve textarea’daki mesaj verisi Model ile ifade edilir.

Model ve Controller “.cs” uzantılı bir dosyada bulunan sınıflardan ibaretken View “.cshtml” uzantılı c# ve html kodlarının karışık olduÄŸu bir dosyadır. Bu uzantıların C#’a ait uzantılar olduÄŸunu ifade etmek istiyorum. EÄŸer Vb.Net kullanıyorsanız bu uzantılar “.vb” ve “.vbhtml” olacaktır. Veya Razor yerine baÅŸka bir görünüm motoru kullanıyorsanız “.cshtml” uzantısı deÄŸiÅŸiklik gösterecektir.

MVC aslında yeni bir teknoloji olmadığı gibi mucidi Microsoft da deÄŸildir. MVC, kökleri 1978 yılına dayanan ve Xerox PARC da Smalltalk projelerinde kullanılmış bir yöntemdir. Fakat günümüzde web programlamada ciddi ölçüde popülerlik kazanmıştır. Özellikle Ruby on Rails ile bu had safhaya ulaÅŸmıştır. Ruby on Rails‘in bu popülerliÄŸi o kadar artmıştır ki Microsoft’un gözünü açmasına sebep olmuÅŸtur. Ruby on Rails‘in bu baÅŸarısını, kullandığı dilden çok, içine monte edilen MVC ve ORM mimarilerine baÄŸlamak gerekir. Microsoft sadece MVC’ye el atmamış, ayrıca bir ORM mimarisi olan Entity Framework ve beraberinde LINQ de .NET’e dahil olmuÅŸtur. Evet ORM’nin ünlü olmasına sebep LINQ ve Entity Framework deÄŸildir aslında.

Åžu an için bir çok dilde MVC yapısını kullanan kütüphaneler mevcuttur. Mesela php’de CakePhp, Symfony ve Mojavi MVC kütüphanelerine en güzel örneklerdendir. Fakat bulabileceÄŸiniz çoÄŸu MVC kütüphanesi Rails’den esinlenmiÅŸtir.

Belki şu an için kafanızda MVC ne olduğuna dair somut bir fikir oluşmamış olabilir. Makelenin sonununda vereceğimiz küçük örneği kendiniz yaparak somut fikir edineceğinizi tahmin ediyorum.

ASP.NET MVC

MVC mimarisi, Web Forms mimarisinden farklı bir yapıya sahiptir. Web Formlarında tut-taşı mantığı ile çok hızlı bir şekilde siteler oluşturabilirsiniz. Fakat iş yukarıda da bahsettiğimiz gibi özelleştirmeye ve temiz html kodlarına geldiğinde, durum biraz değişiyor. ASP.NET MVC, temiz, standartlara uyumlu html kodları üretmenin farkındadır. Ve barındırdığı Html yardımcı metodları, Web Formların aksine, ciddi ölçüde temiz ve standart uyumlu kodlar üretirler. Küçük bir kontrol için bile bir çok hantal ve karışık kodlar üretmek yerine, CSS ile şekillendirilmiş gayet basit ve hoş kodlar üretir.

Hemen akla gelen, Web Formlarındaki gibi, kodları hazır, menü ve tarih seçici gibi bileşenleri olsa iyi olmazmıydı. Bunun için en iyi çözüm jQuery gibi javascript bileşenleri olacaktır. İşin gerçeği Web Formları kullanırken bile Web Formlarının varsayılan bileşenleri yerine bu tarz bileşenleri daha fazla kullanmaktayız. Bununla birlikte ASP.NET MVC dahili jQuery desteğine sahiptir. Eğer bir fikir edinmek isterseniz buraya göz atabilirsiniz.

Web Formlarının aksine, ASP.NET MVC ile üretilmiş sayfalar View State namına hiç bir veri içermezler. Bu yüzden küçük bir site için bile yüzlerce kilobayt boyutunda olan bu hantallıktan kurtulmuş olursunuz.

Ayrıca ASP.NET MVC mükemmel bir yönelendirme sistemine sahiptir. Bu sayede şu şekildeki bir urlyi:

/web_motoru/Makaleler/Default.aspx?islem=goster&makale_id=41567&sayfa=1

daha temiz ve kullanıcılar için ve seo için daha uygun bir şekle zahmetsizce çevirebilirsiniz:

/makale/mvc-ve-razor/sayfa-1

Böylesine bir yapı hem SEO için hem kullanıcılar için hem de güvenlik için daha kullanışlı olacaktır.

Bunun dışında söyleyebileceÄŸim baÅŸka bir ÅŸey de, ASP.NET MVC’nin açık kaynak kodlu olduÄŸudur. Bunun bize getirdiÄŸi en büyük faydalardan biri şüphesiz debug aÅŸamasında ortaya çıkmaktadır. Sistem bileÅŸenlerinin nasıl çalıştığını görebileceÄŸiniz gibi geliÅŸtiricilerin yorumlarını bile kodlarda görebilirsiniz.

BaÅŸka bir ÅŸey ise, MVC stateless dediÄŸimiz bir yapıya sahiptir. Yani Web Formlarında olduÄŸu gibi sayfanın o anki durumu kayıt altında tutulmaz. Tersine bu yapıya tamamen karşı bir yapıya sahiptir. Bu yüzdendir ki önceden bahsettiÄŸimiz gibi View State’e ihtiyaç duymaz ve kullanmaz.

Razor

Microsoft sadece MVC ve ORM mimarilerini ASP.NET ortamına taşımakla kalmamış yeni bir görünüm motoru da kazandırmıştır. Görünüm Motoru(View Engine), uygulama kodları ile(bu makale için C#), html ve benzeri text tabanlı verileri iç içe kullanmanızı sağlar. ASP.NET MVC için tanımlanmış bir çok görünüm motoru bulunmaktadır. Bunların başlıcaları, Spark, SharpTiles, NHaml, WebForms(ASPX) ve Razor.

Kısacası; Spark, html benzeri bir gramere, SharpTiles java kullanıcılarına yakın bir gramere ve NHaml ise Rail benzeri bir gramere sahip. WebForms ise bildiğimiz ASPX görünüm motorudur. Tüm kodlar <% ve %> işaretleri arasına yazılır.

Razor, Microsoft tarafından geliştirilmiş olan yep yeni bir gramere sahip bir görünüm motorudur. Yeni gramer derken sakın korkmayın. Çünkü Razor diğer görünüm motorlarında olduğu gibi sizi yeni bir grameri öğrenmek zorunda bırakmaz. Kullanacağınız dil yine C# gibi bir .net dili olacaktır. Kısaca Razor:

• Az yer kaplayan, kompakt, anlamlı ve akıcı bir yapıya sahiptir.
• Öğrenmesi çok kolaydır.
• Sizi yeni bir dil öğrenmek zorunluÄŸundan kurtarır.
• Çok çok iyi bir Intellisense desteÄŸi mevcuttur.
• Unit-test’lerine uygun bir yapısı mevcuttur.

Mesela aşağıdaki ASPX görünüm motoru ile oluşturulmuş kodlara bakalım:

<ul>
<% foreach (var country in Model)
   { %>
        <li><%: country.GetCountryCode(); %></li>
<% } %>
</ul>

Bu kodların Razor karşılığı ise şöyle olacaktır:

<ul>
@foreach (var country in Model)
{
    <li>@country.GetCountryCode()</li>
}
</ul>

Bilmiyorum farkettiniz mi ama C# kodu yazmak için sadece “@” iÅŸaretini kullandık. Gördüğünüz gibi çok sade bir grameri var. Ä°lerledikçe bu gramere aÅŸina olacaksınız ama bir kaç küçük detaya deÄŸinmek istiyorum.

Yukarıdaki küçük örnekte gördüğünüz gibi basit bir Razor kodunu şu şekilde yazıyoruz:

<div>Ä°sminiz: @Model.Name</div>

“@” iÅŸareti ile baÅŸlayan inline kodunu herhangi bir ÅŸey ile kapatmıyoruz. Bir nesnenin ya da strict sınıfın bir özelliÄŸini ya da metodunu html kodumuz içine yazdırmak istiyorsak bu tarz kullanımı tercih edebiliriz. Gördüğünüz gibi @ ile baÅŸlayan kod bloÄŸu, “;” veya “%>” gibi herhangi bir sonlandırıcıya ihtiyaç duymadan, bir satır sonlandırıcısı, bir text ya da html tag’ında sonlanıyor.

Razor daha karmaşık kod bloklarının da benzer bir şekilde üstesinden gelir. Mesela bir if bloğunu ele alalım:

@if (Model.WebSiteName == "Diyezon")
{
    <div>@Model.WebSiteName sitesinin adresi: <a href="@Model.WebSiteUrl">@Model.WebSiteUrl</a></div>
}

Razor süslü parentez ile başlayıp ve biten bu bloğun içeriğini C# kodu olarak kabul eder. Tabiki Razor sahip olduğu akıllı gramer sayesinde blok içinde <div> ile başlayan satırı C# kodu olmadığını anlar ve o satırı html ya da text satırı olarak algılar. Bu satır <div> ile başladığı için içine yerleştireceğimiz tüm C# kodları da @ işareti ile başlamalıdır.

Yukarıdaki örnekte gördüğünüz gibi birden fazla kod satırı eklemek istediğimiz durumlarda kod bloklarını kullanabiliriz. Yani:

@{
    string BirString = "Bu bir string";
    int sayi = 5;
}

Bir kod bloÄŸunun bir satırının ilk terimi bir önceki örnekte olduÄŸu gibi bir html tag’ı ise(bir önceki örnekte <div> idi), Razor bu satırı text ya da html satırı olarak algılar. Fakat bu son örnekte olduÄŸu gibi normal bir karakter ile baÅŸlarsa, Razor bu satırı c# kod satırı olarak algılar. Bu yüzden satırı “;” ile sonlandırdık. Çünkü bu satır c# kod satırı.

Peki kod bloÄŸu içinde html tag’i olmadan düz bir yazıyı nasıl yazarız?

<p>
@{
    @:Normal bir yazı satırı<br />
    <text>Normal bir yazı
          satırı daha. Ama bu sefer
          tek satır değil.</text>
}
</p>

Yukarıda iki yöntem ile de bir kod bloÄŸu içinde yazı yazabiliriz. Yukarıdaki örnekte ikinci satırın “<text>” tagı ile baÅŸladığına dikkat edin. Bu tag bir html tag’ı gibi gözükse de Razor’a ait özel bir tag’dır. Ve bu tag kaynak kodda gözükmeyecektir. Yani yukarıdaki örneÄŸin html çıktısı aÅŸağıdaki gibi olacaktır:

<p>
Normal bir yazı satırı<br />
Normal bir yazı
satırı daha. Ama bu sefer
tek satır değil.
</p>

Gördüğünüz gibi <text> tagı çıktıda gözükmemektedir. Kısacası bir kod bloÄŸunun içinde bir text ya da html satırı açmak istiyorsdak “@:” ya da “<text>” kullanmalıyız. Seçim size kalmış.

Razor görünüm motoru tahmin ettiğimizden daha akıllı davranır. Mesela aşağıdaki gibi yazıyı:

admin@yahoo.com

bir e-posta olarak algılar. Yani “yahoo” sınıfının ya da nesnesinin “com” özelliÄŸini çağırmaz. Veya aÅŸağıdaki gibi bir inline koduna bakalım:

Merhaba @adSoyad. Bu günün tarihi @tarih.

Inline kodların sonundaki “.” iÅŸaretine dikkat edin. Razor bunu normal text olarak algılayacak kadar ve bir metod ya da özellik çağıran nokta gibi algılamayacak kadar zekidir.

Daha fazla ayrıntıya girip kafanızı şişirmek istemiyorum. Şimdilik bu kadarlık gramer bilgisi fazlasıyla yeterli. Eğer daha fazla detaya inmek isterseniz şuradaki sitede güzel bir tablo hazırlanmış, müracaat edebilirsiniz.

MVC’ye Hazırlık

Ben ÅŸu anda Visual Web Developer 2010 Express sürümünü kullanıyorum. Hem bedava hem de her ihtiyacınızı karşılamakta. Express sürümlerin eksiÄŸi unit-test hadisesi ki ben unit-test ile uÄŸraÅŸmayı sevmediÄŸimi söylemiÅŸtim zaten. Ama kullandığınız Visual Studio sürümü her ne ise Web Platform Installer ile ASP.NET MVC 3 paketini rahatlıkla kurabilirsiniz. EÄŸer MVC’nin daha düşük bir veriyonu kurulu ise yine Web Platform Installer ile ASP.NET MVC 3 Tools Update paketini kurmalısınız.

Yine IIS Express ve SQL Server Express versiyonlarını da kurmanızda fayda var. IIS Express kurmanızda fayda var çünkü ASP.NET Development Server IIS’in desteklediÄŸi SSL gibi bir çok ÅŸeyi desteklemiyor. SQL Server Express de hâkeza eÄŸer veritabanı kullanan bir proje geliÅŸtirecekseniz kurmanız gerekenlerden. Bu ikisi de Web Platform Installer ile sorunsuz bir ÅŸekilde kurulabilir.

ASP.NET MVC 3 paketini kurduğunuzda Visual Studio(VS) ya da Visual Web Developerda(VWD) yeni proje ekranında ASP.NET MVC 3 Web Application seçeneğini göreceksiniz. Eğer görmüyorsanız ASP.NET MVC 3 Tools Update paketini kurmamışsınız demektir.

Basit Bir Örnek Yapalım

Anlattıklarımızı somut bir ÅŸekilde kavrayabilmek için basit bir örnek yapalım. Makalenin başında MVC’yi tarif etmek için verdiÄŸimiz iletiÅŸim sayfası örneÄŸini yapmaya çalışalım.

Küçük bir not: Makale boyunca çoÄŸu terimin ingilizce orjinal hallerini kullanmayı tercih ettim ve ediyorum. Çünkü VWD ya da VS’de karşılaÅŸacağımız terimler hep bu ÅŸekildedir. Ve bu ÅŸekilde alışmanız daha yararlı olacak kanaatindeyim.

1. VWD ya da VS’yi açalım ve New Project ile yeni proje açalım. Dil olarak “Visual C#”, proje template’i olarak da “ASP.NET MVC 3 Web Application” seçeneÄŸini seçelim. Proje adı olarak “Iletisim” girelim ve pencereyi tamam’a basarak onaylayalım.
2. Karşımıza gelen pencereden “View engine” olarak Razor seçili olduÄŸuna dikkat edelim. Template olarak ise “Empty” seçelim ve projemizi oluÅŸturalım.

Solution Explorer’a göz attığımızda bir kaç dosya ve klasörün eklendiÄŸini göreceksiniz. Åžu an için bunlara yabancı olmamız doÄŸal. Bizim için burada en önemli klasörler Models, Views ve Controllers klasörleridir. Hiç bir ÅŸeye dokunmadan F5 ya da menüden Debug=>Start Debugging ile projeyi çalıştıralım. Bir kaç derleme iÅŸleminin ardından browser önümüze gelecek ve proje sayfasını bize gösterecek. Fakat göreceÄŸiniz gibi bir HTTP 404 hatası alacaksınız. Bunun nedeni henüz bir controller nesnemiz bulunmamasıdır.

Bir MVC mimarisinde gelen istekler Controller nesneleri tarafından iÅŸlenirler. Siz bir sayfayı çağırdığınızda, o url’ye ait controller bu isteÄŸi alır ve iÅŸler.

Bir controller genelde System.Web.Mvc.Controller sınıfından türeyen basit bir sınıftan ibarettir. Controller içindeki her bir public metoda action method adı verilir. Bu action metodlar web üzerinden herhangi bir url ile çalıştırılırlar. Her ne kadar zorunlu olmasa da oluşturduğumuz controller sınıflarını Controllers klasörü altına toplamaktayız. Şimdi ilk controller sınıfımızı oluşturalım.

1. Solution Explorer’dan Controllers klasörüne saÄŸ tuÅŸla tıklayalım ve Add->Controller seçeneÄŸini seçelim.
2. Karşımıza gelen Add Controller penceresinden isim olarak HomeController ismini verelim. Zaten gelen pencerede sadece “Default1″ kısımını seçerek burayı deÄŸiÅŸtirmenizi isteyecek.
3. Template olarak Empty girelim ve tamam tuşu ile onaylayıp sınıfımızı oluşturalım.

VWD IletisimController.cs dosyasını hazırlayarak önümüze sunacaktır. Hemen bir deneme yapmak için controller sınıfımızı aşağıdaki gibi düzenleyelim:

namespace Iletisim.Controllers
{
    public class HomeController : Controller
    {
        public string Index()
        {
            return "Merhaba dünya!";
        }
    }
}

Kaydedip ctrl+shift+b ile ya da projeye saÄŸ tuÅŸla tıklayıp build edelim. EÄŸer browser penceresini kapatmadı isek, sayfayı yenileyelim. Kapatmış isek saat’in yanındaki ASP.NET Developer Server ikonuna saÄŸ tuÅŸla tıklayıp Open in Web Browser seçeneÄŸini seçelim.

Gördüğünüz gibi Home controller çalıştırıldı ve Index action metodu çaÄŸrıldı. Sonuçta ekrana istediÄŸimiz bir text çıktı. Sayfanın kaynak koduna bakarsanız, sadece bizim belirlediÄŸimiz string’den baÅŸka bir ÅŸey olmadığını göreceksiniz.

VWD yeni proje oluÅŸturduÄŸunda varsayılan olarak birincil controller ismini Home ve birincil action metodu da Index olarak atar. Yani ana sayfa ya da kök url (“/”) çaÄŸrıldığında Home controller sınıfına ait Index action metodu çaÄŸrılacaktır. Ä°leride bunu nasıl deÄŸiÅŸtirileceÄŸini öğreneceksiniz. Ama illaki kontrol etmek isterseniz Global.asax dosyasında ki RegisterRoutes metoduna göz atabilirsiniz.

Eğer Index metodunu View sayfasını gösterecek şekilde ayarlarsak ne olacağını görelim bunun için Index metodunu şu şekilde değiştirin ve derleyip sayfayı yenileyin:

        public ViewResult Index()
        {
            return View();
        }

Derleyip sayfayı yenilediğinizde hata mesajları ile karşılaşacaksınız. Bu hata mesajlarından da göreceğiniz gibi bu Index metoduna ait varsayılan View sayfalarının nerelerde arandığını liste halinde gösterilmektedir.

Åžimdi bu controller’ı düzgün bir ÅŸekilde gösterecek bir view hazırlayalım. Bunun için ilk baÅŸta sayfada hangi verilerin olacağını düşünmeliyiz. Bu bir iletiÅŸim sayfası olduÄŸundan basit bir kaç textbox olması bizim için kafi gelecektir. Controller ve View’lerde kullanılacak olan verilerin Model sınıfları ile ifade edildiÄŸinden daha önce bahsetmiÅŸtik. Bu yüzden ilk baÅŸta veri modelimizi oluÅŸturalım:

1. Models klasörüne sağ tuş ile tıklayıp Add->Class seçeneğini seçelim.
2. İsim olarak IletisimModel yazıp entere basalım.
3. Oluşturulan yeni dosyayı aşağıdaki gibi düzenleyelim:

namespace Iletisim.Models
{
    public class IletisimModel
    {
        public string AdSoyad { get; set; }
        public string EPosta { get; set; }
        public string Telefon { get; set; }
        public string WebSitesi { get; set; }
        public string Mesaj { get; set; }
    }
}

Küçük bir ipucu: Özellikleri kolay bir şekilde oluşturmak için prop yazıp iki defa tab tuşuna basın.

Åžu anda Controller ve View’lerde kullanılacak olan veri modelimizi oluÅŸturmuÅŸ bulunmaktayız. Åžimdi bu veri modeli kullanan bir View oluÅŸturalım. Tabi ilk baÅŸta daha önce oluÅŸturmuÅŸ olduÄŸumuz controller sınıfını da bu modeli kullanacak ÅŸekilde deÄŸiÅŸtirelim:

1. HomeController.cs dosyasını açın.
2. Henüz değiştirmedi iseniz Index action metodunu aşağıdaki gibi değiştirin:

        public ViewResult Index()
        {
            return View();
        }

3. Ctrl+Shift+B ile projeyi derleyin.
4. Index metodunun üzerinde herhangi bir yerinde saÄŸ tuÅŸ ile tıklayın ve “Add View…” seçeneÄŸini seçin.
5. Eğer Index metodunun üzerinde tıkladı iseniz VWD, View adı olarak bu action metodunun ismini verecektir. Eğer View name alanında Index yazmıyorsa Index yazacak şekilde değiştirin.
6. View engine olarak yine Razor seçiyoruz.
7. “Create a strongly typed view” seçeneÄŸini iÅŸaretleyip altındaki kutucuktan IletisimModel isimli modeli seçelim. EÄŸer 3. adımdaki derleme iÅŸlemini yapmadı iseniz yeni oluÅŸturduÄŸunuz modeli burada göremezsiniz. Bu durumda buraya el ile Iletisim.Models.IletisimModel ÅŸeklinde model sınıfının ismini girmelisiniz.
8. Template kısmını empty yani boş bırakın.
9. “Use a layout or master page” seçeneÄŸini kaldırın. Böylelikle herhangi bir layout veya master page kullanmamış olacağız.
10. Diğer seçenekleri olduğu gibi bırakın ve Add tuşuna basın.

VWD bu işlemin ardından Views klasörüne controller sınıfımız ile aynı isimde yani Home isminde bir klasör oluşturacak ve bu klasörün içine Index.cshtml isimli bir view dosyası oluşturacak.Ve bu dosyanın içeriği şöyle bir şey olacak:

@model Iletisim.Models.IletisimModel

@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <title>Index</title>
</head>
<body>
    <div>

    </div>
</body>
</html>

Ãœst kısımdaki kodlar hariç geri kalan kısım tamamen bildiÄŸimiz saf html kodları. Yukarıdaki @model ile baÅŸlayan ilk satır, “Create a strongly typed view” seçeneÄŸi ile belirttiÄŸimiz modeli kullanacağımızı ifade ediyor. Sonrasında gelen kod bloÄŸu ise herhangi bir layout ya da master page kullanmayacağımızı ifade ediyor.

Şimdi projeyi derleyip browser sayfasını yenileyelim. Kaynak koda baktığımızda View dosyasındaki html kodlarının olduğunu göreceksiniz.

Åžu anda çok basit bir Model-View-Controller mimarisini oluÅŸturmuÅŸ bulunmaktayız. Her ne kadar ÅŸimdilik herhangi bir iÅŸlem yapmasa da MVC mantığını daha iyi kavramamızı saÄŸlayacaktır. Kısaca iÅŸleyiÅŸi özetlersek; Browser’dan kullanıcı url’yi istekte bulunur, server bu url’ye atanmış olan controller’ın yani örneÄŸimize göre Home controller’ın içindeki Index action metodunu çağırır. Ardından bu action metod, kendisine ait olan View sayfasını belirlenen veri modelini kullanarak çağırır ve kullanıcıya çıktı olarak gönderir.

Şimdi bu sayfamızı işler hale getirelim.

1.  Index.cshtml view dosyasını açalım ve içeriğini aşağıdaki gibi değiştirelim(Kendi elinizle düzenlemenizi şiddetle tavsiye ediyorum.):

@model Iletisim.Models.IletisimModel

@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <title>İletişim Sayfası</title>
</head>
<body>
    @using (Html.BeginForm())
    {
        <table border="0">
        <tr><th>Ad, Soyad: </th><td>@Html.TextBoxFor(m => m.AdSoyad)</td></tr>
        <tr><th>E-Posta: </th><td>@Html.TextBoxFor(m => m.EPosta)</td></tr>
        <tr><th>Telefon: </th><td>@Html.TextBoxFor(m => m.Telefon)</td></tr>
        <tr><th>Websitesi: </th><td>@Html.TextBoxFor(m => m.WebSitesi)</td></tr>
        <tr><th>Mesaj: </th><td>@Html.TextAreaFor(m => m.Mesaj)</td></tr>
        </table>
        <input type="submit" value="Gönder" />
    }
</body>
</html>

Küçük bir ipucu: View dosyalarında yaptığınız deÄŸiÅŸiklikleri görmek için projeyi tekrar derlemenize gerek yok. Browser’dan direk olarak sayfayı tazelemeniz yeterli olacaktır.

2. Home controller sınıfımıza geçelim ve aşağıdaki değişiklikleri yapalım:

namespace Iletisim.Controllers
{
    public class HomeController : Controller
    {
        [HttpGet]
        public ViewResult Index()
        {
            return View();
        }

        [HttpPost]
        public ViewResult Index(IletisimModel iletisimModel)
        {
            return View("Tesekkur", iletisimModel);
        }
    }
}

Küçük bir ipucu: Eğer IletisimModel sınıfını bulamadığından dolayı altı kırmızı ile çizilirse, klavye imlecini buraya getirin ve ctrl+nokta tuşlarına basın. Intellisense sizin için bu sınıfı arayacak ve using ile referansı ekleminizi sağlayacaktır.

Buraya kadar ne yaptığımıza bir göz atalım.

İlk adımımızda view sayfamızda bir form oluşturduk. Bunun için Html yardımcı metodlarından yararlandık. Bunları kullanmak zorunda değildik fakat ileride kullandıkça göreceğiniz gibi bu yardımcı metodlar model sınıfı ile birlikte çalışarak işlemlerimizi daha da kolaylaştırıyor.

Bu yardımcı metodlardan ilki, bir html formu oluÅŸturmamıza yarayan Html.BeginForm() metodudur. Bu metod diÄŸerlerinden farklı olarak using kelimesi ile beraber kullanılıyor. Böylece using kod bloÄŸu içindeki tüm kodlar, form elementinin içine yerleÅŸtiriliyorlar. Sayfayı browser’dan yenileyip kodlarına baktığınızda, göreceÄŸiniz gibi using kod bloÄŸunun baÅŸlangıcında form elementinin baÅŸlangıç tag’ı(<form>) ve kod bloÄŸunun bitiÅŸinde de form elementinin bitiÅŸ tag’ı(</form>) yer almaktadır. Bu metodun diÄŸer paremetre ve ayarlarına burada deyinmeyeceÄŸim. Ama tek söyleyeceÄŸim bu metod varsayılan olarak form elementinin POST veri gönderecek ÅŸekilde ayarladığıdır. Zaten kaynak kodlara baktığınızda siz de bunu farkedeceksiniz.

Html.TextBoxFor() ve Html.TextAreaFor() metodları ise paremetre olarak delegate tipinde veri alıyor. Bu metodlara paremetre olarak lambda kullanılarak model yapımıza ait özellikler ile iliÅŸkilendirme yapıyoruz. Burada delegate kullanmamak için TextBox() ve TextArea() metodları da kullanılabilir fakat bu ÅŸekilde model yapımıza bu form elementlerini baÄŸlamamız biraz daha uzun olacaktır. Ãœstelik delegate ve lambda kullanarak yazım yanlışlarının da önüne geçmiÅŸ oluyoruz. Özellikle ilk maddede bu kodları kendi elinizle yazmanızı istememin esas sebebi bu idi. “(m => m.” yazdıktan sonra intellisense’in çıkardığı listenin, daha önce tanımlamış olduÄŸumuz Model sınıfına ait olduÄŸuna dikkat edin.

Ä°kinci adımda ise controller sınıfımıza baÅŸka bir Index metodu daha ekledik. Ve bu metodlardan ilkini HttpGet ve diÄŸerini HttpPost öznitelikleri(attribute) ile ilÅŸikilendirdik. Böylelikle GET ile gelen bir istek ilk Index metodunu, POST ile gelen bir istek ise ikinci Index metodunu çalıştıracaktır. BildiÄŸiniz gibi her hangibir url’yi browser’dan talep ettiÄŸimizde browser server’dan GET ile istekte bulunur. Yani bu örneÄŸimize göre, kullanıcı sitenin url’sini browser’a yazıp entere bastığında ilk Index metodu çalışacaktır. Velevki herhangi bir form verisi sayfaya POST edilirse, bu durumda HttpPost ile iliÅŸkilendirilmiÅŸ olan ikinci Index metodu çalıştırılacaktır. View sayfamızda oluÅŸturmuÅŸ olduÄŸumuz form elementi POST veri yolladığında, ikinci Index metodu faaliyete geçecektir.

Burada ikinci Index metodundaki View sayfasını çağıran View() metoduna dikkat edin. Bu View() metodu, bu action metoda ait view sayfasını değil başka bir view sayfasını çağırmanızı sağlar.  Bunun gibi View metodunun bir çok overload versiyonları vardır. Tüm bu overload edilmiş metod çeşitleri için yardım dosyasına ya da Intellisense yardımına bakabilirsiniz. Biz bu örneğimizde view sayfasına belirlediğimiz modeli parametre olarak yollayan metodu kullanmayı seçtik.

Projeyi derleyip browser’da sayfayı yenileyin ve form’daki Gönder düğmesine basın. Karşılık olarak “Tesekkur” view dosyasının bulunamadığna dair bir hata mesajı alacaksınız. Buradan varsayılan olarak nerelerde bu dosya arandığını liste halinde görebilirsiniz. Bu view sayfasını da oluÅŸturup ekrana teÅŸekkür mesajı yazdıralım:

1. Home controller dosyasında herhangi bir yerde saÄŸ tuÅŸ ile yıklayın ve “Add View..” seçeneÄŸini seçin.
2. View name olarak Tesekkur girelim.
3. “Create a strongly typed view” seçili olacak ÅŸekilde Model class olarak yine IletisimModel modelini seçelim.
4. Template’i empty girelim ve yine “use a layout or master page” seçeneÄŸini kaldırıp Add tuÅŸuna basalım.
5. Tesekkur view dosyasını aşağıdaki gibi değiştirelim:

@model Iletisim.Models.IletisimModel

@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <title>Teşekkür ederiz!</title>
</head>
<body>
    <div>
        <p>Sayın @Model.AdSoyad,</p>
        <p>Bizimle irtibata geçtiğiniz için teşekkür ederiz.
        Size en kısa zamanda @Model.EPosta e-posta adresinizden
        ya da @Model.Telefon nolu telefonunuzdan ulaşacağız.</p>
        <p>İyi günler.</p>
    </div>
</body>
</html>

Åžimdi bu ÅŸekilde projemizi derleyip sonucu browser’da gözlemleyelim. Formda ki textboxlara bir ÅŸeyler yazalım ve Gönder tuÅŸuna basalım.

Gördüğünüz gibi “Tessekkur” view dosyamız hazırladığımız gibi ekrana basıldı. Fakat henüz controller sınıfımız, formdan gelen bu verileri iÅŸleyecek durumda deÄŸil. Ä°lk baÅŸta form verilerinin uygunluÄŸu kontrol edilmeli. Bunun için validation yani doÄŸrulama kontrolü yapmamız gerek.

1. IletisimModel isimli model sınıfımıza aşağıdaki gibi eklemeler yapalım:

    public class IletisimModel
    {
        [Required(ErrorMessage="Adınız ve soyadınız gerekli.")]
        public string AdSoyad { get; set; }

        [Required(ErrorMessage="Bir e-posta adresi girmelisiniz.")]
        [RegularExpression(".+\\@.+\\..+",
            ErrorMessage="Girdiğiniz e-posta geçerli değil.")]
        public string EPosta { get; set; }

        [Required(ErrorMessage="Bir telefon girmelisiniz.")]
        public string Telefon { get; set; }

        public string WebSitesi { get; set; }

        [Required(ErrorMessage="Bir mesaj girmelisiniz.")]
        [StringLength(500, MinimumLength=10,
            ErrorMessage="Girdiğiniz mesaj 10 ila 500 karakter arasında olabilir.")]
        public string Mesaj { get; set; }
    }

2. Home controller dosyasını açalım ve HttpPost öznitelikli Index metodumuzu şu şekilde değiştirelim:

        [HttpPost]
        public ViewResult Index(IletisimModel iletisimModel)
        {
            if (ModelState.IsValid)
            {
                return View("Tesekkur", iletisimModel);
            }
            else
            {
                return View();
            }
        }

3.  Son olarak Index view dosyamızı açıp şu değişikliği yapalım:

<body>
    @Html.ValidationSummary()<br />
    @using (Html.BeginForm())
    {
        <table border="0">

Projemizi derleyelim ve browser ile sayfamızı tazeleyelim. Sonucu gözlemlemek için textboxları boş bırakalım ve formu gönderelim.

Gördüğünüz gibi Tesekkur view sayfası yerine tekrar Index’e döndük. E-posta ve mesaj alanları haricindekileri düzgün bir ÅŸekilde dolduralım ve e-posta alanına e-posta adresi olmayan bir ÅŸey girelim ve mesaj alanına da 10 karakterden az bir ÅŸeyler yazalım ve formu gönderelim. Bu sefer de belirlediÄŸimiz diÄŸer doÄŸrulama mesajlarını göreceksiniz.

Ä°lk maddeden baÅŸlayarak kodlarımızı açıklayalım. Ä°lk maddede model sınıfımıza bazı öznitelikler(attribute) ekledik. Bunlar System.ComponentModel.DataAnnotations alanında tanımlıdırlar. Bu yüzden eÄŸer bu öznitelikleri yazdığınızda altları kırmızı ile çizilirse using ile bu alanı tanıtmalısınız (ya da ctrl+nokta ile otomatik eklettirebilirsiniz). Bu alan altında doÄŸrulama yapabileceÄŸiniz bir çok öznitelik mevcutur. Biz burada bir kaçını gösterdik. En basit doÄŸrulama özniteliÄŸi Required özniteliÄŸidir ve gerekli manasında olup alanın boÅŸ olup olmadığını kontrol eder. Yine ReqularExpression ile e-posta’nın uygun olup olmadığını kontrol için bir regexp tanımladık. Buraya yazdığımız regular expression bizim makalemizin konusu deÄŸil. Aynı ÅŸekilde StringLength ile alanın karakter boyutunu sınırlandırmış olduk.

İkinci maddede ise controller sınıfımızdaki HttpPost ile ilişkilendirilmiş olan Index metodumuz model verilerinin doğru olup olmadığını öğreniyor. Sonucunda doğru değilse form yani Index view dosyası tekrar gösteriliyor. Bunun için kullanılan özellik ModelState.IsValid özelliğidir.

En son olarak hata mesajlarını formumuz üzerinde göstrermek için @Html.ValidationSummary() metodundan faydalandık. EÄŸer sayfanın kaynak koduna bakarsanız textbox’lara da bazı class deÄŸerleri eklendiÄŸini görebilirsiniz. Bu sayede, biz burada yapmadık ama, hatalı giriÅŸ yapılmış textboxları css ile belirtebilirsiniz.

Tabi ki bu doğrulama en basit ve varsayılan şekliyle karşımızda. Fakat daha karmaşık doğrulamaları da MVC ile çok rahat bir şekilde yapabiliyorsunuz. Hatta view sayfasına eklediğimiz hata mesajlarının yapısını bile çok rahat bir şekilde değiştirebilirsiniz.

Aslında örneğimizin MVC ile ilgili kısmı bitmiş durumda. Fakat en son olarak mail gönderme işlemini de kodlarımıza ekleyelim ve projemizi tamamlamış olalım. Tesekkur view dosyasını açalım ve aşağıdaki eklemeleri yapalım:

</head>
<body>
    @{
        try
        {
            WebMail.SmtpServer = "smtp.birsunucu.com";
            WebMail.UserName = "kullanıcı adı";
            WebMail.Password = "şifre";
            WebMail.From = "iletisimformu@deneme.com";
            WebMail.Send("info@deneme.com", "İletişim Formu Mesajı", @<text>
                <p>Aşağıda bilgileri bulunan şahıs iletişim formunu doldurmuştur</p>
                <p>Adı Soyadı: @Model.AdSoyad</p>
                <p>E-Posta: @Model.EPosta</p>
                <p>Telefon: @Model.Telefon</p>
                <p>Web Sitesi: @Model.WebSitesi</p>
                <p>Mesaj: @Model.Mesaj</p>
                </text>);
            }
        catch (Exception)
        {
            @:<strong>E-posta gönderirken bir hata ile karşılaştık. Lütfen daha sonra tekrar deneyiniz.</strong>
        }
    }
    <div>
        <p>Sayın @Model.AdSoyad,</p>

Başka şekillerde de e-posta gönderimi yapılabilir. Biz burada view içinde mail göndermeye çalıştık fakat controller içinde de bu gönderim yapılabilir. Buradaki amacım daha çok Razor gramerine aşinalığınızı artırmaktır. Özellikle WebMail.Send metoduna girdiğimiz üçüncü parametreye dikkat ediniz.

Ä°nanıyorum MVC ve Razor’u benim kadar sevdiniz. Benden ÅŸimdilik bu kadar, yorumlarınızı bekliyorum.

İlerleyen zamanlarda başka MVC makaleleri ile karşınızda olabilirim. Klavyenize zeval gelmesin !

Fatih Tolga Ata © 2011

1. Otomatik Form Oluşturmayın: Normalde, projeye eklediğiniz her bir form uygulama tarafından otomatik olarak oluşturulmak üzere ayarlıdır. Bunu dpr dosyasının kaynak kodunda bulunan Application.CreateForm ile görebilrisiniz. Her ne kadar bu size formlara erişirken büyük kolaylık sağlasa da uygulamanın ilk çalışma zamanını önemli derece de yavaşlatmaktadır. Bu yüzden formları otomatik olarak oluşturmayın. Sadece ihtiyacınız olduğunda dinamik olarak oluşturun. Çoğu zaman sadece ana formu otomatik olarak oluşturmanız kafi glecektir.
2. Mümkün OlduÄŸunca Windows API’lerini Tercih Edin: Yapacağınız bir iÅŸlem için eÄŸer Windows API’lerinde bu iÅŸi göre bir fonksiyon var ise, sakın ayrı bir fonksiyon yazmaya kalkmayın. Windows fonksiyonlarını kullanmak bizim için en hızlı yöntem olacaktır. Bu yüzden bir fonksiyon yazmadan önce Windows API’si içinde bu iÅŸi yapan baÅŸka bir fonksiyonun olup olmadığından emin olun.
3. Küçük Fonskiyonlar İçin “inline” Direktifini Kullanın: Yeni Delphi sürümleri “inline” direktifini desteklemektedir. “inline” kullanmak exe boyutunu artıracaktır. Fakat hız da artacaktır. EÄŸer küçük fonskiyonlarınız varsa veya büyük olsa da çok fazla yerde kullanılmayan fonksiyonlarınız varsa, fonksiyon veya prosedür tanımlamasından sonra “inline” direktifini kullanın.
4. Table yerine Query Tarzı Bileşenler Kullanın: TTable gibi bileşenleri mümkün olduğunca kullanmaktan çekinin. Bunun yerine TQuery veya TSqlQuery tarzı bileşenleri tercih edin.
5. FastMM Kullanın: FastMM projesi, normalde Delphi 2005 ile Delphi’ye dahil oldu. EÄŸer daha düşük versiyon kullanıyorsanız kesinlikle FastMM kullanın. D2005 ve yukarısı için de yeni güncellemeler oldukça faydası olacaktır. Daha fazla bilgi için FastMM’i google’da arattırın.
6. Kodlarınızı Yazarken Disiplinli Olun: Kodlarınızı yazarken değişken, sınıf, fonksiyon isimlendirmelerinde belli bir standarta uyun. Bıraktığınız kod yorumlarını daha sonradan bakacak mışsınız veya başka birisi projeyi devam ettirecekmişcesine yazın. Bu ve bunun gibi kendinize kurallar belirleyerek disiplinli bir şekilde kodlarınızı yazın. Bu size, daha sonradan programınızı bitirdikten sonra kolay bir optimizasyon imkanı sağlayacak. Tekrar kodlara dönüp baktığınızda disiplinli ve düzenli yazılmış bir kod göreceksiniz ve yavaş çalışan veya hatalı çalışan kısımları daha çabuk farkedip, kodunuzu optimize edebileceksiniz.
7. Basm İle Optimizasyona Gidin: Basm yani Delphi içinde assembler kullanarak bazı önemli yerleri optimize edebilirsiniz. Özellikle hızın çok önemli olduğu yerleri bu şekilde optimize edebilirsiniz. Bununla ilgili olarak  daha önceden burada bir şeyler karalamıştık.

Tabi bunlar dışında hızı etkileyen başka faktörlerin de olduğunu unutmayın. Fakat ilk etapta bu adımlara dikkat etmeniz, programlarınızdaki çalışma hızını önemli derece artıracaktır. Buradaki adımların çoğunun tek dez avantajı, exe boyutunun biraz artabilmesi. Fakat bu devirde kimse exe boyutunu çok önemsemiyor.

Benim aklıma 7 adım geldi fakat sizlerin de önerileri olursa lütfen yorum yazarak katkıda bulununuz.

Güncelleme: 07.03.2009: Bu maddelere ek olarak buradaki yorumda bulunan 3 maddeye daha göz atmanızı tavsiye ediyorum. Saadettin beye teşekkürler.

Fatih Tolga Ata © 2009

Bu yazı serisi, önceden yazdığım makaleler gibi tecrübe ve bilgiye dayalı olmayacak. Okuduğum kitap ve makalelerden ve denemelerimden oluşacak. Bu yüzden bu makale serisinin hedeflediği kitle, sadece bu işin meraklılarına hitap ediyor. Derleyici-yorumlayıcı yazmak isteyenlere faydalı bir konu özeti olacağını düşünüyorum. Ayrıca bu işe yeni başlayacak olanlara veya başlamış ama bir sebepten dolayı yarım bırakmış kimselere de bir fihrist, bir yol haritası olacağını düşünüyorum. Tabi bu notları çıkarmakla ben de kendimi bu konuda geliştirmeyi düşünüyorum.

BaÅŸlarken..

İlk derleyici yazma merakım, bir işletim sistemi yazma merakım olduğunda başladı Gerçi işletim sistemi olarak sadece disketten boot edilebilir ve dos benzeri bir şeyler yazabildim ancak. Fakat bu gayretim bana çok şeyler kazandırdı. Öncelikle bilgisayar ve işletim sisteminin çalışma mantığını çok iyi bir şekilde sindirdim. Ayrıca assembler ve diğer programlama dilleri noktasında da çok faydası oldu. Ayrıca derleyicilerin işletim sistemleri için ne kadar önemli ve vazgeçilmez bir şey olduğunu da gördüm. Bütün o kodları assembler ile yazmak bir yana, herhangi bir hata olduğunda kafayı yememek bir yana. Bu tabiki ilk başlarda derleyici yazma merakından çok, derleyici yazma ihtiyacını doğurdu.

Tabi bunlar çok öncelerde kaldı. Artık eskisi gibi işletim sistemi yazmak gibi uçuk bir düşüncenin altına girmeyi düşünmüyorum. Fakat derleyici yazmak o kadar da uçuk, ütopik olan bir şey değil. Zira en ünlü programalama dillerine baktığınızda hemen hemen hepsinin ilk başlarda bir veya iki kişi ile yazıldığını görürsünüz. Bu konu ile ilgili araştırma yaptıkça, bu konunun anlaşılmasının çok zor olmadığını fakat teoriden pratiğe, uygulamaya dökmenin zorluğunu gördüm. Son zamanlarda derleyici tasarım teknolojisinin gelişmesiyle beraber uygulamaya dökme işlemi de artık -eskisi gibi- çok zor değil. Zamanı geldiğinde bu teknolojilerden bahsetmeye çalışacağım.

Bu Makale Serisi Kime Hitap Ediyor

Ä°lk baÅŸlarda da dediÄŸim gibi öncelikle bu iÅŸe meraklı olmalısınız. Bu konu sadece derleyici veya yorumlayıcı yazmaktan ibaret deÄŸil tabiki. EÄŸer yabancı bir dilden (mesala Ä°ngilizce’den) Türkçe çeviri yapan veya tam tersi iÅŸlemi yapan bir çeviri programı yapmak istiyorsanız, yine bu konu iyi bilmeniz gerekiyor.

Bir derleyici, yorumlayıcı yazabilmek için bir programlama diline iyi hakim olmanız da gerekmektedir. Bu yüzden bu makaleyi okuyabilmeniz için en az bir adet programlama dilini iyi bilmeniz gerekiyor. Üstelik nesne tabanlı programlamayı da bilmeniz işinizi daha da kolaylaştıracaktır.

Ayrıca şunu da belirtmek isterim. Bu konuda Türkçe kaynak yok denecek kadar az. Bu konuda kendinizi geliştirmek istiyorsanız ilk başta İngilizce ile başlasanız fena etmezsiniz.

Kitaplar ve Kaynaklar

Piyasada bu konu ilgili bir çok kitap mevcut. Kimi çok eski ve şu anki teknolojiye hitap etmiyor, kimisi de çok teoride kalıp pratikte hiç bir kullanımından bahsetmiyor. Onca kitap arasından kendimize referans kabul edebileceğimiz kitabı seçmek zor olabiliyor. Ben bunlardan beğendiğim ve gerçekten kaliteli kitapları tavsiye edeceğim. Bu kitaplar genel yorumlarda da iyi gözle bakılan ve günümüz derleyici teknolojilerine de uygun kitaplardır.

Benim tavsiye edebileceÄŸim kitaplar ÅŸunlar:

Compilers, Principles, Techniques and Tools; 2nd Edition: Bu kitap, derleyici tasarımının temel ve vazgeçilmez kitabı olarak kabul edilir. Derleyici tasarımcıları arasında ilk baskısının kapağındaki ejder figüründen dolayı “Dragon Book” ismiyle anılmaktadır. Kitabın ilk baskısı yanılmıyorsam 1986 yılında yayınlanmış. Fakat benim tavsiye edeceÄŸim 2. baskısıdır. 2. baskısı 2006′da çıktı ve deÄŸiÅŸen bir çok derleyici teknolojisini barındırmaktadır. Ä°yi bir baÅŸlangıç yapmak isteyen ve yanı başında referans kitap olarak bulundurmak isteyenlere tavsiye ediyorum.

Engineering a Compiler (Cooper, Torczon): Bu kitabı çok aramama rağman ancak ebay üzerinde bulabildim. Sıfır almak isteyenler için amazonda da mevcut. Ebook olarak bulmayı niyetlenenlere söyleyeceğim şey şu ki, bu kitabın internet üzerindeki ebookları eksik. Daha doğrusu draft, yani yazarın kitap çıkmadan çok önceki taslak metinlerinden oluşuyor. Şu ana kadar incelediğim kitaplar arasında işe yarar, teori ve pratik bilgisi iyi olan ve yeni derleyici teknolojilerine hitap eden nadir kitaplardan birisi.

The Definitive ANTLR Reference: İleride bahsedeceğim derleyici derleyicilerinden birisi olan ANTLR ile ilgili yazılmış güzel bir kitap. ANTLR derleyici derleyicisini tasarlayan ve yazan Terence Parr tarafından yazılmış olan kitapta, sadece ANTLR ile ilgili bilgi bulunmamakta. Bu kitapta derleyici tasarımının temel bilgileri yanında gramer oluşturma, lexer, parser çalışma mantıkları ve LL çakışmaları gibi bir çok konuda bilgi de bulunmakta. Önceki iki kitap, her ne kadar pratikte kullanılabilecek bilgiler içerse de genelde teoriyi hedefleyen kitaplardır. Fakat bu kitap, öğrendiğimiz teoriyi uygulumaya nasıl dökebilceğimizi ayrıntısı ile anlatmakta.

Derleyici-yorumlayıcı yazmak isteyen herkese bu üç kitabı ÅŸiddetle tavsie ediyorum. Bunlar dışında yardımcı olabilecek ÅŸu kitaplara da göz atabilirsiniz.Â

Bu kitaplarla beraber bir sorununuz olduğunda, internet üzerinde ANTLR ve Coco/R mail listeleri sizlere yardımcı olacaktır.

Ayrıca sourcefoge.net gibi bir çok sitede bulabileceğiniz açık kaynak kodlu derleyici projeleri bulunmaktadır. Özellikle Tiny C benzeri bir çok açık kaynak kodlu ve küçük (yani incelenebilir) derleyicilere ulaşabilirsiniz. Gcc, freepascal gibi büyük projeleri de inceleyebilirsiniz. Fakat bu projeler çok büyük olduklarından pek öğretme/öğrenme amaçlı değiller. Bunun yerine daha çok küçük ve deneysel projeleri bulup incelemekte yarar var.

Ben yeri geldikçe bu tarz projeleri bulup sizlerle paylaşacağım. Ayrıca yeni çıkmış olan veya benim yeni keşfettiğim güzel kitapları da burada yeri geldikçe tanıtmaya çalışacağım.

Bir sonraki bölümde derleyiciler hakkında temel teorik bilgiler bulacaksınız. Bir sonraki bölümde anlamadığınız yerler olursa burada verdiğim kitap ve kaynaklardan istifade edererek araştırırsınız. Çünkü bunlar temel konulardır ve sonrasında gelecek olan bölümler bu temel bilgiler üzerine inşa edilecektir.

Bölüm 1: Derleyiciler ve Çalışma Mantığı

Derleyici tasarımı, bilgisayar biliminde önemli bir sahayı oluşturmaktadır. En basit olarak bir derleyici, büyük bir bilgisayar programıdır. Bir derleyici, kaynak kodu alır ve belli bir bilgisayar mimarisine uygun çalıştırılabilir bir hedefe çevirir. Bu çevirimin bir parçası da girilen kaynak kodun imla analizini yani syntax analizini yapmaktır. Bu imla analizi sonucunda, kaynak kodlarda hata tespiti yapılır ve kaynak kodun derleyici içindeki karşılıklarına çevrilir. Derleyeci, daha sonra, bu çevrilmiş olan kaynaklara bir mânâ, anlam yükler. Bu anlam yüklemesi sonucunda, derleyici anlam hatalarını araştırır. Bu işlemden sonra da kaynak kodun derleyicide ifade ettiği anlama göre hedeflenen çıktı üretilir. Tabi bu açıklama çok yüzeysel bir açıklama ve adeta bu bölümde göreceklerimizin bir özeti hükmünde oldu.

Derleyici tasarımı, bir mühendislik çalışmasıdır ayrıca. Derleyici yazarı, bu yolda kendisine bol alternatifi olan, masrafı, avantajları ve zorluğu belirgin olan bir tasarım ortamı oluşturmak zorundadır. Her bir karar, oluşturulacak olan derleyiciyi etkileyecektir. Oluşturulacak olan ürünün kalitesi bu alınan kararlara bağlıdır.

Derleyici tasarımı, çok eski olmamasına rağmen, tatmin edici seviyelere kadar gelişmiş bir konudur. Bu konuda bir çok başarılara imza atılmıştır. Piyasada olan bir çok derleyici ve binlerce çeşit programalama dili ile beraber, bu konudaki bilgiler kullanılarak geliştirilmiş bir çok program, bunun ispatıdır. Bir problemi çözmek için bir çok yöntem geliştirilmiştir. Ben burada en güncel ve popüler tekniklerden bahsetmeye çalışacağım. Ama bilinki, bahsedeceğimiz her bir konu ve teknik için alternatifler mevcuttur. Bu alternatifleri araştırmak size kalmış.

Derleme İşlemine Genel Bakış

Bir program çalıştırılabilir olmadan önce, bir çok çevirim iÅŸlemlerine tabi tutularak hedef çalıştırılabilir kodlar oluÅŸturulurlar. Bu çevirim iÅŸlemini yapan programın özel adına derleyici (compiler) diyoruz. Derleyici, kendisinin anlayacağı bir dilde kaynak kodlarını alır ve çıkışta çalıştırılabilir kodlar üretir. Bu çalıştırılabilir kodlar Windows’da exe, dll, Linux’de elf, so gibi dosyalar olabilceÄŸi gibi, .net, java gibi sanal makinalar için çalıştırılabilir kodlar da üretebilir.

Ayrıca çalıştırılabilir kodlar, direk olarak işleme de tabi tutulabilirler. Yani javascript, vbscript gibi direk olarak derleme anında çalışan derleyiciler de mevcuttur. Bu tip derleyicilerin özel adına ise yorumlayıcı (interpreter) denilir. Her ne kadar bazı eski kaynaklarda yorumlayıcılar ve derleyiciler iki farklı şeylermiş gibi gösterilse de çalışma mantıkları aynı olduğu için hepsine genel olarak derleyici demeyi uygun buluyorum. Çünkü derleme işleminde, ileride ayrıntısı ile göreceğimiz gibi, ilk safha yorumlama, ikinci safha ise kod üretmedir. Yorumlayıcıların tek farkı, kod üretme safhası bulunmamasıdır.

Ayrıca yorumlayıcı kodları, çalışabilmek için bir yorumlayıcıya ihtiyaç duyarlar. Mesela php kodları php derleyicisine, basic kodları basic derleyicisine, javascript kodları ecmascript destekli bir browser’a ihtiyaç duyarlar. Bu kodlar, yorumlayıcı olmadan çalıştırılamazlar. Fakat C++, Delphi gibi derleyicilerin ürettiÄŸi kodları, direk olarak iÅŸletim sistemi üzerinden iÅŸlemci çalıştırmaktadır, daha sonradan derleyiciye ihtiyaçları yoktur.

Bir de günümüz teknolojisinde yorumlayıcı olan ama temelde derleyiciler gibi kod üretebilen derleyiciler de mevcuttur. Mesela php derleyicisi, yorumlayıcı gibi ayrı bir dosyaya iÅŸletim sistemine uygun bir kod üretmeden, hemen çalışmaya baÅŸlar. Fakat yorumlayıcılardan farklı olarak “kod üretir”. Bu kod tabiki ayır bir dosya deÄŸil, IIS, Apache gibi server’lara uygun yapıda opcode’lardır.

Günümüzde derleme iÅŸlemi yapan bir programı, yorumlayıcı, derleyici olarak kesin bir ÅŸekilde ayırmak zorlaÅŸmıştır. Bunun yerine hepsine derleyici demek ve derleme iÅŸlemindeki ilk bölüme yorumlayıcı demek daha doÄŸru olacaktır. Ve bu mantığın kavram karmaÅŸasını da önleyeceÄŸini düşünüyorum. Ve herhangi bir yorumlayıcıya derleyici demeyi de yanlış bulmuyorum. (Php yorumlayıcısı yerine, php derleyicisi demek bana daha uygun geliyor…)

Peki, kaynak kodumuz, derleyici ile tanıştıktan sonra hangi aşamalardan ve safhalardan geçiyor? Bu konuyu ayrıntısı ile ilerleyen bölümlerde göreceğiz. Burada özet mahiyetinde şöyle bahsedebiliriz:

Derleyici İşleyiş Diagramı

Genel manada bu şekilde olsa da hem arka planda, hemde görüntüde bir çok safha değişebilmektedir.

Kaynak kod derleyicimize geldiÄŸi vakit, ilk olarak, kaynak kodun harfleri teker teker iÅŸlenir ve tanımlanarak token dediÄŸimiz nesnelere dönüştürülürler. Bu iÅŸlemi gerçekleÅŸtiren parçaya Lexer denilir. Lexer’ın görevi, imla (syntax) analizi yapıp sonuç olarak bir token listesi oluÅŸturmaktır. Bu imla analizi sırasında kaynak kodda hatalar da bulunabilir. Bu hatalar Lexer tarafından tespit edilir ve imla hatası (syntax error) olarak bildirilir. Lexer, kaynak kodun ifade ettiÄŸi, edeceÄŸi anlam ile uÄŸraÅŸmaz. Hangi token’nın hangisinden sonra geldiÄŸi ile ilgilenmez.

Mesela aşağıdaki karakter katarına bakalım.

Lexer, bu karakter katarındaki her bir karakteri ayrıştırır. “width” kelimesini bir token, “:=” atama operatörünü bir token, 2 sayısını bir token ve “;” iÅŸaretini bir baÅŸka token olarak belirler. EÄŸer gramere göre bu karakter katarında hata mevcut deÄŸilse token listesini üretir. Burada ayrıca her bir boÅŸluk da, kimi lexer’lar tarafından, birer token olarak kabul edilmektedir. Ä°leride ayrıntısını göreceÄŸimiz token’ı Delphi’deki bir record veya C++’daki bir struct yapısına benzetebilirsiniz. Bu record ya da struct içinde, token’nın türü, bulunduÄŸu pozisyon gibi deÄŸerler bulunur.

Lexer, token listesini oluşturduktan sonra işlemini tamamlamıştır. Artık bu token listesini, Parser dediğimiz başka bir derleyici parçasına iletir.

Parser, bu token listesini alır ve bir aÄŸaç yapısı üretir. Bu oluÅŸturulan aÄŸaca, Parse AÄŸacı denilir. Token listesinden oluÅŸturulmuÅŸ olan parse aÄŸacı, yine tokenlardan oluÅŸmuÅŸ bir yapıdır ve derleyicinin tanıdığı gramere göre oluÅŸturulur. Parser eÄŸer aÄŸacı oluÅŸtururken gramere uygun olmayan bir token ile karşılaşırsa bunu hata olarak bildirir. Parserın ürettiÄŸi bu hataya “Gramer Hatası” yada “Parse Hatası” (Parse Error) denilir.

Parser, token içinde bulunan ve tokenın ifade ettiği text ile uğraşmaz. Tokenın karakter katarında hangi pozisyonda bulunduğu ile ilgilenmez. Ayrıca parser, lexer gibi, tokenın ifade ettiği anlam ile uğraşmaz. Parser sadece token listesinin dizilişine göre gramere uygunluğu kontrol eder. Bunun sonucunda da bu token listesinden oluşan bir parse ağacı üretir.

Misal olarak aÅŸağıdaki karakter katarından, Lexer ve Parser’ın ürettiÄŸi çıktılara bakalım:

Â

Lexer ve Parser Ä°ÅŸleyiÅŸi

Bu ağacın oluşturulmasının amacına daha sonra değineceğiz.

Parse aÄŸacı oluÅŸtuktan sonra bu aÄŸaç, Semantik Analiz’e (Semantic Analysis) tabi tutulur. AÄŸacın her bir yaprağında bulunan tokenlar, bu aÅŸamada derleyici için bir mânâ ifade etmeye baÅŸlarlar. Yani artık integer olan bir token, derleyici tarafından integer, deÄŸiÅŸken olan token ise deÄŸiÅŸken olarak anlam verilir. Bunun sonucunda ise, anlam olarak belli hatalar oluÅŸabilir. Bu aÅŸamada oluÅŸabilecek hatalara Semantik Hatalar (Semantic Errors) denilir. Mesela integer olan bir deÄŸiÅŸken, string olan bir deÄŸiÅŸkene direk olarak eÅŸitlenemez! Tabi bu örnek programlama dillerine göre farklılık da gösterebilir. Fakat genel manada integer bir deÄŸeri string bir deÄŸere direk olarak eÅŸitleyemezsiniz. Çünkü bunların token tipleri farklıdır. Bu tarzdaki, yani anlam bakımından yanlış olan iÅŸlemler semantik hataları oluÅŸtururlar.

Semantik analiz sonucunda herhangi bir hata oluşmamış ise parse ağacı yardımı ile intermediate code ya da intermediate representation dediğimiz ara bir kod oluşturulur. Tabi bu safha her derleyicide bulunmayabilir. Bu ara kod oluşturulduktan sonra kodlar optimize edilir ve tekrar son çıktı için kod üretilir. Bazı derleyiciler ara kod oluşturmadan direk olarak kod oluşturabilmektedir.

Bu iÅŸlemlerden bizi en çok zorlayan kısım lexer ve parser kısımlarıdır. Çünkü bu parçalar, programlama dilinin gramerini ifade eden, tanımlanmasında hata kabul etmeyen, hamaliyesi çok olan parçalardır. Bu zorluklardan dolayı bir çok “derleyici derleyicisi” denilen yardımcı programlar geliÅŸtirilmiÅŸtir. Her büyük derleyicide bu derleyici derleyicisi kullanılmaktadır. Bunu daha sonra ayrıntısı ile göreceÄŸiz.

Burada bahsettiÄŸimiz tabirler yabancı gelse de, ileride bunları daha iyi ve ayrıntısı ile bahsedeceÄŸiz. Ama genel olarak “Derleyici Tasarım Notları” baÅŸlıklı bu yazı serimiz bunlardan bahsedecektir. Burada bir nevi, anlatacaklarımızı özetlemiÅŸ olduk. Fakat ayrıntıda gizli, çok farklı teknikler ve yöntemler mevcut. Bunlara yeri geldikçe bahsedeceÄŸiz.

Â

________________________________

Birinci bölüm henüz bitmiÅŸ deÄŸil. Devamını bir baÅŸka zamana atıyorum.Â

Kolay gelsin.

Fatih Tolga Ata © 2009

Bu yazımızda C / C++ ve Delphi gramer bilgisi vermek yerine, daha çok C / C++ kodlarını en doÄŸru ÅŸekilde Delphi’ye nasıl adapte edebileceÄŸimizi göreceÄŸiz. Yapacağımız iÅŸlem sadece bire bir kod çevirisi olmayacak. Yeri geldiÄŸinde hiç bir kod çevirmeden sadece orjinal kütüphaneyi Delphi programımızın içine gömebileceÄŸiz.

EÄŸer siz de, ister derlenmiÅŸ olsun, ister açık kaynak kodlu olsun, bir C / C++ kütüphanesini Delphi’ye nasıl çevirebileceÄŸimizi merak ediyorsanız buyurun beraber yazımıza giriÅŸ yapalım.

GiriÅŸ

C / C++ ‘dan Delphi’ye kod çevirme derken ilk akla gelen, binlerce satırlık C kodlarını teker teker uÄŸraşıp Delphi olarak yazmak gelecektir. Halbuki bu en son tercihimiz olması gerekmektedir. Ä°lerleyen bölümlerde de göreceÄŸimiz gibi, Delphi derleyicisinin hünerli parmakları bizi bir çok dertten kurtarmaktadır. Yine de bütün kodları baÅŸtan çevirmek gibi bir derdin altına girmek isterseniz bu makale size bir baÅŸlangıç noktası olacaktır.

Hemen kodlara dalmak gerçekten gerekli mi? Kesinlikle gerekli deÄŸil. Çünkü bizim uÄŸraÅŸtığımız ÅŸey, önceden birileri tarafından yapılıp internet üzerinde dağıtılıyor olabilir. Bu yüzden ilk yapacağımız iÅŸlem bir “Delphi port” bulmamız gerekmetedir.

Mesela şuanda en hızlı ve en stabil xml kütüphanesi kabul edilen libxml2 kütüphanesini kullanmak istediğimizde, hemen kodları çevirmeye kalkmak yerine bir Delphi port bulmamız en akıllıca işlem olacaktır. Ki bu kütüphanenin başlık dosyaları zaten sourceforge üzerinde dağıtılmaktadır.

Bu makalede, C objelerinin kullanımı, C veri tiplerinin Delphi’deki karşılıkları, C baÅŸlık (header .h) dosyalarının Delphi’ye çevrilmesi gibi bir çok konu bulacaksınız. Bu bilgiler ile istediÄŸiniz bir C kütüphanesini korkmadan Delphi’ye adapte edebilirsiniz.

Bu makalede çok fazla C / C++ bilgisi gerekli mi? Gerekli olsa bu makaleye ihtiyaç duymazdınız. Fakat çok  az da olsa C / C++ gramerine aşinalığınız olmak zorunda. En basit olarak bir bir fonksiyon nasıl tanımlanır, bir değişken nasıl tanımlanır, bir pointer nasıl atanır, bunları bilmeniz gerekmektedir.

Fonksiyon Çağırım Mekanizmaları

Bir çinli ile anlaÅŸabilmek için bir tercüman tutmanız gerekti. Fakat çok aramanıza raÄŸmen çinli bir tercüman bulamadınız. Bunun yerine bir birine benziyor diye kalkıp, japonca bir tercüman tuttunuz. Çinli olan birisi ile ne kadar anlaÅŸabilirsiniz. Her ne kadar bize “benzer” gibi gözükse de iki dil bir birinden farklı dildir. Bu örneÄŸi ÅŸimdi göreceÄŸimiz konuya hazırlamak için verdim. Bu misalden hakikate ÅŸu ÅŸekilde geçebiliriz. DerlenmiÅŸ olan her bir kütüphanedeki fonksiyonlar belli bir dili konuÅŸmaktadırlar. Bu konuÅŸtukları diller görünüşte bir birlerine benzeseler de, ayrıntıda bir birlerinden farklıdırlar. Bu konuÅŸulan dillere fonksiyon mekanizmaları ya da ingilizce terim olarak “calling conventions” denilmektedir. EÄŸer kullanacağınız fonksiyon farklı bir dili kullanıyor ve siz de fonksiyonu farklı bir dil ile çağırıyorsanız muhtemel hatalar ile karşılaÅŸacaksınız. Bu yüzden ilk öğreneceÄŸimiz konu bu olmalıdır.

Direk olarak çağırım mekanizmalarının delphi karşılıklarını vermek yerine az da olsa bir kaç özelliklerinden bahsetmek istiyorum. Çünkü hangi çağırımı nerede ne için kullanacağımızı bilmemiz şarttır.

Şu an literatürde en çok kullanılan 4 çeşit fonksiyon çağırım mekanizması vardır. Bunların ne olduğunu ayrıntısı ile anlatan buradaki makalemize göz atabilirsiniz. Hatta okumadı iseniz bir göz gezdirmenizi şiddetle tavsiye ediyorum. Biz burada bu mekanizmaların çalışma şekillerinden çok işimize yarayan kısmını anlatmaya çalışacağız. Ama linkini verdiğim makalede bunların çalışma şekillerini ayrıntılı bir şekilde bulabilirsiniz.

Birinci olarak göreceÄŸimiz çağırım mekanizması register çağırımıdır. Delphi varsayalın olarak bütün fonksiyon ve metodlarda bu çağırımı kullanmaktadır. Normalde Dehlpi’de “register” ayrılmış kelimesini fonksiyon ya da metodun sonuna eklemekle, fonksiyon ya da metodu bu çağırım için ayarlamış oluruz. Fakat varsayılan olarak kullanıldığı için bunu yazmanıza gerek yoktur:

procedure RegisterCagirimliProcedure; register;

Fonksiyon çağırım mekanizmaları ile ilgili yazıyı okuduysanız en verimli ve performanslı çağırımın bu olduğunu biliyorsunuzdur. Bu mekanizma ilk olarak Borland tarafından geliştirilip C++ Builder ve Delphi derleyicilerinde kullanıldı. Şu anda bildiğim bütün C / C++ derleyicileri bu çağırımı desteklemektedir. C / C++ derleyicilerinde bu çağırım __fastcall olarak isimlendirilmektedir.

Her ne kadar en hızlı çağırım __fastcall yani register olsa da ve çoÄŸu derleyici tarafından desteklense de, belki de alışkanlıklardan dolayı, C / C++’da pek kullanılmamaktadır. Genelde Linux ve Windows’da ileride gelecek olan baÅŸka çağırımlar kullanılmaktadır.

__fastcall yani register çağırımları, Microsoft’uın derleyicilerinde __msfastcall olarak baÅŸka bir biçimi de almıştır. Fakat ÅŸu anda Delphi bu çağırımı desteklememektedir. Umarım ilerideki Delphi derleyicilerinde bunu görebiliriz. Fakat bu çağırım __fastcall kadar bile yaygın ve fazla kullanılmadığı için ÅŸu anda anlattığımız çevirim iÅŸlemi için çok da önemli deÄŸil. Hatta, eÄŸer bir kütüphane bir çok dili desteklemek gibi bir gayesi varsa __fastcall çağırımını da desteklememektedir.

Kısacası bu çağırımı delphi’ye aktarmak için hiç bir ÅŸey yapmamız gerekmiyor. Çünkü delphi bunu varsayılan olarak kullanıyor. Mesela aÅŸağıdaki C fonksiyonunu delphi’ye çevirelim:

__fastcall int birFonksiyon(int i);

function BirFonksiyon(i: Integer): Integer;

Ä°kinci çağırım mekanizmamız __pascal yada delphi’de pascal çağırımıdır. Ki bu çağırım Win 3.1 zamanından kalma eski bir çağırımdır. Bu yüzden eÄŸer karşılaşırsanız yapmanız gereken __pascal yerine pascal yazmalısınız.

Üçüncü çağırım mekanizmamız __stdcall ya da delphi’de stdcall çağırımıdır. Bu çağırım, Windows iÅŸletim sisteminin varsayılan çağırım mekanizmasıdır. EÄŸer windows’a ait bir DLL’i kullanacaksak, bilinki %99 stdcall olarak tanımlanmıştır. __stdacall çağırımı derleyicilerde çeÅŸitli takma adlar ile kullanılmaktadır. Genelde “WINAPI” kelimesi __stdcall için kullanılmaktadır. Mesela aÅŸağıdaki Windows API’sinden bulunan fonksiyonu şöyle çevireceÄŸiz:

WINAPI BOOL ReleaseCapture(VOID);

function ReleaseCapture: Boolean; stdcall;

Yardım dosyalarında bu fonksiyonun başında WINAPI ya da __stdcall ifadesini görmesek de, biliyoruz ki bu bir Windows fonksiyonudur. Öyleyse bu fonksiyon stdcall çağırımıdır. Bu çıkarım ile hem delphi hem de C kodunda bu çağırımı belli ettim.

Dördüncü ve son çağırımımız ise __cdecl ya da delphi’de cdecl çağırımıdır. Bu çağırım C / C++ derleyicilerinin varsayılan çağırımıdır. EÄŸer C dosyalarında hernangi bir çağırım belirtilmemiÅŸ ise, bu fonksiyon cdecl olarak çağırılacaktır. Yani aÅŸağıdaki fonksiyonlar aynı ÅŸeyi ifade edip her iksinin de çevirimi aÅŸağıda gösterilmektedir.

void bir_proc();
__cdecl void ikinici_proc();

procedure bir_proc; cdecl;
procedure ikinci_proc; cdecl;

İleride makroları göreceğiz. Aşağıdaki makro tanımlamaları da geçerlidir ve kullanılmaktadır.

__stdcall = _stdcal = CALLBACK = WINAPI = APIENTRY = PASCAL = APIPRIVATE

__cdecl = _cdecl = WINAPIV

__fastcall = _fastcall

Yukarıda eşitliklik ile ifade edilenleri birbirlerinin aynısı olarak kabul edebilirsiniz.

DLL Kullanımı ve Çağırımlar

Normalde bir DLL’den bir fonksiyonu kullanmak için fonksiyonu nasıl tanımlayacağımızı bir hatırlayalım:

const
  DLLDosyasi = 'birkutuphane.dll';
procedure bir_proc(); cdecl; external DLLDosyasi;

Kendi DLL’imizi kullandığımızda fonksiyonu nasıl tanımlayacağımızı biliyoruz. Peki DLL’i biz yazmamış isek ne yapacağız?

Bu durumda, eÄŸer herkes tarafından kullanılabilir bir DLL dosyası ise, DLL saÄŸlayan firma, ekip, yazılımcı, vs. DLL dosyası ile beraber bir “header” dosyası saÄŸlayacaktır.

Delphi’de, bildiÄŸiniz gibi, unit iki bloktan oluÅŸur. Birinci blok yani interface bloÄŸu, unit tarafından “unit dışında” kullanılacak olan sınıf, deÄŸiÅŸken, fonksiyon, vs. ‘den oluÅŸur. Ä°kinci blok yani implementation bloÄŸu ise, interface bloÄŸunda tanımlanmış olan fonksiyon ve sınıfların esas kodlarından oluÅŸur. Yani esas çalıştırılan kodlar implementation kısmında bulunur. Ayrıca implementation’da tanımlı herhangi bir deÄŸiÅŸken, fonksiyon, vs. eÄŸer interface’de tanımlı deÄŸilse diÄŸer unitlerde görünmezler ve kullanılamazlar.

C / C++ dosyaları da Delphi’nin unit dosya mantığının aynısıdır. Fakat Delphi’nin aksine C / C++ dosyaları tek parça halinde deÄŸil iki parça halinde tutulurlar. Delphi’de interface olarak ifade ettiÄŸimiz blok C ‘de “header” olarak ifade edilir ve “.h” uzantısına sahiptir. Nadir de olsa C++’da header dosyaları “.hpp” uzantısı alabilirler. Delphi’de implementation olarak ifade edilen esas çalışan kodlar ise C’de “.c” ve C++’da ise “.cpp” uzantısı ile ifade edilen dosyalardadır.

Header dosyaları, ÅŸart olmasa da, genelde kütüphanenin “include” adlı klasöründe barındırılmaktadır. Kullanacağınız DLL’in header dosyası da bu veya bunun benzeri bir klasörde bulunacaktır. Header dosyası olmadan Delphi çevirimi yapmamız çok zor olacaktır. Hatta üst düzey assembler bilginiz olması gerekebilir. Bu yüzden DLL ile beraber en az bir adet header dosyasına sahip olduÄŸunuzu varsayıyorum.

Bu başlık altında esas olarak anlatmak istediğim mevzuya şimdi geliyoruz.

DLL’e ait header dosyasına baktığımızda fonksiyonların hangi çağırım mekanizmalarını kullandıklarını görebiliyor ve anlayabiliyoruz. Fakat derlenmiÅŸ olan DLL dosyalarında bu çağırım mekanizmalarını belirten hernhangi bir iÅŸaret var mı?

Bunun için yardımcı bir araca ihtiyaç duyacağız. Aslında TDump isimli ve delphi ile beraber gelen bir konsol uygulaması bulunmakta. Ancak konsol uygulaması yerine göresel bir aracı tercih ederim. Ama illaki tdump kullanmak isteyen olursa “-b” parametresi ile beraber kullanabilirsiniz. Her neyse, ihtiyacımız olan program “Dependency Walker” . Bu program ile DLL’de bulunan tüm fonksiyonları isimleri ile beraber görebiliriz.

Peki header dosyasında fonksiyonlar ayrıntılı bir ÅŸekilde olmasına raÄŸmen neden ekstra bir araca ihtiyaç duyuyoruz. Aslında ekstra bir programa ihtiyacımız yok. Header dosyaları fazlasıyla yeterlidir. Fakat bazen DLL’ler varsayılan ayarlarla derlenmemektedir. Bu da bize sorun çıkarabilmektedir.

DLL’ler derlenirken fonksiyon isimleri çeÅŸitli ekler alırlar. Bu ekler, fonksiyonun hangi çağırımı kullandığını belirler. Ama bazen bu varsayılan isimlendirmenin dışına çıkan kütüphane yazılımcıları, bütün ekleri kaldırabiliyorlar. Mesela cdecl fonksiyonları önlerinde “_”  iÅŸaretini barındırırlar. Veya stdcall fonksiyonları fonksiyon isiminden sonra “@” iÅŸareti ve parametrelerin boyutlarını içeren bir dizi ekten ibarettirler. Dependency Walker gibi programlar, bize fonksiyonların hangi isimlerden oluÅŸtuÄŸunu gösterecektir. EÄŸer header dosyasını Delphi’ye hatasız aktardık fakat halen fonksiyonun bulunmadığına dair hata alıyorsak demek ki isimlendirmeler yanlış demektir. Bunun için aÅŸağıdaki yöntemi kullanmalıyız:

procedure BirProc; cdecl; external DLLDosyasi name '_bir_proc';

Gördüğünüz gibi “external” direktifinin hemen sonuna bir boÅŸluk ile beraber bir name direktifi ekledik. Bu “name” direktifi ile DLL’deki fonksiyona direk olarak iÅŸaret etmiÅŸ oluyoruz. Bu tekniÄŸi sadece ihtiyaç dahilinde kullanabilirsiniz. Veya C / C++ ismi size hoÅŸ gelmedi ise fonksiyonun ismini Delphi’de kullanım adını deÄŸiÅŸtirmek için kullanabilirsiniz.

Not

Bir tecrübemi aktarmak istiyorum. EÄŸer C / C++’a fazla hakim deÄŸilseniz, muhtemelen header dosyalarını çeviriken bir çok hata yapacaksınız. Bu durumda DLL’i statik olarak kullandığınızdan dolayı, delphi programı derleyecek ama çalıştıramayacktır. Ve program donacaktır. Çünkü istediÄŸi DLL içinde sizin tanımladığınız gibi bir fonksiyon bulamamıştır. Bunun yerine ilk baÅŸlarda, header dosyasının çevirimi doÄŸru bir ÅŸekilde çevrilene kadar, DLL dosyasını dinamik olarak yükleyin. Bu ÅŸekilde çıkan hataları, hangi fonksiyon tanımlamasından kaynaklandığını belirleyebilirsiniz. Dinamik DLL yüklemesinin nasıl yapıldığını internetten araÅŸtırarak bulabilirsiniz.

Not

Header dosyalarını çevirmek için aslında JEDI kütüphanesine ait bir araç bulunmaktadır. Fakat bu araç da tam olarak header dosyalarını çevirememektedir. Daha doÄŸrusu yine burada anlattığımız bilgilere ihtiyaç duyacaksınız. Bu araç sadece çok büyük dosyalarda yazım kolaylığı saÄŸlamak açısından bir kolaylık getirmektedir. Ayrıca ileride anlatacğımız konular için bu araç yetersiz kalmaktadır. Bu araca Dr. Bob’un sitesinden ya da JEDI kütüphanesinden eriÅŸebilirsiniz. (Header Conversation Tool)

Çağırım mekanizmalarına hakim olmak Delphi çevirimi noktasında size büyük kolaylık sağlayacaktır. Bu yüzden bu konuyu ilk sıraya aldım ve biraz da uzun tuttum.

Veri Tipleri

C / C++ kodları, çok fazla pointer ile ilgili iÅŸlemleri barındırmaktadır. Basit bir tip tanımlamasında bile pointerlara ihtiyaç duyarsınız. Fakat C / C++’da bulunan bu pointer kullanımı Delphi’ye geçtiÄŸinde illaki pointer kalacak diye bir ÅŸart yoktur. Kullanımda bu olay farklılık göstermektedir.

İlk önce basit veri tiplerinden başlayalım. Aşağıdaki fonksiyona bir göz atalım:

char* birfonksiyon(void);

Burada “char*” olarak çıktı veren bir fonksiyonuz mevcut. C’de “*” iÅŸareti pointer tanımlamak ve çarpım iÅŸlemlerini yapmak için kullanılır. EÄŸer char, int gibi bir tip ile birlikte kullanılıyorsa bu, pointer operatörüdür. Bu örnekte “char*” ifadesi bir char iÅŸaretçisini ifade eder. Bu Delphi’de PAnsiChar ile ifade edilir. PChar demiyorum çünkü Delphi 2009 ile beraber artık PChar unicode oldu. Fakat buradaki “char” ansi olan bir char tipidir. Bunun Delphi karşılığı:

function birfonksiyon: PAnsiChar; cdecl;

olacaktır. Burada kullanılan C / C++ pointer’ı aynı ÅŸekilde Delphi’de de pointer olarak geçmiÅŸtir. Fakat bazen C’de pointer’lar hem pointer tanımlamak için, hem dizi tanımlamak için hem de parametrelerde çıkış için kullanılabiliyor. Bunların ayırımını zamanla ve tecrübeyle kazanacaksınız. AÅŸağıda referans olarak kullanabileceÄŸiniz bir tablo gözükmektedir. Bu tabloyu kullandıkça artık aÅŸina olup tekrar dönüp bakmayacağınızı da zannediyorum. Ama ÅŸimdi her birine birer birer göz atmanızda yarar var.

Tabloyu incelerseniz çoÄŸu tipin birbirinin aynısı olduÄŸunu anlarsınız. Bu yüzden tablo biraz uzunca oldu. Bunun nedeni C / C++’da bolca makro denilen yapıların kullanılmasıdır. Makrolar ile ilgili iÅŸlemleri ileride anlatacağımızdan ÅŸimdilik burada kısa kesiyoruz.

Gördüğünüz gibi string yerine PChar yada PAnsiChar kullanılmakta. Tabloda ayrıca Delphi 2009 ve yukarısında kullanılmak üzere verdiğim alternetifler de mevcut.

#define UINT unsigned int

Veri tipleri ile ilgili zamanı geldikçe yine değineceğiz. Ama giriş için bu kadarlık bilgi yeterli.

Makrolar

Diyeceksiniz ki, ne oluyor C dersine mi baÅŸladık? EÄŸer bir dilden diÄŸer dile çevirim yapmak istiyorsanız her iki dilin de incelikleri bilmeniz gerekmektedir. Tabi biz burada bir C kitabı yazacak deÄŸiliz. Bunun yerine mümkün olduÄŸunca kısa tutup püf noktalarını vermeye çalışıyorum. Fakat, yeri gelecek bir C kitabını karıştırmanız gerekebilecek veya C ile ilgili bir siteyi…

Makrolar C / C++ derleyicilerine, derlemeden hemen önce yapılacak olan iÅŸlemleri bildirir. Bir nevi Delphi’deki {$ ..} derleyici direktiflerine benzeselerde bunlar daha karmaşıklardır. Önemli nokta, makroların derlemeden hemen önce çalıştırılmasıdır ve derlemeye dahil olmamasıdır. Bu yüzden C / C++ derleyicileri precompile denilen bir iÅŸleme tabi tutulurlar. Bu da C / C++ derleyicilerinin neden bu kadar yavaÅŸ derlediklerinin bir sebebidir. EÄŸer C / C++ ile büyük bir programı derlememiÅŸ iseniz hala, Delphi gibi 1-2 sn içinde derlediÄŸini zannedersiniz. Halbuki C/C++’da ömrünüz yarısı derlemekle geçer

Aşağıda tanımlı basit bir makro görüyorusunuz:

#define BIRMAKRO MakronunDegeri

Makro burada gördüğünüz gibi #define ile tanımlanıyor. Delphide olduğu gibi #ifdef, #ifndef, #endif gibi ifadelerle bu makronun tanımlı olup olmadığı kontrol edilebilir.

Peki bu makro delphi’ye geçirilecek mi? Belki evet belki hayır. EÄŸer makro bir fonksiyonu tanımlıyorsa bu durumda makroyu delphide tanımlamalısınız. Aksi taktirde makronun deÄŸeri sizin için yeterlidir. Makroyu geçrimenize gerek yok.

EÄŸer önceki konudaki tüyoyu okudu iseniz makroların gerçek deÄŸerlerine nasıl ulaÅŸacağımızı biliyoruz. Mesela aÅŸağıdaki makroyu birebir delphi’ye geçirmeye luzum yoktur:

C:

#define size_t unsigned int
__stdcall size_t getSize();

Delphi:

function getSize: Cardinal; stdcall;

Ama isterseniz size_t makrosunu bir tip olarak tanımlayabilirsiniz de:

size_t = Cardinal;

Ama lüzum yok. Peki hangi makroları delphi’ye çevirmemiz gerekli? Åžimdiye kadarki tecrübeme göre genelde fonksiyon makrolarını geçrimek yeterli. AÅŸağıda örnek bir fonksyion makrosu mevcut ve devamında delphi kodlarını bulabilirsiniz:

#define Fonksiyon(Msg) MessageBox(NULL, Msg, NULL, NULL)

procedure Fonksiyon(Msg: PChar); inline;
begin
  MessageBox(0, Msg, '', 0);
end;

Gördüğünüz gibi sadece “inline;” olarak tanımlamamız aynı etkiyi yapacaktır. Çünkü “inline” direktifi de makro gibi fonksiyonun çaÄŸrıldığı yerde çalıştırılır. Inline ve makro fonksiyonlar için internette bir çok makale bulabilirsiniz.

Bunun dışında makrolar ile iligli olarak ÅŸunu söylemek istiyorum. Önceden de dediÄŸim gibi her makronun bire bir Delphi’ye çevrilmesine gerek yoktur. Makro fonksiyonların haricinde bir de bazen makro sabitler de tanımlanabilir. Mesela:

#define ei_NONE 0
#define ei_WRITE 1
#define ei_READ 2
#define ei_CREATE 3

Bu tanımlamaları ister const ile tek tek eşitleyerek yaparsınız isterseniz enumerator tanımlarsınız. Biz ikisini de görelim:

//const ile
const
  ei_NONE = 0;
  ei_WRITE = 1;
  ei_READ = 2;
  ei_CREATE = 3;
//enumerator ile
type
  Tei = (ei_NONE = 0, ei_WRITE = 1, ei_READ = 2, ei_CREATE = 3);

Tercih size kalmış…

Çok karmaşık makrolar geldiğinde internetten veya bir c kitabından yardım alabilirsiniz. Fakat bu kadarlık bilgi sizi fazlasıyla idare edecektir.

Gelecek Makalede

Daha yapacağımız çok işler olacak. Şimdilik bu verdiğimiz bilgiler ile kendiniz çevirimler deneyebilirsiniz. Fakat, daha görememiz gereken çok önemli konular mevcut. Özellikle fonksiyon parametreleri başlı başına bir konu başlığı.

Bununla beraber bu makale serisinde sadece DLL kullanımını görmeyeceÄŸiz. Gelecek makalelerde DLL kullanmadan C obje dosyalarını direk olarak delphi’ye gömeceÄŸiz. Böylece programınızın yanında ek bir DLL verme zorunluluÄŸunuzda kalkacak. Tabi bu konu baÅŸlı başına bir makale bölümü olacaktır.

Yine gelecek makalelerde hedear dosyaları haricindeki, implementation olarak ifade ettiÄŸimiz kısımları da sıfırdan Delphi’ye nasıl çevrileceÄŸinden bahsedeceÄŸiz. Daha doÄŸrusu yine bazı püf noktalara deÄŸineceÄŸiz. Yoksa tüm gramerin nasıl çevrileceÄŸini anlatmak biraz uzun ve sıkıcı olabilir.

Bu bölümlük bu kadar.

Fikir, eleştiri ve önerilerinizi bekliyorum.

Fatih Tolga Ata – 2009

Hafıza Bölgesinde Stream Kullanımı

Takdir edersiniz ki en hızlı stream verisi hafızada bulunan stream verisidir. Yani bir hafıza stream nesnesi her halukarda okuma-yazma işlemleri dosya ve veritabanından hızlı çalışacaktır. Bu durumda eğer bir stream ile çok fazla okuma-yazma işlemleri gerçekleştiriliyorsa, ilk başta bir hafıza streami kullanılmalı ve stream ile işimiz bitip son durumu kaydetmek istediğimizde bu hafıza streaminden başka bir stream nesnesine aktarım yapılması en doğru işlem olacaktır. Aynı şekilde stream verisi üzerinde çok miktarda Seek işlemi yani stream işaretçisinin pozisyonunu değiştirme işlemi gerçekleştiriyorsanız, bu durumda yine stream verisinin tamamını bir hafıza bölgesine aktarmalısınız.

Aşağıdaki örneğe göz atalım:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  writebuffer, readbuffer: AnsiString;
begin
  Mem := TMemoryStream.Create;
  try
    writebuffer := 'Diyezon';
    Mem.WriteBuffer(writebuffer[1], Length(writebuffer));
    Mem.Position := 0;
    SetLength(readbuffer, Length(writebuffer));
    Mem.ReadBuffer(readbuffer[1], Length(readbuffer));
    ShowMessage(readbuffer);
  finally
    Mem.Free;
  end;
end;

Gördüğünüz gibi TMemoryStream’in Create oluÅŸturucusu hiç bir parametre almıyor. Burada ekstradan yazma iÅŸleminden sonra Position := 0 ile stream iÅŸaretçisini baÅŸa getiriyoruz. Çünkü yazma iÅŸleminin sonunda iÅŸaretçi pozisyonu kayacaktır. Okuma iÅŸlemini yapabilmemiz için yine iÅŸaretçiyi baÅŸa getirip okutuyoruz. Aynı iÅŸlemi Seek metodu ile de yapabiliriz. Ek bir not olarak, Seek metodu Position’dan daha hızlı çalışmaktadır.

Hafıza streami kullanmak, oluşturulması esnasında hiç bir parametre gerektirmediğinden, diğerlerine nazaran daha kolay ve pratiktir. Bu yüzden yapacağımız yüksek yoğunluktaki stream işlemlerini TMemoryStream ile yapmamız bizim yararımıza olacaktır. Özellikle Seek işlemlerinde yani pozisyon değiştirme işlemlerinde hafızadan faydalanmak önemli bir performans artışına sebep olacaktır.

Stream’lerin Aktarımı ve Kopyalanması

Stream verileri ile okuma-yazma iÅŸlemlerinden sonra yapılan en önemli iÅŸlem de bir stream’in baÅŸka bir stream verisi üzerine aktarılmasıdır. Mesela bir dosyayı hafızaya almak isteyebilirsiniz. Veya hafızadaki bir veriyi veritabanına aktarmak isteyebilirsiniz. Bu durumda her stream fonksiyonunda bulunan CopyFrom metodu kullanılır.

Aktarım işleminde basit bir metodu kullanmaktan öte, bir noktaya dikkat edilmesi şarttır. CopyFrom metodu ve bunun gibi bir çok metod, stream işaretçisinin bulunduğu pozisyondan itibaren işlemeye başlarlar. Aşağıdaki örneğe bir göz atalım:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  F: TFileStream;
  //Mem, F: TStream; şeklinden de yazılabilirdi...
  buffer: AnsiString;
begin
  Mem := TMemoryStream.Create;
  F := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    buffer := 'Diyezon';
    Mem.WriteBuffer(buffer[1], Length(buffer));
    //karakter katarımızı hafızaya aldık.

    Mem.Position := 0; //Önemli!!!!

    F.CopyFrom(Mem, Mem.Size);
  finally
    Mem.Free;
    F.Free;
  end;
end;

İlk yaptığımız işlem bir karakter dizisini hafızaya almak oldu. Ardında bu hafıza streamini dosya üzerine kopyaladık. Burada dikkat edilmesi gereken nokta Position := 0 kısmıdır. Hafızaya karakter dizisinin yazılmasından sonra stream işaretçisi sona kayar. Böylece sonrasında gelen CopyFrom gibi metodlar bu pozisyondan itibaren işlem yapmaya başlarlar. İşaretçi sonda olduğu için CopyFrom kopyalayamaz ve bir istisna hatası çıkarır. İşte bunu önlemek için işaretçiyi başa alıyoruz ve hafıza streaminin tamamını dosya üzerine aktarıyoruz.

Kısacası CopyFrom metodu, kopyalanacak olan streamin iÅŸaretçi pozisyonundan itibaren, sizin belirlediÄŸiniz uzunluk kadar stream’den okur ve diÄŸer streame aktarır. Tek dikkat etmemiz gereken nokta kopyalayacağımız kaynak stream’in mevcut iÅŸaretçi poziyonudur. EÄŸer iÅŸaretçi poziyonu sonda ise CopyFrom kaynak stream’den veri okuyamayacak ve hata meydana gelecektir.

Nesneler ve BileÅŸenleri Okuyup Yazmak

Nesneleri, stream üzerine yazmak denildiğinde ilk akla gelen record verileri gibi okuyup yazmaktır. Halbuki nesneler, her ne kadar benzese de, record verilerinden çok farklıdır ve karışıktır. Bu yüzden direk olarak bir sınıf ya da nesne stream üzerine aktarılamaz. Ancak sizin belirlediğiniz kısımları ayrı ayrı, önceden öğrendiğimiz okuma-yazma işlemleri ile halledebilirsiniz.

Fakat bileÅŸenlerde durum biraz farklıdır. Daha doÄŸrusu TPersistent sınıfından türeyen bütün sınıflarda durum biraz farklıdır. TStream sınıfında, bileÅŸenlerin özelliklerini stream üzerine alabilmek için ReadComponent ve WriteComponent metodları mevcuttur. Bu metodlar sayesinde bileÅŸenler stream verileri üzerine aktarılabilirler. Ki, Delphi IDE’si bunu bol bol kullanmaktadır. EÄŸer bileÅŸen yazımı ile ilgili 3 bölümlük makaleyi okumuÅŸ iseniz bileÅŸenlerde bir özelliÄŸe kaydedebilme özelliÄŸi kazandırmıştık. Yani özelliÄŸin kaydedebilme özelliÄŸi yoksa stream üzerine aktarılamazlar. Özelliklerin kaydedilebilme iÅŸlemine burada deÄŸinmeyeceÄŸiz. Ama isterseniz, bileÅŸen yazımı ile ilgili makaledeki kolleksiyon ve binary özellikler kısmına göz atabilirsiniz.

Bileşenlere bu özelliği kazandıran TPersistent sınıfıdır. TPersistent sınıfı ile ilgili daha fazla bilgi alabilmek için yardım dosyalarına göz atabilirsiniz.

Yeni bir form açalım ve bir button ekleyelim. Buttonun OnClick olayına aşağıdaki kodları yerleştirelim:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  F: TFileStream;
begin
  Mem := TMemoryStream.Create;
  F := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Mem.WriteComponent(Button1);

    Mem.Position := 0; //Önemli!!!!

    F.CopyFrom(Mem, Mem.Size);
  finally
    Mem.Free;
    F.Free;
  end;
end;

Bu programı çalıştırıp button’a basarsanız, C: bölümde deneme.txt isimli bir dosya göreceksiniz. Bu dosyayı bir hex editor ile açıp kontrol edebilirsiniz. Ama dosyaya baktığınızda TButton’a ait tüm özelliklerin olmadığını göreceksiniz. Çünkü burada sadece bileÅŸenin deÄŸiÅŸmiÅŸ olan özellikleri kaydedilir. Her özellik bir default deÄŸere sahiptir. Ve bu deÄŸer deÄŸiÅŸmiÅŸ ise, WriteComponent metodu bunu stream üzerine yazacaktır.

Åžimdi bu dosyadaki Button1 bileÅŸenini okutalım ve form üzerinde oluÅŸturalım. Bunun için yeni bir uygulama açalım ve içinde Button1 isimli bir button olmamasına özen gösterelim. Çünkü birazdan bu bileÅŸeni dosyadan biz oluÅŸturacağız.

Form üzerine bir button ekleyelim ve ismine Button2 diyelim ve Caption olarak "bileşeni dosyadan oku" gibi bir şey yazalım. Ardından buttonun OnClick olayına aşağıdaki kodları yerleştirilem:

procedure TForm1.Button2Click(Sender: TObject);
var
  F: TFileStream;
  Button1: TButton;
begin
  F := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    Button1 := TButton.Create(Self);
    Button1.Parent := Self;
    F.ReadComponent(Button1);
  finally
    F.Free;
  end;
end;

Programı çalıştırıp Button2′ye tıklarsanız form üzerinde önceden kaydettiÄŸimiz Button1 bileÅŸenini göreceksiniz.

Önceden de dediÄŸimiz gibi TPersistent olmayan nesneleri direk olarak stream olarak yazmak ve okumak mümkün deÄŸildir. Fakat kendinizin tanımlayacağı formatta, stream’den okuma ve stream’e yazma gibi fonksiyonlar ile nesnelerinize bu özelliÄŸi kazandırabilirsiniz. Zaten TPersistent sınıfının da yaptığı iÅŸlem budur. TPersistent sınıfına fazla girmek istemiyorum, fakat merakı olanlar TPersistent ile beraber TFiler, TReader gibi sınıflara yardımdan göz atabilirler.

Ek olarak bu konuda söyleyebileceğim bir tecrübem de şudur. İster VCL içinde olsun, ister başka bir yerden bulacağınız bir bileşen veya bir sınıf olsun, eğer stream ile çalışıyorlarsa şu 4 metod bunlarda bulunacaktır. LoadFromStream, LoadFromFile, SaveToStream, SaveToFile.

Buna tecrübe dedim çünkü literatürde bu metodlar aynı isim ve parametrelerle bulunacak diye bir ÅŸart yoktur. Fakat VCL’de bulunan bileÅŸenlerde bolca kullanılan bu metodlar, diÄŸer 3. parti bileÅŸen ve sınıflarda da kolaylık ve alışkanlık olması açısından isimlerini ve yapılarını korumuÅŸtur. EÄŸer bir sınıf stream ile iÅŸlem yapıyorsa bilinki bu sınıfta, yukarıda bahsettiÄŸimiz 4 metod bulunacaktır.

Sizler de yazacağınız sınıflarda bu metodları aynı isim ve yapıda kullanırsanız, sınıfınızı ya da bileÅŸeninizi kullanacak olan kiÅŸiler zorlanmayacaktır. Bu metodların tanımlamasını VCL’de herhangi bir sınıf ya da bileÅŸenin tanımlamasından kopyala yapıştır ile alabilirsiniz. Sadece burada deÄŸiÅŸecek olan kısım LoadFromStream ve SaveToStream metodlarıdır. Bu metodların içeriÄŸini kendinize göre yeniden oluÅŸturmalısınız.

Resource Verilerini Okuyup Yazmak

Resoruce verileri, kısaca açıklamak gerekirse, exe ya da dll dosyanız içine gömülen verilerdir. Bu veriler resim, yazı, icon, form olabileceği gibi herhangibir formatta stream verisi de olabilir.

Resource dosyaları ".RC" uzantılı bir dosyadan herhangi bir resource compiler ile derlenir. Bu derleme sonucunda ".RES" uzantılı bir dosya oluÅŸacaktır. RES dosyalarını istediÄŸiniz bir resource derleyicisi ile oluÅŸturabilirsiniz. Çünkü bu res dosyaları derleyiciden bağımsızdır. Fakat RC dosyasının grameri deÄŸiÅŸiklik gösterebilmektedir. Biz bu makalede resource verilerini derlemek için delphi ile beraber gelen brcc32 derleyicisini kullanacağız. Ä°sterseniz Visual Studio veya benzeri bir baÅŸka resource manager ile RES dosyaları oluÅŸturabilirsiniz. EÄŸer Delphi 2009′a sahip iseniz, yeni "Resource Manager" ile daha rahat resource dosyaları oluÅŸturabilirsiniz.

Delphi 2009′da menüden Project/Resources… altından ulaÅŸabilrsiniz.

Biz elimizde Delphi’den baÅŸka bir ÅŸey olmadığını düşünerek iÅŸe koyulalım ve resource dosyamızı oluÅŸturalım.

Notepad ile yeni bir yazı dosyası oluşturalım ve içine bir yerlerden uzun bir paragraf bulup yapıştırılım. Bunu yazi.txt ismi ile kaydelim. Aynı klasöre başka bir yazı dosyası daha oluşturalım ve içine aşağıdakileri yazalım:

yazi RCDATA yazi.txt 

Daha sonra bu dosyayı "yazi.rc" ismi ile aynı klasöre kaydedelim.

Burada ilk yazdığımız kelime resource’a verdiÄŸmiz isimdir. Ä°leride bu isme göre resource verimizi kullanacağız. Ä°kinci kısımda RCDATA ile verimizin tipini belirledik. Burada RCDATA’nın dışında BITMAP, CURSOR ve ICON gibi ayrı ayrı tipler kullanılabilir. Bunların tam listesi için internette araÅŸtırma yapabilirsiniz. (http://msdn.microsoft.com/en-us/library/aa381043(VS.85).aspx). En sondaki kısım ise resource olarak kullanacağımız verimizin dosyasını giriyoruz.

BaÅŸlat/Çalıştır ile cmd yazıp entere basıp komut satırına geçelim. Buradan dosyaları kaydettiÄŸimiz klasöre geçelim(msdos biliyorsunuzdur herhalde ). Ardından aÅŸağıdaki komutu yazıp entere basalım.

brcc32 yazi.rc

Bir problem oluşmadı ise aynı klasörede yazi.res isimli bir dosya göreceğiz.

Bu iÅŸlemlerden sonra Delphi’ye geçip yeni bir uygulama açalım. Yeni uygulamamızı .res dosyalarını oluÅŸturduÄŸumuz klasöre kaydedelim. Åžimdi az önce oluÅŸturduÄŸumuz res dosyasını programımız içine gömmek için gerekli iÅŸlemleri yapalım.

Unit1′in kodlarını açalım ve uygun bir boÅŸluÄŸa aÅŸağıdaki derleyici direktifini girelim:

{$R yazi.res}

Programızı derlediğimizde bu res dosyasında buluna bütün veriler, resource verisi olarak programımıza gömülecektir. İsterseniz bunu ResHack gibi herhangi bir resource yöneticisi ile kontrol edebilirsiniz.

Şimdi bu gömülmüş olan veriyi okumamız gerekiyor diyelim. Mesela az önce programımız içine gömdüğümüz yazi.txt dosyasını bir memo içine alalım ve gösterelim.

Form üzerine bir adet memo bileÅŸeni ve bir adet button ekleyelim. Button’unun OnClick olayına ÅŸunları yazalım:

var
  Res: TResourceStream;
begin
  Res := TResourceStream.Create(hInstance, 'yazi', RT_RCDATA);
  Memo1.Lines.LoadFromStream(Res);
end;

Programı çalıştırıp button’a basalım. Bir sorun çıkmadı ise memo bileÅŸeninde yazi.txt dosyasındaki yazılı olan paragrafı göreceÄŸiz.

Bu yaptığımız örnek ile görüyoruz ki; bir TResourceStream nesnesi, herhangi bir exe veya dll içindeki resource verilerine erişebiliyor. Create oluşturucusunda gördüğümüz ilk parametre resource verisini nereden çekeceğimizi belirliyor. Buna daha sonra değineceğiz. İkinci parametre olarak erişeceğimiz resource verisinin ismidir. Bunu RC dosyasını hazırlarken görmüştük. Aynı şekilde son parametre de RC dosyasında belirlenmişti. Bu son parametre ile resource verisinin tipini belirliyoruz. Tek fark olarak baş tarafına RT_ ön ekini getiriyoruz.

Sonraki işlem ise memo bileşenin Lines özelliğine streamdeki veriyi aktarıyoruz.

Bu mantığı kullanarak istediÄŸiniz türde veriyi resource olarak gömebilir ve program çalışması anında kullanabilirsiniz. Bu yaptığımız örnek sadece mevcut programdan verileri çekebilir. Fakat baÅŸka bir dll ya da exe’den veri çekmemiz gerektiÄŸinde ne yapacağız?

Ä°ÅŸte bu durumda hInstance olarak girdiÄŸimiz parametre deÄŸiÅŸecektir. Çünkü burada girdiÄŸimiz parametre veriyi nereden çekeceÄŸimizi daha doÄŸrusu resource verisinini nerede olduÄŸunu belirler.

Her program(exe, dll, ocx, ..) çalıştırıldığında windows tarafından bir handle numarası ile iliÅŸkilendirilir. Delphi’de bu handle numarasına eriÅŸebilmek için hInstance isimli global bir deÄŸiÅŸkeni kullanıyoruz. Bu yüzden Create oluÅŸturucusunda mevcut çalışan programımızın handle numarasını buraya birinci parametre olarak girdik.

Peki baÅŸka bir exe veya bir dll’in handle numarasını nasıl alırız?

Bunun için cevabımız LoadLibrary fonksiyonudur. Bu fonksiyon ile çağırdığımız herhangi bir program geçici olarak hafızaya yüklenir ve windows tarafından bir handle atanır. Bu handle numarası ise çıkış olarak döner. Eğer yükleme işlemi başarısız ise handle numarası 0 olarak dönecektir. Mesela yukarıda yaptığımız işlemleri bir dll içinden almaya kalkarsak nasıl yapacaktık?

var
  Res: TResourceStream;
  DLLHandle: THandle;
begin
  DLLHandle := LoadLibrary('resource.dll');
  if DLLHandle <> 0 then
  begin
    Res := TResourceStream.Create(DLLHandle, 'yazi', RT_RCDATA);
    Memo1.Lines.LoadFromStream(Res);
  end;
end;

Aynı işlemi exe, ocx gibi diğer çalıştırılabilir formatlar içinde yapabilirsiniz.

Artık herhangi bir veriyi exe içine gömüp okumayı öğrendik. Şimdi de bu işlemin bir benzerini veritabanlarında yapalım.

Veritabanında Stream Kullanımı

Artık buraya kadar öğrendiklerimizle herhangi bir stream verisini okuyup yazabiliriz. Burada yapacağımız işlem de pek farklı olmayacak. Bu yüzden hemen konuya girelim ve kısaca veritabanlarında nasıl stream kullanıldığını görelim.

Veritabanlarında bulunan tablolarda stream verilerini saklamak için alanımız BLOB tipinde olmalıdır. BLOB tipindeki alanlar binary veriler tutabilir. Fakat indeksli ve üzerinde çok arama tarama işlemleri yapılan bir tablomuz var ise bu BLOB alanlar veritabanı işlemlerini yavaşlatacaktır. Bu yüzden bu BLOB alanları başka bir tablo üzerine taşımak performansı artıracaktır.

Tabloda bulunan bir BLOB alana veri yazmak ve bu alandan veri okumak için TBlobStream nesneleri kullanılır. Kullanımı aşağıdaki gibidir:

var
  blob: TBlobStream;
begin
  blob := tblBirTablo.CreateBlobStream(tblBirTablo.FieldByName('BlobAlan'), bmReadWrite);
  try
    blob.Position := 0;
    blob.ReadBuffer(...);
    blob.WriteBuffer(...);
    ......
  finally
    blob.Free;
  end;
end;

Genel manada kullanım bu şekildedir fakat daha başka yöntemler ile de blob stream oluşturulabilir. Bu örnekte BlobAlan isimli bir alan hem okuma hem de yazma işlemleri için stream olarak bizim blob stream nesnemize atanmıştır. Burada sadece okuma işlemleri yapacaksak bmRead, sadece yazma işlemi yapacaksak bmWrite parametrelerini kullanmalıyız.

TStream’i .NET ve Delphi 2009′da Kullanmak

TStream sınıfı Delphi’nin bileÅŸen mantığının temelini oluÅŸturmaktadır. Delphi, .NET ortamına taşınırıken haliyle TStream sınıfı da ufak farklılıklar ile .NET ortamına taşınmıştır. Benim burada bahsedeceÄŸim konu sadece bu küçük farklılıklar olacaktır. Geri kalan iÅŸlemlerde buraya kadar öğrendiÄŸiniz bilgiler fazlasıyla yetecektir.

.NET ortamında Pointer işlemleri kullanılmadığından TStream sınıfı ve alt sınıfları için bir değişikliğe gidilmesi şarttı. Bu yüzden, TStream sınıfı .NET ortamına taşındığında Pointer işlemleri yerine, bu işlemlerin yerini tutan belirgin ve basit tipler için ayrı ayrı metodlar hazırlandı.

Mesela hatırlarsanız normalde TStream sınıfında bulunan ReadBuffer ile bir srting veri yazdığımızda string’i pointer olarak type cast yapıp parametre olarak giriyorduk. .NET’de pointer kullanmadığımız için ReadBuffer yerine artık aynı isimli ve sadece özel tipler için özdeÅŸleÅŸtirilmiÅŸ bir metodumuz var. Bu metodu kullanarak rahat bir ÅŸekilde pointer kullanmadan iÅŸlemlerimizi aynı ÅŸekilde yapabiliriz. Tabi bu daha önce yaptığımız Win32 TStream sınıfına göre çok rahatlık getirmektedir. Bu da hiç şüphesiz .Net’in getiridiÄŸi rahatlıklardan birisi.

ReadBuffer ver WriteBuffer metodlarından bir kaçındaki değişlikliklere göz atalım:

    //TBytes
    procedure ReadBuffer(Buffer: TBytes; Count: Longint); overload;
    procedure WriteBuffer(const Buffer: TBytes; Count: Longint); overload;

    //Boolean
    procedure ReadBuffer(var Buffer: Boolean); overload;
    procedure WriteBuffer(const Buffer: Boolean); overload;

    //Integer
    procedure ReadBuffer(var Buffer: Integer); overload;
    procedure WriteBuffer(const Buffer: Integer); overload;
    procedure WriteBuffer(const Buffer: Integer; Count: Longint); overload; platform;

    //Char
    procedure ReadBuffer(var Buffer: Char); overload;
    procedure ReadBuffer(var Buffer: Char; Count: Longint); overload; platform;
    procedure WriteBuffer(const Buffer: Char); overload;
    procedure WriteBuffer(const Buffer: Char; Count: Longint); overload; platform;

    // AnsiChar
    procedure ReadBuffer(var Buffer: AnsiChar); overload;
    procedure ReadBuffer(var Buffer: AnsiChar; Count: Longint); overload; platform;
    procedure WriteBuffer(const Buffer: AnsiChar); overload;
    procedure WriteBuffer(const Buffer: AnsiChar; Count: Longint); overload; platform;

Tam liste için lütfen Borland.Vcl.Classes unitinde bulunan TStream sınıfına ya da yardıma göz atınız.

Gördüğünüz gibi aynı ReadBuffer metodu, overload yöntemi ile bir çok kez tanımlanmış. Biz bunlardan ihtiyacımız olanı seçip kullanacağız. Boolean ve Integer yazımı için tek bir adet parametre gerektirdiğine dikkat ediniz.

Diyelimki stream üzerine yazdıracağımız veya okuyacağımız veri çeÅŸidine uygun bir metod bulunmamakta. Bu durumda verimizi bir byte dizisi gibi düşünüp ona göre davranacağız. Bu durumda verimizi TBytes’a yani "array of Byte" tipinieçevirmemiz gerekmektedir. Bunun için herhangi bir for döngüsü tanımlayarak bu iÅŸlememizi yapabiliriz.

Integter ile ilgili metodlara bakarsanız, en sonda fazladan Count parametresi alan bir metod yerleştirdim. Bütün metod çeşitlerinde alternatif olarak bu ikininci parametreye sahip olan metodlar mevcuttur. Bu parametreyi mesela Integer için normalde 4 byte ayrılmasına rağmen siz 10 byte yer ayırmak istediğinizde kullanablirsiniz.

Bu metodlara baktığınızda string ile ilgili bir özel metodun olmadığını farkedeceksiniz. Peki string veriyi nasıl yazacağız?

Bu durumda veriyi hangi encode’da yazacağımız veya okuyacağımız önemli. Veriyi istersek UTF8 formatında istersek UTF16 veya ANSI olarak okuyabilir ve yazabiliriz. Bu durumda string verimizi byte dizisine çeviren veya byte dizisini string verisine çeviren bir yönteme ihtiyacımız var. AÅŸağıdaki örneÄŸe göz atalım:

var
  Mem: TMemoryStream;
  s: string;
  bytes: TBytes;
begin
  Mem := TMemoryStream.Create;
  try
    s := 'diyezon';
    bytes := Encoding.UTF8.GetBytes(s); //uses'a System.Text eklenmeli
    Mem.WriteBuffer(bytes, Length(bytes));
    Mem.Position := 0;
    Memo1.Lines.LoadFromStream(Mem);
  finally
    Mem.Free; //Yapmanıza gerek yok.
  end;
end;

Gördüğünüz gibi string verimizi utf-8 olarak stream üzerine attık ardından memo1 ile ekranda gösterdik. Bu iÅŸlemi yapabilmek için string verisini uygun bir byte dizisine çevirmemiz gerkiyordu. Bunun için System.Text alanında bulunan Encoding sınıfını kullanıyoruz. Bu sınıfı kullanabilmek için uses’a System.Text’i eklemelisiniz.

İsterseniz bu yazma işlemini Encoding.Unicode ile utf-16 ya da diğer adıyla unicode olarak, isterseniz Encoding.Default ile işletim sisteminin varsayılan ansi karakterleri olarak yazıp okuyabiliriz. Önemli olan string bir şekilde byte dizisine çevrilmiş olması gerekmektedir. Ayrıca yazma ve okuma işlemlerinde aynı tip encode formatını kullandığınızdan emin olun. Yani ya her ikisinde de Unicode ya da her ikisinde de UTF8 kullanın.

EÄŸer TBytes’dan stringe çevirim yapmamız gerekirse bu durumda aÅŸağıdaki metodu kullanıyoruz:

s := Encoding.UTF8.GetString(bytes)

Gördüğünüz gibi .net ile bu iÅŸlemleri yapmak çok basit. Ayrıca en sonda stream’i free yapmasanız da Garbage Collector sizin için bunu yapacaktır. Fakat TFileStream kullanıyor ve dosyaya fmShareExclusive gibi kilitleyici bir parametre ile ulaşıyorsanız, stream nesnesini öldürmeden veya program kapanmadan, baÅŸka bir program dosyaya ulaÅŸamaz, dosya kilitli kalır.

Bu bölümde bahsetmek istediğim başka bir konu da bu işlemleri Delphi 2009 ve üstünde yapmak. Burada bahsediyorum, çünkü bahsedeceğimiz bu konu .net ile de ilgili bir konu.

Aslında daha önceden gördük ki; bir stringi stream’e yazmak için stream’in kaç karakter olduÄŸundan çok ,boyutunu bilmemiz gerekiyor. Bu yüzden ansi ya da ascii stringlerde boyut olarak her zaman Length(string) ÅŸeklinde aldık. Çünkü ansi stringlerde boyut = karakter sayısıdır. Fakat unicode olan stringlerde bu durum biraz farklıdır. Unicode olan stringler 1 byte deÄŸil, 2 byte yer kaplarlar. Bu yüzden WideString gibi unicode stringler ile uÄŸraÅŸtığımızda artık boyutumuz Length*2 olmaktadır. BildiÄŸiniz gibi Delphi.Net ve Delphi 2009 ve yukarısı derleyicilerde "string" ve "Char" tipi unicode formatındadır. Bu derleyicilerde ansi olarak veri tanımlamamız gerektiÄŸinde AnsiString, AnsiChar, PAnsiChar gibi tipleri kullanmalıyız. Aksi durumda bu derleyicilerde bir Char tipi 2 byte yer kaplar. Bu konu ile ilgili daha önceden örnek verdiÄŸimizden bu konuyu burada bitiriyorum.

.NET Stream Nesnesinin Kullanımı

TStream’e ek olarak, .net’de aynı mekanizma bulunmaktadır. Neden bilmiyorum ama .net’de bulununa bir çok teknoloji Delphi ile benzerlik göstermektedir. Belki de c# ve .net’in fikir babası olan Anders Hejlsberg’in delphi’nin ilk temellerini atmasından kaynaklanıyor olabilir. Her neyse biz konumuza dönelim.

Aslında bu konu çok uzun anlatılabilecek bir konu ve burada bahsetmemiz makaleyi bir üçüncü bölüme bile taşıyabilir. Ki bence buna gerek yok. Ben sadece TStream ile arasındaki benzerlikleri gösterip, nasıl kullanıldığına dair bir örnek vermek istiyorum.

Bu bölümü VCL.Net kullanmak istemeyip saf .net kodu oluÅŸturmak isteyenler veya Delphi Prism kullananlar için yazmak istedim. Aksi takdirde TStream sınıfı çoÄŸu kez iÅŸimizi rahat bir ÅŸekilde görmektedir. Fakat bazen kullandığımız .net sınıfları .net’in stream sınıflarına ihtiyaç duyabilmektedir.

VCL’de bulunan bazı stream sınıfları yerine .net’de bulunan karşılıklarını şöyle sıralayabilriiz:

TFileStream => FileStream
TMemoryStream => MemoryStream
TIdTCPClient => NetwrokStream

vs..

Tabi bu stream sınıflarının metodları benzerlik gösterse de kullanımları farklıdır. Bu stream sınıflarını kullanabilemek için uses’a System.IO alanını eklemelisiniz. Biz buradan MemoryStream ile ilgili bir örnek verelim:

var
  Mem: MemoryStream;
  s: string;
  bytes: array of Byte;
begin
  Mem := MemoryStream.Create;
  s := 'diyezon';
  bytes := Encoding.UTF8.GetBytes(s);
  Mem.Write(bytes, 0, Length(bytes));

Gördüğünüz gibi kullanım olarak TStream’den farklı deÄŸil. Fakat Write metodunu TStream’de olduÄŸu gibi bir çok çeÅŸidi olduÄŸunu zannetmeyin sakın. Çünkü MemoryStream sınıfında Write metodunun sadece iki adet varyasyonu mevcut. Bu metodda ilk parametre byte dizisi, ikinci parametre nereden itibaren yazılacağı yani ofset ve üçüncü parametre olarak yazdırılacak verinin uzunluÄŸu giriliyor.

Bunun dışında bu string ve binary değerleri rahat bir şekilde okuyup yazabilmek için çeşitli ek sınıflar kullanılmaktadır. Mesela BinaryWriter ile binary değerleri stream üzerine yazabiliriz veya StreamReader ile streamden karakter verilerini okuyabiliriz. Aşağıdaki örneğe göz atalım:

var
  Mem: MemoryStream;
  textW: StreamWriter;
  s: string;
  bytes: array of Byte;
begin
  Mem := MemoryStream.Create;
  textW := StreamWriter.Create(Mem);
  s := 'diyezon';
  textW.Write(s);

Yukarıda yaptığımız iÅŸlemin aynısını burada StreamWriter sınıfı ile gerçekleÅŸtirdik. Ä°ÅŸte burada StreamWriter sınıfının Write metodunda bir çok varyasyon mevcuttur. Bu varyasyonlara yardım dosyalarından ulaÅŸabilirsiniz. Mesela bir Integer deÄŸer yazmak için yine StreamWriter’a ait Write metodunu kullanmamız kafidir.

Bunun dışında bir de kullanabileceğimiz BinaryWriter ve BinaryRead sınıfları mevcuttur. Bu sınıflar ise binary verileri okuyup yazmak için kullanılırlar. Ama kullanım aynı olduğu için bu konuya da girmeyeceğim.

Burada en son olarak BufferedStream sınıfından bahsetmek istiyorum. Bu stream ile okuma ve yazma iÅŸlemlerini baÅŸka bir stream üzerinde buffer’layarak daha hızlı iÅŸlemler yaptırabilirsiniz. Hatırlarsanız TMemoryStream sınıfından bahsederken, bu sınıfı diÄŸer stream sınıflardaki okuma yazma iÅŸlemleri yerine kullanılabileceÄŸinden ve bunun performansı artırdığından bahsetmiÅŸtik. Ä°ÅŸte burada TMemoryStream bir buffer vazifesi görmektedir.

Mesela bir dosyaya bir çok veri yazılacak, ve bu veriler parça parça yazılacak. Ayrıca bu dosya stream’i üzerinde bir çok seek iÅŸlemi yani ileri geri alma iÅŸlemleri yapılacak. Ä°ÅŸte bu durumda direk olarak TFileStream gibi bir dosya stream nesnesi ile uÄŸraÅŸmak yerine hafıza stream’leri ile uÄŸraÅŸmamız iÅŸlemlerimizin performansını önemli derecede artıracaktır. Yapacağımız stream iÅŸlemlerini bir hafıza stream’i üzerinde gerçekleÅŸtirip, en son iÅŸlemimiz bittiÄŸinde hafıza stream’ini ilgili stream nesnesine aktarmak en akıllıca yöntemdir. Ä°ÅŸte bu yönteme buffering ya da tamponlama tekniÄŸi denir.

İşte bu anlattığımız tekniği BufferedStream nesnesi gerçekleştirmektedir. Aynı işlemi ekstra bir memory stream tanımlayarak siz de oluşturabilirisiniz, hatta bu makalede buna benzer örnekleri çok gördük.

BufferedStream sınıfını kullanmak isteyenler, yardım dosyalarında ve msdn’de tanımlamasına bakabilirler. Artık stream mantığını kafanızda yerleÅŸtirdiÄŸinize göre burada kullanımını vermek artık sıkacaktır.

Sonuç

Bir makalenin daha sonuna geldik. Bu makale serisinde VCL ve .net’de kullanılan stream sınıflarına deÄŸinmeye çalıştık ve bu sınıfların kullanımına dair çeÅŸitli örnekler vermeye çalıştık.

Tabi ki burada verdiklerimiz stream için en temel konulardır. Bu makaleyi okuduktan sonra artık kafanızda stream’e ait somut düşüncelerin oluÅŸtuÄŸunu zannediyorum. Ve bundan sonra önünüze gelecek olan bir çok stream iÅŸlemini rahat bir ÅŸekilde halledebileceÄŸinizi umut ediyorum.

Fikir, eleştiri ve yorumlarınızı bekliyorum. Ayrıca makaledeki hataları bildirirseniz sevinirim.

Hayırlı çalışmalar.

Fatih Tolga ATA, Åžubat 2009

Stream’ler hakkında bir makale yazmak, yapacaklarım arasındaydı. En son gelen bir istek üzerine stream konusuna el atalım istedim. Bu makale serimizde hem VCL’de bulunan TStream, hem de .NET’de bulunan Stream sınıfları ve kullanımlarından bahsetmeye çalışacağım.

Özellikle TStream üzerinde stringlerle uğraşmak gibi bir çok konu programcıların kafasını karıştırabilmektedir. Bu ve bunun gibi sorunların çözümlerine de çareler bulmaya çalışacağız.

Stream Nedir?

Bilgisayar ortamında yazma-okuma iÅŸlemlerinden bahsettiÄŸimizde aklımıza bir çok ÅŸey gelir. Mesela disk üzerinde bir dosyaya eriÅŸip üzerinde yazma ve okuma iÅŸlemleri yapabiliriz. Veya bir hafıza bölgesinde yazma-okuma iÅŸlemleri yapabileceÄŸimiz gibi bir veritabanındaki bir tablo alanında veya daha baÅŸka çeÅŸit çeÅŸit ortamlar üzerinde yazma-okuma iÅŸlemleri yapabiliriz. Bu bütün yazma-okuma iÅŸlemleri aslında her zaman yöntemi, iÅŸleyiÅŸi aynı olan bir fonksiyonlar dizisidir. Sadece alt planda yazma-okuma iÅŸleminin yapılacağı yüzeyde(disk, hafıza…) farklılıklar oluÅŸmaktadır.

İşte bu işlemleri kolay bir şekilde, ortak bir sınıf üzerinden yapmak istediğimiz zaman ortaya Stream gibi bir yapı çıkıyor. Stream nesnelerini kullanarak, bir dosyayı yazıp okuyabilir, aynı fonksiyonları kullanarak bir hafıza bölgesine ulaşılabilir veya yine aynı fonksiyonlar ile bir veritabanı tablosunun alanına ulaşılabilir.

Stream, burada anlatılan basit özelliklerin yanında, stream verileri üzerinde bir çok işlemi yapabilmemize imkan sağlamaktadır. Bu makalemizde bunları ayrıntısı ile görmeye çalışacağız.

Stream Verileri

Stream nesneleri, stream verilerini kullanmamızı sağlamaktadır. Stream verileri, üzerinde çalışılan yere göre çeşitli veriler içermektedir. Bu bir resim dosyası olabileceği gibi kendimize özel çok farklı bir format da olabilir.

Buradan da anlaşılacağı gibi, stream verileri bir nevi bir byte dizisidir. Yani aynı veriyi "array of byte" ÅŸeklinde kullanarak da oluÅŸturabilir ve üzerinde iÅŸlem yapabiliriz. Fakat bu, bize ek masraftan baÅŸka bir ÅŸeye yaramayacaktır. Üstelik yazacağımız fonksiyon ya da sınıf stream nesneleri gib esnek ve hızlı olmayacaktır.

Stream Ne Zaman Kullanılmalı?

Yapacağımız işlemerde stream mi, array mi kullanılmalı noktasında karar vermek istediğimizde bir kaç hususu göz önünde bulundurmamız gerekecektir.

Ä°lk olarak bilmemiz gereken stream verileri array’de olduÄŸu gibi indeksli deÄŸildir. EÄŸer kullanacağımız veriler, sabit veri tipi ise ve bir for döngüsüne girmek üzere oluÅŸturulacak ise kullanacağımız nesne array olacaktır. Stream’de de istediÄŸiniz veriye array’de olduÄŸu gibi ulaÅŸabilirsiniz. Fakat bu ileride de göreceÄŸimiz gibi array indekslerinden farklı olarak çalışmaktadır.

Eğer bu veri dizimiz bir disk veya bir hafıza bölgesi üzerine yazılacaksa ve burada işlem yapılacaksa, bu durumda array yerine stream kullanılması bize bir çok kolaylık sunacaktır.

Aynı ÅŸekilde veri dizimiz sabit veri tipleri içermiyorsa yani sadece array of string veya sadece array of Integer deÄŸilse bu durumda yine stream kullanmalıyız. Mesela veri dizimizin birinci elemanı 4 karakterlik bir string, ikinci elmanı bir Integer, üçüncü elemanı bir Boolean, vs… gibi. Bu ÅŸekilde kendi dosya formatımızı oluÅŸturabileceÄŸimiz gibi, doc, exe, zip gibi bir çok binary dosyasının yapısını bildiÄŸimizde bu dosyaların verilerine de ulaÅŸabiliriz.

VCL’ de Stream Kullanımı

İlk başta VCL ile stream kullanımına değinelim. Ardında .Net üzerinde stream kullanımını göreceğiz.

VCL ile stream işlemleri yapabilmek için TStream sınıfından türeyen bir çok sınıf mevcuttur. TStream sınıfı abstract olarak tanımlanmış bir sınıftır ve direk olarak kullanılamaz. Abstract olarak oluşturulmuş olan bir sınıftan nesne oluşturulamaz. Ancak bu abstract sınıftan türemiş olan abstract olmayan sınıflardan nesne oluşturulabilir. Bu şekilde bir yapı olması, tüm stream sınıflarının aynı olan bir çok metod ve özelliğe sahip olmasını sağlar. Abstract sınıfların avantajları burada anlatılacak kadar kısa değil. Bu yüzden şimdilik bu kadar bilmemiz yeterli.

Help dosyasına göz attığımızda TStream sınıfından türemiş bir çok stream sınıfını görüyoruz.

TFileStream: Disk yani dosya sistemi üzerinde bulunan dosyalarla işlem yapmamızı sağlar.

TMemoryStream: Dosyalar üzerinde yapılan aynı işlemleri bir hafıza bölgesi üzerinde yapmamızı sağlar.

TBlobStream: Veritabanında bulunan bir tablodaki BLOB yani binary veri olarak tanımlanmış alanlar üzerinde okuma-yazma işlemleri yapmamızı sağlar.

TResourceStream: Resource dediğimiz, exe, dll gibi çalıştırılabilir dosyalar içine gömülü olan resim, yazı, dialog kutuları, versiyon bilgisi gibi çok çeşitli verileri okuyup yazmamıza imkan sağlamaktadır.

TStringStream: Aynı işlemleri bir string verisi üzerinde işlem yapabilmemizi sağlar. Böylece, sınırsız uzunlukta bir string üzerinde stream ile yapılabilecek her türlü işlemler yapılabilir.

Bunlar, temelde kullanılan stream çeşitleridir. Bunun gibi özel olarak tasarlanmış bir çok stream sınıfı da olabilir. Fakat hepsi TStream sınıfından türediği için, kullanımları da aynı olacaktır.

Dosyalar Üzerinde Stream Ä°ÅŸlemleri

Dosyalar ile uğraşırken TFileStream kullanıldığını söylemiştik. TStream sınıflarının nasıl kullanıldığını, sonucu kolay görme açısından ilk başta dosyalar üzerinde görelim. İleride diğer stream çeşitlerine de değineceğiz.

var
  AFile: TFileStream;
  Buffer: String;
begin
  AFile := TFileStream.Create('C:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Buffer := 'Deneme';
    AFile.WriteBuffer(Pointer(Buffer)^, Length(Buffer));
  finally
    AFile.Free;
  end;

Bu kodları bir button’nun OnClick olayına yerleÅŸtirip deneyelim. Kodlar çalıştırıldığında, C: üzerinde eÄŸer bir eriÅŸim ihlali yoksa deneme.txt isminde bir dosya göreceÄŸiz.

İlk bakışta bu kodlar ürkütücü gelebilir. Fakat konular ilerledikçe stream kullanmanın ne kadar rahat olduğunu göreceğiz.

AFile‘ın oluÅŸturulduÄŸu satıra bakalım. Bir TFileStream nesnesi oluÅŸturabilmeniz için iki adet parametreye ihtiyacınız var. Birincisi dosyanın yolu, ki bizim örneÄŸimizde "deneme.txt" olarak verilmiÅŸ. Ä°kinci parametremiz ise bu dosya üzerinde yapacağımız iÅŸlem kipini ve paylaşım kipini belirler. Ä°ÅŸlem ve paylaşım kipleri "or" kelimesi ile birleÅŸtirilerek kullanılır. Åžimdi bu kiplerin ne olduÄŸuna bakalım:

Ä°ÅŸlem Kipleri:

fmCreate: Verilen dosya yolunda eğer dosya yoksa oluşturur. Eğer dosya var ise üzerine yazar.

fmOpenRead: Dosyayı sadece okuma amaçlı açar.

fmOpenWrite: Dosyayı sadece yazma amaçlı açar.

fmOpenReadWrite: Dosyayı hem okuma hem de yazma için açar.

Paylaşım Kipleri:

fmShareExclusive: Diğer uygulamaların, bizim üzerinde çalıştığımız dosya üzerinde hem okuma hem de yazma işlemlerini yasaklar.

fmShareDenyWrite: Diğer uygulamalar dosyayı okuyabilir fakat üzerinde yazma işlemi yapamazlar.

fmShareDenyRead: Diğer uygulamaların, dosya üzerinde okuma işlemi yapmasını yasaklar.

fmShareDenyNone: Ne okuma ne de yazma yasağı koyar. Yani diğer uygulamalar, dosya üzerinde yazma ve okuma yapabilirler.

fmShareCompat: Eskiden dos zamanlarında kullanılan FCB(File Control Block) ile uyumluluğu sağlamak için kullanılır. Windows üzerinde fmShareExclusive, Linux üzerinde ise fmShareDenyNone ile aynıdır. Bu yüzden bunu es geçebilirsiniz.

Yukarıda verdiğimiz örnekte olduğu gibi işlem kipleri ve paylaşım kipleri "or" kelimesi ile birleştirilerek kullanılır. Örneğimizde dosya fmCreate ile eğer yoksa oluşturulacak ve eğer varsa üzerine yazılacaktır. Ve dosya fmShareDenyNone kipinde olduğu için üzerinde herhangi bir okuma yazma yasağı bulumamaktadır.

Ardından try..finally buloÄŸunda, stream üzerine yazma iÅŸlemleri yapılmaktadır. Åžimdilik bu kısmı anlatmayacağız. Çünkü okuma ve yazma iÅŸlemleri için ayrı bir konu baÅŸlığımız bulunmaktadır.

finally bloÄŸunda gördüğümüz Free metodu dosyalar üzerinde fazladan bir önem arz etmektedir. Çünkü bir kez TFileStream ile bir dosyaya eriÅŸildiÄŸinde, bu stream nesnesi Free oluncaya yani yok edilinceye kadar, dosyanın handle’ı iÅŸletim sistemi tarafından tutulur. Dosya handle’ı aktif olduÄŸu sürece dosyanın silinmesi taşınması iÅŸletim sistemi tarafından engellenir. Ve genelde herkesin karşılaÅŸtığı "Bu dosya bir uygulama tarafından kullanıyor." gibi bir mesaj alırız. Bunun için unlocker, process explorer gibi harici programlar ile aktif kalan bu handle’lar kapatılarak dosyalar silinebilir. Bu yüzden okuma yazma iÅŸlemlerimiz biter bitmez stream nesnemizi Free yapmalıyız.

Kısaca bir stream nesnesini oluşturmak için aşağıdaki şablonu kullanmalıyız:

var
  AStream: TBirStreamSınıfı;
begin
  AStream := TBirStreamSınıfı.Create({Stream sınıfına ait parametreler...});
  try
    //Stream üzerinde okuma yazma işlemleri
  finally
    AStream.Free;
  end;
end;

Stream Üzerinde Okuma-Yazma Ä°ÅŸlemleri

Stream’ler üzerinde yazma iÅŸlemleri için baÅŸlıca Write ve WriteBuffer metodları ve okuma iÅŸlemleri için de Read ve ReadBuffer metodları tanımlanmıştır. Åžimdi göreceÄŸimiz iÅŸlemler Win32‘ye göre anlatılacaktır. Ä°leride ayrı bir baÅŸlık halinde TStream sınıfının .NET üzerinde nasıl yazma okuma yapabileceÄŸiniz de göreceÄŸiz. Ayrıca .NET içinde bulunan Stream sınıflarına deÄŸineceÄŸiz.

Stream üzerinde yapılan okuma yazma işlemleri bir işaretçi vasıtası ile yapılır. Bu işaretçi hangi pozisyonda ise o pozisyonda okuma ve yazma işlemi yapılır. İlk stream nesnesi oluşturulduğunda işaretçinin pozisyonu sıfırdır. Bu metodlar çağrıldığı vakit, yani her okuma ve yazma işleminin sonunda stream işaretçisi bir sonraki pozisyona kayar. Stream işaretçisi, stream verisinin sonuna gelip gelmediğini test etmek için Eof metodu kullanılır.Bu paragraf streamlerin çalışma mantığının anlaşılması için önemlidir. Bu yüzden dönüp ikinci bir defa okumanızda fayda var.

Sonunda Buffer yazan metodların yazmayanlardan farkından söz etmek istiyorum. Tek fark, "istisna" (Exception) yakalama özelliğidir. Yani mesela ReadBuffer metodu yine alt planda Read metodunu çalıştırır. Fakat Read metodu bir sorunla karşılaşır ve okuyamaz ise, ReadBuffer metodu, EReadError istisnasını yollar. Aynı şekilde WriteBuffer da sorun yaşadığında EWriteError istisnasını yollar. Böylece okuma ve yazma işlemlerinde herhangi bir hata olup olmadığının tespiti için ReadBuffer ve WriteBuffer ile beraber istisnaların yaklanması kafidir.

Okuma ve yazma metodları, işlemlerini bir buffer aracılığı ile gerçekleştirir. Bu buffer bir string olabilceği gibi bir Integer, bir record dahi olabilir. Bu yüzden her veri tipi için okuma ve yazma işlemlerinin nasıl olduğunu ayrı ayrı incelemeye çalışalım.

Sayısal Değelerin Okunması ve Yazılması

Integer, Byte, Double gibi sayısal verileri okuyup yazmak diğerlerine nazaran en basit işlemdir. Ekstra bir çevirim yapmamıza gerek kalmamaktadır.

Bunu bir örnek üzerinde görelim. İki adet button yerleştirelim. Birinin Caption özelliği "Yaz", diğerinin Caption özelliği de "Oku" olsun. "Yaz" butonuna çift tıklayalım ve şunları yazalım:

procedure TForm1.btnYazClick(Sender: TObject);
var
  BirStream: TFileStream;
  BirInteger: Integer;
  BirDouble: Double;
  BirReal: Real;
  BirByte: Byte;
begin
  BirStream := TFileStream.Create('c:\deneme.bin', fmCreate or fmShareDenyNone);
  try
    BirInteger := 15000;
    BirDouble := 1.3;
    BirReal := 123.123123123;
    BirByte := 65;
    BirStream.WriteBuffer(BirInteger, SizeOf(Integer));
    BirStream.WriteBuffer(BirDouble, SizeOf(Double));
    BirStream.WriteBuffer(BirReal, SizeOf(Real));
    BirStream.WriteBuffer(BirByte, SizeOf(Byte));
  finally
    BirStream.Free;
  end;
end;

Gördüğünüz gibi bir TFileStream nesnesi oluÅŸturduk ve bu stream nesnesini kullanarak dosyaya bir takım sayısal deÄŸerler yazdırdık. Mesela ilk yazdırma örneÄŸimizde buffer, Integer tipinde bir deÄŸiÅŸkendir. Bu Integer deÄŸeri yazdırırken ne kadar yazdırılması gerektiÄŸini WriteBuffer metodunun ikinci parametresi olarak giriyoruz. Yani yazdıracağımız bu buffer kaç byte yer tutacak, onu ikinci parametre olarak giriyoruz. ÖrneÄŸimizde, bu parametre olarak Integer‘ın boyutunu giriyoruz. Bunun için SizeOf fonksiyonundan faydalanıyoruz. Help dosyasına baktığımızda, Integer‘ın 4 byte yer kapladığını görürüz. Burada yaptığımız iÅŸlem dosyada 4 byte’lık bir alana Integer deÄŸeri yazdırmaktan ibarettir.

Ardından gelen yazma iÅŸlemleri de aynı mantık ile yapılmaktadır. Burada dikkat etmemiz gereken nokta ikinci parametredir. Çünkü bu parametre yanlış girilirse hem yazmada hem de okumada eksik ve yanlış verilerle karşılaşırız. Bu örnekten de anladığımız gibi sayısal veriler ile uÄŸraşırken SizeOf(DeÄŸiÅŸkeTipi) ÅŸeklinde ikinci parametreyi belirlememiz yeterlidir.

Åžimdi bu programı çalıştırıp Yaz butonuna basalım. Diskin C: bölümünde deneme.bin isimli bir dosya oluÅŸmuÅŸ olmalı. Herhangi bir hex editor ile (HxD) bu dosyayı açıp inceleyebilirsiniz. EÄŸer ayrıntısına girmek isterseniz Integer ve diÄŸer sayısal deÄŸerlerin nasıl yazıldığını inceleyebilirsiniz. Mesela demiÅŸtik ki dosyamızın ilk 4 byte’ında bir Integer bulunmaktadır. Dosyamızı bir hex editör ile açtığımızda ilk 4 byte’ında 98 3A 00 00 yazdığını görürüz. IBM (x86) tabanlı makinelerde bu veriler tersten yazılırlar. Bu yüzden bu ifadeyi 00 00 3A 98 olarak düşüneceÄŸiz. Hesap makinesini açıp 16′lık Hex moda geçelim. Tabi bunu yapabilmek için bilimsel moda geçmeniz gerekmektedir. Hex modu seçili iken 3A98‘i yazalım. Ardından Dec yani ondalık olarak her zaman kullandığınız sayı formatına çevirelim. Ve karşımızda 15000 sayısını göreceÄŸiz ki bu deÄŸer örneÄŸimizde Integer olarak dosyanın baÅŸ tarafına yazdırılmıştı. DiÄŸer veri tiplerinin nasıl kaydedildiÄŸini bu ÅŸekilde inceleyerek bulabilirsiniz.

Åžimdi gelelim bu deÄŸerleri okumaya… Oku butonumuza çift tıklayıp ÅŸu kodları girelim:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  BirInteger: Integer;
  BirDouble: Double;
  BirReal: Real;
  BirByte: Byte;
begin
  DosyaOku := TFileStream.Create('c:\deneme.bin', fmOpenRead or fmShareDenyNone);
  try
    DosyaOku.ReadBuffer(BirInteger, SizeOf(Integer));
    DosyaOku.ReadBuffer(BirDouble, SizeOf(Double));
    DosyaOku.ReadBuffer(BirReal, SizeOf(Real));
    DosyaOku.ReadBuffer(BirByte, SizeOf(Byte));
    ShowMessage('Integer: ' + IntToStr(BirInteger) + #13 +
      'Double: ' + FloatToStr(BirDouble) + #13 +
      'Real: ' + FloatToStr(BirReal) + #13 +
      'Byte: ' + IntToStr(BirByte)
    );
  finally
    DosyaOku.Free;
  end;
end;

Åžimdi bu programı çalıştıralım ve bu sefer oku butonuna basalım. Ve karşımızda dosyaya yazdırdığımız deÄŸerler…

Gördüğünüz gibi okuma iÅŸlemi yazma iÅŸleminden farklı deÄŸil. Ä°htiyacımız olan tek ÅŸey bir buffer ve bu buffer’ın tipinin boyutu. EÄŸer deÄŸiÅŸken tipinin boyutunu yanlış girersek veya okuma sırasını yer deÄŸiÅŸtirirsek, istediÄŸimiz sonucu alamayız. Çünkü stream üzerine yazarken, bu sırada ve bu deÄŸiÅŸken tipleri ile yazılmıştır. Okurken de aynı sıra ve uzunlukta okunmalıdır. Bu yüzden, bu ÅŸekilde kendi dosya formatlarımızı oluÅŸtururken, bir plan üzerinde dosya formatında hangi pozisyonda hangi veri bulunacağı ve boyutu belirlenmelidir.

Gördüğünüz gibi sayısal verileri okumak ve yazmak hiç de zor değil. Şimdi dilerseniz karakter dizilerini nasıl okuyup yazacağımızı görelim.

Karakter Dizilerinin Okunup Yazılması

Karakter dizisi dediÄŸimizde aklımıza gelen ilk deÄŸiÅŸken tipleri string ve PChar‘dır. EÄŸer Delphi 2009′dan önceki bir sürüm kullanıyorsanız bu deÄŸiÅŸken tipleri ANSI‘dir. Yani her bir karakter bir byte yer kaplar. D2009 ve sonrası için her bir karakter Unicode olduÄŸu için 2 byte yer kaplarlar.

İlk önce PChar verilerini nasıl yazıyoruz ve okuyoruz onu görelim:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: PChar;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Karakterler^, Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Karakter verililerini yazdırırken ve okurken dikkat etmemiz gereken nokta yine verinin kapladığı alandır. Karakter dizisinin kapladığı alanı hesaplayabilmek için bir karakterin ne kadar yer kapladığını bilmemiz gereklidir. Önceden de dediÄŸim gibi, eÄŸer karakterleriniz ANSI ise yani Unicode deÄŸilse, her bir karakter 1 byte yer kaplar. Bu yüzden bu örneÄŸimizde yazılacak uzunluk olarak karakter sayısını verdik. Çünkü ANSI karakter katarlarında karakter sayısı, karakter dizisinin boyutuna eÅŸittir. Fakat PChar yerine PWideChar kullansa idik ya da bu kodları D2009 ve üzeri bir sürümde çalıştırsa idik her bir karakteri 2 byte olarak alacaktık. Bu durumda karakter sayısı karakter dizisinin boyutuna eÅŸit deÄŸil, boyutun yarısı kadarı olacaktı. Yani Yukarıdaki kodda PChar‘ı PWideChar yaparsak WriteBuffer metodunun ikinci paramteresine Length(Karakterler) * 2 yazmamız gerekiyordu. Bu bahsettiÄŸimizi örneÄŸimizde deÄŸiÅŸtirip deneyin ve bir hex editör ile her bir karakterin 2 byte yer kapladığına ÅŸahid olun. Ama daha sonra tekrar PChar olarak deÄŸiÅŸtirip dosyayı tekrar yazın. Çünkü birazdan yapacağımız okuma iÅŸleminde PChar olarak okutacağız.

Okuma iÅŸlemine geçmeden önce WriteBuffer metodunda ilk parametreye bir göz atalım. Burada gördüğünüz gibi Karakterler deÄŸiÅŸkeninin sonuna ^ operatörünü ekledik. Bu operatör, iÅŸaretçilerle (pointer) birlikte kullanılan özel bir operatördür. Bir iÅŸaretçinin iÅŸaret ettiÄŸi esas deÄŸere eriÅŸmek için bu operatörü kullanıyoruz. ÖrneÄŸimizde ise PChar tipindeki deÄŸiÅŸkenimizin iÅŸaret ettiÄŸi gerçek deÄŸeri buffer parametresi olarak girdik. Çünkü PChar da bir çeÅŸit iÅŸaretçidir. Ve Karakterler^ yazmak ile bu iÅŸaretçinin hafızada iÅŸaret ettiÄŸi gerçek karakter verisini buffer olarak girdik.

Şimdi yazdırdığımız bu stream verilerini okuyalım:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: PChar;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    Karakterler := AllocMem(22);
    DosyaOku.ReadBuffer(Karakterler^, 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

İlk yaptığımız işlem Karakterler değişkeni için hafızadan yer ayırmaktır. Bunun için AllocMem fonksiyonu kullanılır. Tabi bunun için okuyacağımız verinin ne kadar uzunlukta olduğunu bilmemiz gerekiyor. Eğer okuyacağımız karakter verilerinin uzunluğu belli değilse ya da duruma göre boyut değişebiliyorsa bu durumda daha başka bir şeyler yapmamız gerekecek. Bununla ilgili ayrıntılı bilgiyi ilerleyen konularda bulacağız. Ama şimdilik veri uzunluğumuzu sabit kabul ederek işlemlerimizi yapalım.

AllocMem ile hafızadan yer ayırdıktan sonra bu hafıza bölgesine stream verilerini yerleÅŸtirebiliriz. Bunun için yine ReadBuffer ile stream’den veri okuyoruz ve buffer’a atıyoruz. Yine buffer olarak iÅŸaretçinin gerçek deÄŸerini ifade eden ^ operatörünü kullanıyoruz. Ä°kinci parametrede de ne kadar uzunlukta okuyacağımızı belirliyoruz.

PChar ile veri okuma ve yazma bu ÅŸekilde olmakta. Peki string bir deÄŸiÅŸkeni nasıl yazıp okuyacağız? Aslında PChar‘da kullandığımız yöntemden farklı deÄŸil. Çünkü string ile PChar arasında çok büyük bir fark bulunmamakta. Zaten çalışma anında bu iki tip arasında dönüşümler rahatlıkla yapılabilmektedir. Yazma için yazdığımız kodları aÅŸağıdaki gibi deÄŸiÅŸtirelim:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: string;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Pointer(Karakterler)^, Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Önceki yazma işleminde çok farklı olmadığını burada görüyoruz. Tek yaptığımız işlem derleyiciye, string değişkene bir işaretçi gibi davranmasını söylüyoruz. Bu şekilde derleyici, string olan Karakterler değişkenini bir işaretçi gibi düşünecek ve ^ operatörü ile esas hafıza bölgesindeki veriyi buffer olarak kullanacak. Burada Pointer yerine PChar yazarak da type casting yapabilirsiniz.

Okuma kodları PChar‘a göre fazla ya da eksik deÄŸil. Önceki okuma fonksiyonumuzu aÅŸağıdaki gibi deÄŸiÅŸtirelim.

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: string;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    SetLength(Karakterler, 22);
    DosyaOku.ReadBuffer(Pointer(Karakterler)^, 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

AllocMem yerine string için SetLength fonksiyonunu kullanıyoruz. Böylece string olan deÄŸiÅŸkenimizin boyutunu belirliyoruz. ReadBuffer‘da yapılanlar önceden anlatılmıştı.

String için yaptığımız bu işlemler biraz pointer yani işaretçi bilgisi gerektiren işlerdi. Halbuki bu pointer işlerine girmeden de string verileri yazıp okuyabiliriz. Ama ilk önce bu şekilde vermemin sebebi, esasında işin arkaplanda çalışma şeklini göstermekti.

Aslında diziler ve iÅŸaretçi olan PChar gibi karakter katarları hafızada bulunan esas verilerdeki ilk elemana iÅŸaret ederler. Derleyici bu deÄŸiÅŸken tipleri ile uÄŸraşırken bunların uzunluÄŸundan haberdardır ve ilk pozisyondan itibaren hafızada bu deÄŸiÅŸkenler üzerinde iÅŸlem yapabilir. Esasında PChar ve string‘de ortak olarak yapılan iÅŸlem, karakter dizisinin ilk elemanını buffer olarak girmektir. Her iki durumda da ^ operatörü dizinin hafızadaki ilk karakterine iÅŸaret eder. Geri kalanında Write ya da Read metodları verilen uzunluk kadar bu ilk karakterden itibaren okumaya ya da yazmaya baÅŸlar. Yukarıda string için yazdığımız kodları ÅŸu ÅŸekilde daha kolay ve sade bir ÅŸekilde de yazabiliriz:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: string;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    SetLength(Karakterler, 22);
    DosyaOku.ReadBuffer(Karakterler[1], 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: string;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Karakterler[1], Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Gördüğünüz gibi pointer’lardan kurtulup, bize yakın olan kodları kullandık ve aynı sonucu aldık. Ama arka planda derleyici bizim ilk yazdığımız ve iÅŸaretçileri kullandığımız kısımdaki gibi çalışır.

Burada tek yaptığımız iÅŸlem buffer olarak string deÄŸiÅŸkeninin ilk karakterini girmek. Tabi okuma iÅŸleminde yine SetLength‘i unutmuyoruz. Çünkü okuma iÅŸleminden önce hafızada yeterince yer ayrılması ÅŸarttır.

Önceden de dediğim gibi uzunluğu sabit uzunlukta olmayan karakter dizileri için ayrı bir konu başlığı ayırdık. O zamana kadar karakter dizimizin boyutunu sabit kabul edeceğiz.

Record’ların Stream Verileri Olarak Kullanılması

Genelde stream ile yapılmak istenen bir gurup veriyi yazmak ve okumaktır. Bu gurup verileri ise genelde record‘lar ile tutarız. Mesela aÅŸağıda bulunan record içinde bir çok deÄŸiÅŸik deÄŸiÅŸken tipi bulunmaktadır.

TDosyaBasligi = record
  Imza: string[3];
  Versiyon: Double;
  IcerikBoyutu: Integer;
end;

Record’ları streamler ile beraber kullanırken ÅŸuna dikkat etmemiz gerekiyor. Bir record verisini stream ile okuyup yazabilmek için, record içeriÄŸinin sabit uzunluklu verilerden oluÅŸuyor olmasıdır. Aksi halde bu record, özel iÅŸlemler yapılmadığı taktirde, streamlerde kullanılmak için elveriÅŸli deÄŸildir. Bu yüzden yukarıda string deÄŸiÅŸkenini 3 karakter ile sınırlandırdık.

Okuma esnasında da aynı record verisini kullanarak rahat bir şekilde okuma işlemini yapabilriiz. Peki ama bu bize ne avantaj sağlayacak?

Önceki örneklerde gördüğümüz gibi, herbir string, Integer, Double gibi değişkenler için ayrı ayrı Read ve Write metodları kullandık. Halbuki bu değişkenler eğer sabit bir formda ise bunları bir paket halinde okuyup yazabilmeliyiz. İşte bu paket halinde okuyup yazma işlemi için recordları kullanıyoruz. Yani yukarıda verdiğimiz TDosyaBasligi isimli recordu yazabilmek için tek tek içinde bulunan 3 değişkeni yazdırmamız gerekmiyor. Sadece TDosyaBasligi isimli recordu yazdırmamız kafidir.

Åžimdi yukarıda verdiÄŸmiz recordu interface kısmında, TForm tanımlamasının yukarısında ama type‘ın altında yazalım. Ve Yaz butonunun OnClick olayına ÅŸunları yazalım:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Paket: TDosyaBasligi;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Paket.Imza := 'DYZ';
    Paket.Versiyon := 1.2;
    Paket.IcerikBoyutu := 1500;
    DosyaYaz.WriteBuffer(Paket, SizeOf(TDosyaBasligi));
  finally
    DosyaYaz.Free;
  end;
end;

Gördüğünüz gibi herhangi bir ekstra işlem yapmadım. Sanki basit bir sayısal veriyi yazdırır gibi recordumuzu yazdırdık. Aynı şekilde okumasını da gerçekleştirelim:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Paket: TDosyaBasligi;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    DosyaOku.ReadBuffer(Paket, SizeOf(TDosyaBasligi));
    ShowMessage(Paket.Imza + #13 + FloatToStr(Paket.Versiyon) + #13 +
      IntToStr(Paket.IcerikBoyutu));
  finally
    DosyaOku.Free;
  end;
end;

Bu programı çalıştıralım ve ilk önce Yaz sonra da Oku buttonlarına tıklayalım. Böylece bir recordu yazıp okuyabildik. Fakat disk üzerine yazılan dosyayı bir hex editör yardımı ile incelersek göreceÄŸiz ki ilk kısımda bulunan 3 karakterlik stringten önce 1 byte’lık bir veri bulunmaktadır. Önceki string yazma iÅŸlemlerinden farklı olarak burada record içindeki stringlerin sadece verisi yazdırılmaz. String deÄŸiÅŸkeninin tamamı record ile beraber yazdırılır. String deÄŸiÅŸkenin tamamından kastımız stringi oluÅŸturan parçalardır. Bir string, PChar gibi karakter dizilerinden farklı olarak ilk 0. baytında stringin veri uzunluÄŸunu tutar. Bu örneÄŸimizde 3 karakter uzunluÄŸunda olduÄŸu için hex editörde ilk göreceÄŸimiz deÄŸer 03 deÄŸeridir. Tabi bu tek bytelık alanda en fazla 255 deÄŸeri yani FF deÄŸerini tutlabilir. Bu yüzden sınırlı bir string(literal string) kullanabilmek için en fazla 255 karakter kullanabiliriz. Aksi halde daha baÅŸka yollara baÅŸvurmalıyız. BaÅŸta bulunan 03 ifadesini kaldırıp sadece string verisini yazdırmak istersek array kullanmamız gerekmektedir. Array kullanımını bir sonraki konuda göreceÄŸiz.

Sabit uzunluklu recordları kaydederken gördüğünüz gibi hiç zorlanmıyoruz. Eğer record içeriği burada olduğu gibi sabit uzunluklu değilse yani record içine PChar ya da limitsiz string girersek ne yapacağız. Bu durumda eğer yapabiliyorsak değişken uzunluklu olanları recorddan çıkartıp işlemlerimizi o şekilde yapmalıyız. Değişken uzunluklu verileri recorddan ayrı olarak okuyup yazmamız gerekmektedir. İleriki konularımızda değişken uzunluklu veriler ile nasıl çalışacağımızı da göreceğiz.

Dizileri Stream Verisi Olarak Kullanmak

Aslında dizileri stream üzerine yazmak için, buraya kadar öğrendiÄŸimiz bilgiler yeterli. String’leri nasıl yazdırır ve okutuyorsak, aynı ÅŸekilde array’leri de yazdırıp okutabiliyoruz.

//Yazdırmak için
var
  FS: TFileStream;
  BirDizi: array[0..5] of Integer;
begin
  FS := TFileStream.Create('c:\deneme.bin', fmCreate or fmShareDenyNone);
  try
    BirDizi[0] := 153;
    BirDizi[1] := 1;
    BirDizi[2] := 3442;
    BirDizi[3] := 902;
    BirDizi[4] := 455;
    FS.WriteBuffer(BirDizi[0], SizeOf(BirDizi));
  finally
    FS.Free;
  end;
end;

//Okutmak için
var
  FS: TFileStream;
  BirDizi: array[0..5] of Integer;
begin
  FS := TFileStream.Create('c:\deneme.bin', fmOpenRead or fmShareDenyNone);
  try
    FS.ReadBuffer(BirDizi[0], SizeOf(BirDizi));
    ShowMessage(IntToStr(BirDizi[0]) + #13 +
      IntToStr(BirDizi[1]) + #13 +
      IntToStr(BirDizi[2]) + #13 +
      IntToStr(BirDizi[3]) + #13 +
      IntToStr(BirDizi[4]) + #13);
  finally
    FS.Free;
  end;
end;

Gördüğünüz gibi ilk elemanını buffer olarak giriyoruz ve ikinci parametre olarak da dizinin boyutunu parametre olarak giriyoruz.

Eğer dinamik array kullanıyorsak okuma işlemini gerçekleştiren ReadBuffer metodundan önce mutlaka SetLength ile dizinin boyutunu belirlemiş olmalıyız. Ayrıca dizinin kapladığı alanı bulabilmek için dinamik dizinin eleman sayısı ile elaman tipinin boyutunu çarpmalıyız. Yani yukarıdaki örnekte dinamik dizi kullanmış olsa idik Length(BirDizi) * SizeOf(Integer) kazacaktık.

İki ve daha fazla boyuttaki diziler için ise, iç içe bir for döngüsü kurularak bir okuma ve yazma algoritması geliştirilebilir.

Bu kısım diziler için kolay kısımdı. Çünkü bunlar önceki öğrendiklermizden farksızdır. Fakat eÄŸer ActiveX ile uÄŸraşıyorsanız, Word, Excel gibi programların otomosyonu ile uÄŸraşıyorsanız variant array‘ler ile uÄŸraÅŸmışsınızdır. Ä°ÅŸte bu durumda variant olan array’leri stream’e kaydetmek ve stream’den okutmak bu kadar kolay deÄŸildir. Ama zor da deÄŸildir. EÄŸer ActiveX ile uÄŸraÅŸmıyorsanız diÄŸer baÅŸlığa atlayabilirsiniz, ya da nasıl yapıldığı hakkında fikir sahibi olmak için kalıp okuyabilirsiniz.

Bu örneğimizde otomosyon ya da ActiveX nesnelerine girmeyeceğim. Bir şekilde bu nesnelerden variant array verilerini aldığınızı düşünerek haraket edeceğim.

var
  VariantArray: Variant;
  VArraySize: Integer;
  PArray: Pointer;
  FS: TFileStream;
begin
  VariantArray := ActiveXNesnesi.ArrayDonderenMetod; //Bu kısım size ait...
  VArraySize := VarArrayHighBound(VariantArray, 1) - VarArrayLowBound(VariantArray, 1) + 1;
  PArray := VarArrayLock(VaraintArray);
  FS := TFileStream.Create;
  try
    FS.WriteBuffer(PArray^, VArraySize);
  finally
    FS.Free;
  free;
  VarArrayUnlock(VaraintArray);

Karışık gibi görünse de eÄŸer ActiveX ile uÄŸraşıyorsanız bu kısım size zor gelmeyecektir. Ä°lk baÅŸta bir nesneden variant array deÄŸerini aldık. Bu deÄŸeri siz delphi içinde de oluÅŸturabilirsiniz. Ardından bu array’in boyutunu hesapladık ve VArraySize isimli deÄŸiÅŸkene attık. Burada dikkat etmeniz gereken nokta, bu örneÄŸimizde diziyi byte, char gibi her elemanı 1 byte olan bir diziye göre hesapladık. EÄŸer array’deki elemanların boyutu 1 byte’dan fazla ise bu durumda:

VArraySize := (VarArrayHighBound(VariantArray, 1) -
  VarArrayLowBound(VariantArray, 1) + 1) * TVarData(VariantArray).VArray^.ElementSize;

gibi bir ÅŸeyler yazmamız gerekiyordu. Yani eleman sayısı ile bir elemanın boyutunu çarpıyoruz. Daha sonraki gelen iÅŸlemlerde, variant array’in ilk elemanının iÅŸaretçisini alıyoruz. Bunun için VarArrayLock fonksiyonundan faydalanıyoruz. Bu iÅŸaretçiyi daha sonra buffer olarak WriteBuffer‘da kullanıyoruz. Bu iÅŸaretçi ile iÅŸimiz bitince VarArrayUnlock yapmayı unutmuyoruz.

Variant dizisini stream’den okurken de VarArrayCreate fonksiyonunu kullanıyoruz ve yeni bir dizi oluÅŸturuyoruz. Ardından aynı VarArrayLock ve VarArrayUnlock iÅŸlemleri arasında dizimizi stream’den okuyoruz. Bu kısmı size bırakıyorum…

DeÄŸiÅŸken Uzunluktaki Verileri Okuyup Yazmak

Buraya kadar öğrendiğimiz işlemlerde hep varsayılan bir uzunluktan bahsettik. Fakat her zaman durum bu şekilde olmuyor.

Mesela, kullanıcının bir TMemo bileÅŸenini doldurduÄŸu bir form var. Biz bu TMemo‘da bulunan yazıyı ve baÅŸka verileri kendi dosya formatımızda saklamak istiyoruz. Ya da veritabanına kendi formatımızda kaydetmek istiyoruz. Bu durumda string’in ne uzunlukta olduÄŸunu yazarken bilebiliriz fakat okurken bilemeyiz. Çünkü dosya’da ya da herhangi bir stream’de kayıtlı bulunan o string’e ait uzunluk, artık bizim bilgimizin dışına çıkmıştır. Buraya kadar yaptığımız örneklerde hep yazma ve okuma iÅŸlemlerini aynı programa koyduk ve aynı çalışma zamanında iÅŸlettirdik. Bu yüzden okuduÄŸumuz verilerin boyutunu her zaman biliyorduk. Halbuki okuma fonksiyonu ayrı bir iÅŸlemde ise ya da programı açıp kapadığımızda da okuma iÅŸleminin çalışmasını istiyorsak bu durumda kaydedeceÄŸimiz veriyi özel bir biçimde kaydetmeliyiz.

Bu ve bunun gibi durumlarda yapacağımız işlem çok basit ve her türlü değişken uzunluklu veri tipi için geçerlidir. Yapacağımız tek şey değişken uzunluklu olan verinin boyutunu sabit bir pozisyona yazmaktır. Ardından okuma esnasında bu sabit pozisyondaki değeri okutarak değişken olan verinin boyutu hakkında bilgi sahibi olabiliriz.

Mesela stream formatımız şu şekilde olsun:

Tabi bu çok basit bir format şekli. Normalde bir çok sabit içerikle beraber bir çok değişken içeriği iç içe kullanmamız gerekebiliyor.

Formatımıza göre ilk 3 byte’da dosya imzası bulunacak. Ardından gelen 8 byte dosyanın versiyonunu tutacak. Ve sonrasında gelen 4 byte’lık Integer deÄŸer ise bizim üzerinde uÄŸraÅŸtığımız esas konudur. Çünkü bu Integer deÄŸer sonrasında gelen string içeriÄŸin boyutunu tutmaktadır. Böylece okuma esnasında string verimizi ne kadar okuyacağımızı belirleyebiliyoruz.

En sonda ise 4 byte’lık bir Integer daha ekledim. Bu deÄŸer aslında bu örneÄŸimizi için gerekli deÄŸil. Fakat burada bir noktaya dikkatinizi çekmek istediÄŸimden bu deÄŸeri de dosya formatına ekledim.

DeÄŸiÅŸken uzunlukta olan string, array ya da herhangi bir deÄŸiÅŸkeni kaydederken normalde ilk akla gelen stream’in sonuna kadar okumak olacaktır. Ya da stream’in uzunluÄŸundan diÄŸer verilerin boytunu çıkarmak olacaktır. Halbuki iÅŸin içine iki veya daha fazla deÄŸiÅŸken uzunlukta veri girdiÄŸinde ve buradaki örnekte olduÄŸu gibi deÄŸiÅŸken uzunluktan sonra da bir baÅŸka veri geldiÄŸinde bu mantık bizi idare etmeyecektir. Aynı ÅŸekilde dosya formatımızı sürekli olarak güncellenebilen bir format ise bu mantık yine çökecektir.

Bu durumda en mantıklı işlem, değişken verilerin başında bu verinin uzunluğunu saklamak olacaktır. Böylece sonrasında gelen değişken uzunluktaki veri rahatlıkla okunabilir.

Şimdi bu anlattıklarımızı pratiğe dökelim ve yukarıdaki stream formatımızı yine bir dosya üzerinde yazıp okuyalım. Bunun için yeni bir uygulama açın ve form üzerine bir adet button ve bir adet memo yerleştirin.

Unit’in interface kısmında TForm1 tanımlamasının hemen üstünde(type bloÄŸu içinde) ÅŸunları yazalım:

type
  TDosyaBasligi = record
    Imza: array[0..2] of Char;
    Versiyon: Double;
    IcerikBoyutu: Integer;
  end;

Buttonnun OnClick olayına aşağıdakileri yazalım.

var
  FS: TFileStream;
  Baslik: TDosyaBasligi;
  Icerik: string;
  Rastgele: Integer;
begin
  FS := TFileStream.Create('c:\deneme.dyz', fmCreate or fmShareDenyNone);
  try
    Icerik := Memo1.Lines.Text;
    //Başlık bilgilerinin yazımı
    Baslik.Imza := 'DYZ';
    Baslik.Versiyon := 1.2;
    Baslik.IcerikBoyutu := Length(Icerik);
    FS.WriteBuffer(Baslik, SizeOf(TDosyaBasligi));

    //Değişken boyutlu içeriğin yazımı
    FS.WriteBuffer(Icerik[1], Length(Icerik)); //Unicode olduÄŸunda Length * 2

    Randomize;
    Rastgele := Random(100);
    FS.WriteBuffer(Rastgele, SizeOf(Integer));
  finally
    FS.Free;
  end;

Burada aslında yeni bir şeyler görmedik. Sadece öğrendiklerimizi bir problemin çözümünde kullandık.

Baslik yazdırılmadan önce, deÄŸiÅŸken uzunluktaki içeriÄŸimiz olan memo’nun Text bilgisinin uzunluÄŸunu, Baslik record verisi içine alıyoruz. Ardından bu recordu stream’e yazdıktan sonra, deÄŸiÅŸken içeriÄŸin uzunluÄŸu da yazılmış oldu. Ardından normal bir stringi yazdırır gibi bütün karakterlerini stream üzerine yazdırdık. Ardından da rastgele bir sayıyı bu deÄŸiÅŸken uzunluktaki veriden sonra yazdırdık. Artık programı çalıştırıp Memo içine bir ÅŸeyler yazalım ve button’a basıp verileri stream üzerine kaydedilim.

Åžimdi gelelim bu stream formatının okunmasına… Bunun için ayrı yeni bir uygulama açalım ve bir button ekleyelim. Ve bu buttonun OnClick olayına geçip ÅŸunları yazalım:

var
  FS: TFileStream;
  Baslik: TDosyaBasligi;
  Icerik: string;
  Rastgele: Integer;
begin
  FS := TFileStream.Create('c:\deneme.dyz', fmOpenRead or fmShareDenyNone);
  try
    //Başlık bilgilerinin okunması
    FS.ReadBuffer(Baslik, SizeOf(TDosyaBasligi));

    if Baslik.Imza <> 'DYZ' then
    begin
      ShowMessage('Desteklenmeyen format');
      Exit;
    end;

    if Baslik.Versiyon > 1.2 then
    begin
      ShowMessage('Bu format ancak üst versiyonlarda açılabilir.');
      Exit;
    end;

    //Değişken boyutlu içeriğin okunması
    SetLength(Icerik, Baslik.IcerikBoyutu);
    FS.ReadBuffer(Icerik[1], Baslik.IcerikBoyutu);
    FS.ReadBuffer(Rastgele, SizeOf(Integer));

    ShowMessage(Icerik + #13 + IntToStr(Rastgele));
  finally
    FS.Free;
  end;
end;

Burada yaptığımız iÅŸlem sadece verilerin okunmasından ibaret. Sadece dikkat etmemiz gereken kısım, ReadBuffer‘ dan önce SetLength ile deÄŸiÅŸken uzunlukta olan verinin uzunluÄŸunu belirlememiz gerekiyor.

DeÄŸiÅŸken uzunluktaki stringler bu ÅŸekilde okutulabilir.

Bir küçük tüyo olarak, verileri yazdırdığımız kısımdaki şu kodlara bir daha göz atmanızı isteyeceğim:

  Icerik := Memo1.Lines.Text;
  ......
  ......
  Baslik.IcerikBoyutu := Length(Icerik);

Bu kodlar Baslik recordunun yazılmasından evvel doldurulmaktadır. Bazen öyle durumlar oluyorki, veri uzunluÄŸunu verinin stream’e tamamen yazdırılmasına kadar bilemiyoruz. Mesela deÄŸiÅŸken uzunlukta bu stringimiz, stream’e yazdırılma esnasında belli bir algoritma ile dinamik olarak oluÅŸturuluyor olabilir. Bu durumda string verisi tamamen stream üzerine yazdırılmadan, uzunluÄŸunu bilemeyiz. Bu durumda TStream‘e ait Seek metodunu kullanacağız. Bu metod stream üzerinde belli bir pozisyona atlamamızı saÄŸlamaktadır. Bu durumda kodumuz şöyle bir ÅŸey olacaktı:

  //Şimdilik yer ayırmak için 0 yazdırıyoruz.
  Baslik.IcerikBoyutu := 0;
  FS.WriteBuffer(Baslik, SizeOf(TDosyaBasligi));

  .....
  .....
  //Stream üzerine verilerin yazdırılması ve boyutunun hesaplanması...
  //Burada değişken uzunluktaki veri yazdırılmakla birlikte boyutu da hesaplanıyor.
  .....
  .....

  FS.Seek(15, soFromBeginning);
  FS.WriteBuffer(IcerikBoyutu, SizeOf(Integer));

Aynı ÅŸeyi Baslik recordunu en sonda yazdırmakla da yapabilrdik. Veya daha baÅŸka yollar ile de bu dediklerimiz yapılabilir. Burada bilmemiz gereken Seek metodunun kullanımıdır. Seek metodunda ilk parametre olarak 15 girdik. Çünkü örneÄŸimizdeki stream format tablomuza baktığımızda 15. byte pozisyonunda içerik boyutu bulunmaktadır. Seek ile stream’in yazma iÅŸaretçisini buraya taşıdık ve bu pozisyondan sonra 4 byte’lık bir Integer deÄŸer yazdırdık. Seek metodunda kullanılan ikinci parametre için help dosyalarını gezebilirsiniz.

Değişken uzunlukta olan diziler için, yani dinamik diziler için de aynı mantığı kullanmamız gerekmektedir. Değişken olan dizinin boyutunu da stream üzerine yazdırmamız ve okuma anında bu değeri okuyup diziyi SetLength ile tekrar oluşturmamız gerekmektedir. Yapacağımız işlemler aynı olacağı için bu kısmı size bırakıyorum.

Bu bölümde bu kadar bilgi yeterli. Gelecek bölümde stream verilerinin başka streamler üzerine aktarılması ve kopyalanması, streamler ile nesne ve bileşen kullanımı, hafıza, resource, veritabanı gibi ortamlarla stream kullanımı ve son olarak .NET ortamında stream kullanımından bahsedeceğiz. İkinci bölüme geçmeden burada anlatılanları iyi bir şekilde kavrayıp, kendi denemelerinizi yapmanız gerekmektedir.

EleÅŸtiri ve yorumlarınızı bekliyorum…

Fatih Tolga Ata – 2008

Aslında bu bölüm gerçekten uzun oldu. Normalde VCL kullanımını üçüncü bir bölüme taşımayı düşünüyordum. Ama bu konuda istekler olunca birleştrip yayınlamayı düşüdüm. İçeride sizi iki sayfalık bir makale bekliyor. Bu yüzden sayfa sonunda bitti zannedip kapatmayın!

Hazırsanız başlayalım.

Kanallar’ı EÅŸ Zamanlı Olarak Çalıştırmak

Kanallar ile uğraşırken karşılaşılan en büyük sorunlardan bir tanesi de şüphesiz kanalları ortak bir şekilde sorunsuz olarak çalıştırmaktır. Eminim kanallar ile uğraşan birisi bütün kanallar tarafından ortak olarak kullanılan bir kaynağa erişmede problemlerle karşı karşıya gelmiştir ve kanalları bir köşeye itmesine sebep olmuştur.

Mesela ÅŸu veritabanı problemi size tanıdık gelecektir. Diyelim ki, iki adet kanalımız var ve bunlardan birincisi veritabanındaki bir kaydı açıp deÄŸiÅŸiklik yapmaya baÅŸladı. Sonra ikinci kanal aynı kaydın belli bölümlerinde düzenlemeler yaptıktan sonra veriyi kaydetti. Ardından birinci kanal, aynı verilerdeki deÄŸiÅŸikliÄŸini bitirdi ve kaydetti. Birinci kanal, ikinci kanal’ın deÄŸiÅŸikliklerinden habersiz olduÄŸundan ikinci kanalın yaptığı düzenlemeler de uçtu gitti.

Burada okuduÄŸunuz problem, normalde kanallar ve veritabanı ile uÄŸraÅŸan bir çok programcının başına gelmiÅŸ bir problemdir. Bununla birlikte sadece veritabanında deÄŸil bir çok noktada özellikle bir dosyayı, bir portu, bir DLL’i veya baÅŸka bir ÅŸeyi, kanalların ortak kullanmasında hep benzer sıkıntılarla karşılaşılmıştır. Bu gibi sıkıntıların ve problemlerin çözümü kanalları eÅŸ zamanlı kullanım için kritik bölgeler tanımlamak ya da muteksleri kullanmaktır. Bu iki yöntem de makalemizin konuları arasındadır.

Kritik Bölgeler(Critical Sections)

Kritik Bölgeler -ya da baÅŸka yerlerde görebileceÄŸiniz gibi kritik kesimler, bölümler, vs..- yukarıda anlatığımız problemdeki, birinci kanalın kaynağı kullanması esnasında ikinci kanalın bu kaynaÄŸa eriÅŸmesini englelemek için kullanılır. Birinci kanal iÅŸini yapıyorken, ikinci kanal’a çalışması için bir zaman dili ayrılmaz. Böylece birinci kanal iÅŸini bitirene kadar ikinci kanal çalıştırılmaz.

Bunun için örnek bir uygulamada yukarıdaki anlattığımız senaryolara benzer bir problem oluşturalım ve çözümünü aramaya çalışalım.

Diyelim ki, iki adet kanalımız var ve bu kanallar bir döngünün her adımında bir dizi işlem gerçekleştiriyor. Ve bu gerçekleştirdikleri işlemler için ortak kullandıkları global olarak tanımlanmış bir değişken olsun. Meseleyi anlatabilmek için iki kanalında yaptığı işlemlerin sonucunun aynı olmasını sağlamak istiyorum. Böylece problem daha iyi anlaşılabilecek.

Birinci kanal bir döngünün her adımında global değişkenimize teker teker harfler ekliyor ve sonuçta değişkenimizde bir yazı oluşuyor. Aynı işlemi ikinci kanalımız da yapıyor ve sonuç olarak birinci kanal ile aynı yazıyı üretiyorlar. Yanlız ikinci kanal harfleri teker teker eklemek yerine ikişer ikişer ekliyor. Ekleme işlemi çok hızlı olduğundan problemin oluşması için aralara Sleep rutinini ekleyerek işlemi birazcık yavaşlatıyoruz. Şimdi bu mantığımızı koda dökmeye başlayalım.

Yeni bir VCL uygulaması açalım ve bir adet button ekleyelim. Aşağıdaki gibi unitin var bloğunda global bir değişken tanımlayalım:

var
  Form1: TForm1;
  SonucYazi: string; //Global deÄŸiÅŸkenimiz

Ardından buttonun OnClick olayını aşağıdaki gibi değiştirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  Kanal1ID, Kanal2ID: DWORD;
begin
  CreateThread(nil, 0, @Kanal1, nil, 0, Kanal1ID);
  CreateThread(nil, 0, @Kanal2, nil, 0, Kanal2ID);
end;

Bu iki adet kanalımıza ait kanal fonksiyonlarını da aşağıdaki gibi oluşturalım:

procedure Kanal1;
procedure Kanal2;

...

implementation

...

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
  end;
end;

Gördüğünüz gibi iki kanal fonksiyonu da aynı sonucu üretiyor. Ama sonucu üretme yolları farklı. Ayrıca iki kanal da peş peşe oluşturulup çalıştırılıyor. Forma bir adet daha button ekleyelim ve bize sonucu göstersin. Bunun için ikinci butonumuzun OnClick olayını aşağıdaki gibi düzenleyelim:

procedure TForm1.Button2Click(Sender: TObject);
begin
  ShowMessage(SonucYazi);
end;

Bu programı çalıştırdıktan sonra ve kanalları birinci düğme ile çalıştırdıktan sonra sonuç yazının "diyezon diyezon diyezon …" gibi bir ÅŸey olmasını isteriz. Yani bir for döngüsünün bir adımı tamamlanmadan SonucYazi isimli global deÄŸiÅŸkene müdahale olmasını istemeyiz. Halbuki programı çalıştırdığınızda sonucun hiç de böyle olmadığını göreceÄŸiz. Kanal1 iÅŸini bitirip "diyezon " yazmadan Kanal2 iÅŸe karışmış ve aralarda kendi harflerini eklemiÅŸtir. Hakeza bu, Kanal2 için de geçerlidir. Yani Kanal2, döngünün bir adımını bitirip istenilen sonucu veremeden Kanal1 global deÄŸiÅŸkenimize müdahale etmiÅŸtir.

Burada verdiÄŸimiz örnek biraz soyut kaçabilir. Çünkü yaptığımız iÅŸlemden sonuç olarak elimize bir ÅŸey geçmiyor. Ama karşılaÅŸacağınız sorunlar hep bu tarzda sorunlardır. KarşılaÅŸtığınız sorunları verdiÄŸimiz bu örnek ile kıyaslama yapabilirsiniz. Mesela biz bu örneÄŸimizde iÅŸlem adımlarını yavaÅŸlatmak için Sleep rutinini kullandık. Normal hayatta kanallar ile uÄŸraşırken zaten yaptığımız iÅŸlemlerin adımları Sleep rutinini aratmamaktadır. Mesela bir veritabanı tablosunda Edit ve Post gibi metodları kullandığımızda belli bir miktar iÅŸlemin tamamlanmasını bekleriz. Bir de eÄŸer sizde sonuç düzgün çıkıyorsa yine söylüyorum iÅŸlemciniz, bu makaleyi yazdığım sıralardaki iÅŸlemcimden hızlı demektir. Bu durumda Sleep rutinine verdiÄŸimiz deÄŸerleri çok az miktarlarda artırmayı deneyin.

Sadede gelelim ve problemi anladı isek şöyle bir soruyu kafamıza getirelim: Bir kanal belli bir işini bitirmeden önce diğer kanalların müdahalesini nasıl engelleyebiliriz?

Cevabı zaten bu bölümün başında verdik. Bunun için belli yerleri kritik bölge ilan edeceğiz. Bir kanalda kritik bölge ilan ettiğimiz yerdeki kodlar çalışmaya başladığı sırada, diğer kanallardaki aynı kritik bölgedeki kodlar işletilmez ve bekler. Yani aynı kritik bölgeye sahip kanallardan aynı anda sadece bir bölgedeki kodlar çalıştırılabilir. Böylece diğer kanalların istenilmeyen müdahalesi engellenmiş olur.

Bir Kritik bölge tanımlamak için bilmemiz gereken üç dört adet Windows apisi vardır.

InitializeCriticalSection: Bu fonksiyon kritik bölge’yi temsil eden recordun ilk deÄŸerlerini atamakla sorumludur. Yani kritik bölgeyi kullanıma hazırlamaktadır. Genelde formun OnCreate olayında kullanılır.

DeleteCriticalSection: Yukarıdaki fonksiyonun tam tersi olarak, bu fonksiyon da kritik bölgeyi ortadan kaldırır. Genelde formun OnDestroy olayına yerleştirilir.

EnterCriticalSection: Bu fonksiyonu çalıştırdığınız satırdan itibaren kritik bölgenin baÅŸlangıcını belirtirsiniz. Yani Delphi’deki "begin" kelimesi gibi düşünebilirsiniz.

LeaveCriticalSection: Bu fonksiyon ise, çalıştırıldığı satırla kritik bölgeyi sınırlandırır. Yine Delphi’deki "end" ifadesine benzetebiliriz.

Kritik bölgeyi temsil eden record ise TRTLCriticalSection tipindedir. Normalde Windows SDK yardım dosyalarında LPCRITICAL_SECTION ÅŸeklinde tanımlanmıştır. Ama Delphi ekibi bir çok windows yapısını tanımlarken bunlara "T" ile baÅŸlayan daha iyi okunur alias isimler vermiÅŸler. Her neyse…

Kritik bölgenin tanımlanması gayet basittir. Bir kritik bölgeyi işletim sistemine tanıtmak için InitializeCriticalSection fonksiyonunu kullanıyoruz. Kritik bölge ile işimiz bittiğinde de DeleteCriticalSection fonksiyonunu çağırmayı unutmuyoruz. Ardından kanal fonksiyonlarımızda kritik bölgeleri belirleyip başına EnterCriticalSection ve sonuna LeaveCriticalSection sonksiyonlarını koyuyoruz.

Örneğimize dönelim ve kritik bölgeleri eklemeye başlayalım. Bizim müdahale istemediğimiz bölge, kanal fonksiyonlarındaki döngülerin her bir adımıdır. Yani teker teker veya ikişer ikişer ekleme yapılan kısımlarda bir adım işini bitirmeden başka bir kanalın global değişkenimize müdahalesini engellemek istiyoruz. Kısacası kritik bölgemiz bu örnekte, döngünün her bir adımı olmalıdır.

İlk başta global olarak bir değişken daha tanımlayalım. Bu değişken bizim kritik bölgemizi temsil eden record olsun.

var
  Form1: TForm1;
  SonucYazi: string;
  BirinciKritikBolge: TRTLCriticalSection; //kritik bölgemizi temsil ediyor.

Ardından formun OnCreate ve OnDestroy olaylarını aşağıdaki gibi değiştirelim.

procedure TForm1.FormCreate(Sender: TObject);
begin
  InitializeCriticalSection(BirinciKritikBolge);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  DeleteCriticalSection(BirinciKritikBolge);
end;

Eğer başka kritik bölgeler de tanımlamış iseniz bunları da InitializeCriticalSection ve DeleteCriticalSection fonksiyonlarını kullanarak oluşturmalı ve silme işlemlerini gerçekleştirmelisiniz. Bizim örneğimizde bir adet kritik bölge yeterlidir.

Şimidi kanal fonksiyonlarında bahsettiğimiz yerleri kritik bölge olarak ilan edelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitiÅŸi
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitiÅŸi
  end;
end;

Yapacağımız baÅŸka bir iÅŸlem kalmadı. Programı çalıştırıp deneybiliriz. Sonucun "diyezon diyezon diyezon …" gibi düzgün olduÄŸunu göreceÄŸiz. Çünkü Kritik bölge tanımlayarak sadece bir kanalın kritik bölgesini çalıştırmış olduk. Böylece bir kanal global SonucYazi deÄŸiÅŸkeni ile uÄŸraşırken diÄŸer kanal buna müdahale edemeyecektir.

Burada bir adet kritik bölge tanımladık. Sizler ihtiyaca göre projelerinizde bir çok kritik bölge tanımlayabilirsiniz. Ayrıca kritik bölgelerin birbirinden bağımsız hareket ettiğini de aklınızdan çıkarmayın. Bazen karıştırılan nokta bu kısım olabiliyor. Mesela bu örneğimizde bir adet kritik bölge mevcut ama iki farklı yapılan iş var.

Gördüğünüz gibi kanalları eş zamanlı olarak çalıştırmak o kadar da zor değilmiş. Tek yaptığımız bell bölgeleri kritik bölge olarak ilan etmek. Şimdi yeni bir kavramla daha tanışalım.

Muteksler(Mutex)

Ä°ngilizce’ de, mutual ve exclusive kelimelerinin birleÅŸiminden meydana gelmiÅŸtir. Dilimizde ise müşterek ve seçkin kelimeleri bu kelimeleri karşılamaktadır. Programlama terminolojisinde ise, sadece tek iÅŸlemdeki deÄŸil birden fazla iÅŸlemdeki kanalları eÅŸ zamanlı olarak kullanılmasını saÄŸlayan bir tekniktir.

Bir mutekse aynı anda sadece bir tek kanal sahip olabilir. Literatürde, bu mutekse, bir kanal sahip olduğunda, muteksin kanal tarafından "tetiklendiği" ya da "tutulduğu" söylenir. Aynı şekilde eğer kanal bu mutekse sahip deiğilse muteks "serbestir" ya da "tetiklenmemiştir" tabirleri kullanılır.

Şu an kafanızda mutekslerin ne olduğuna dair somut bir düşünce oluşmamış olabilir. Ama bölümün sonuna kadar okuduğunuzda neyin ne olduğuna dair bir fikir oluşacağına eminim.

Bir muteks, CreateMutex fonksiyonu ile oluşturulur. Bu fonksiyonun tanımlanması ve açıklaması aşağıdadır.

function CreateMutex(lpMutexAttributes: PSecurityAttributes;
  bInitialOwner: BOOL;
  lpName: PChar): THandle;

lpMutexAttributes: Muteksin güvenliği ile ilgli parametredir. Bu parametreye nil girerek varsayılan güvenlik özelliklerini ayarlamış oluyoruz.

bInitialOwner: Kanalın bu mutekse sahip olup olmadığını ya da yukarıda bahsettiğimiz gibi muteksin tetiklenip tetiklenmeyeceğini belirler. True ya da False giriyoruz. Genelde muteksi programın ana kanalında oluşturduğumuzdan, ana kanalın mutekse sahip olmasını istemeyiz. Bu yüzden genelde bu parametreye False gireriz.

lpName: Eğer farklı işlemler bu mutekse erişecekse bu muteksimize bir isim vermemiz gerekmektedir. Buraya nil de girebilirisiniz. Bu durumda isimsiz bir muteksimiz olur.

Bu fonksiyon eğer muteksi oluşturabilirse çıktı olarak muteksin handle numarasını dönderir. Eğer muteks oluşmamış ise 0 değerini çıktı olarak verir.

Muteksleri, kritik bölgeler gibi düşünebilirsiniz. Kritik bölge oluÅŸturmak için kullandığımız InitializeCriticalSection fonksiyonu yerine CreateMutex fonksiyonunu, kritik bölgenin baÅŸlangıcını belirten EnterCriticalSection yerine WaitForSingleObject fonksiyonunu, kritik bölgenin bitiÅŸini bildiren LeaveCriticalSection fonksiyonu yerine de ReleaseMutex fonksiyonunu kullanıyoruz. CloseHandle ile de CreateMutex ile oluÅŸan muteksin handle’ını kapatmayı da unutmuyoruz.

İlk önce bir muteks oluşturalım.

birmuteks := CreateMutex(nil, False, 'ornekmuteks');

Ardından kritik bölgeyi oluşturduğumuz yerlerdeki fonksiyonları muteksin fonksiyonları ile yer değiştiriyoruz. Şimdilik sadece Kanal1 için örnek verelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    WaitForSingleObject(birmuteks, INFINITE); //Muteksin tetiklenmesini bekle
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    ReleaseMutex(birmuteks); //Muteksi serbest bırak.
  end;
end;

Åžimdi muteksin ne olduÄŸuna dair kafanızda bir ÅŸeyler ÅŸekillenmeye baÅŸlmamıştır. Çünkü kodlara baktığımızda WaitForSingleObject fonksiyonu bir ÅŸeyleri bekliyor ve ReleaseMutex ise bir ÅŸeyi serbest bırakıyor. WaitForSingleObject, "tek bir nesne için bekle" gibi bir manası var. Esas yaptığı görev, birinci parametresinde verilen handle numarasına göre bir muteksi beklemektir. Ä°kinci parametresinde ise ne kadar bekleyeceÄŸini belirliyoruz. Bu örneÄŸimizde INFINITE (sonsuz) girmekle, bir muteks tetiklenene kadar bekleyeceÄŸini belirttik. Bu parametreye, en fazla ne kadar bekleneceÄŸini milisaniye ÅŸeklinde girebilirsiniz.

Muteksi anlamada genelde verilen örnek ve bence en iyi örnek bayrak yarışıdır. Bayrak yarışlarında bir şeritte ancak bir koşucu koşabilir. Bayrağı alan koşmaya başlar. Bir şeritte, bayrağa sahip olmayan, koşabilmek için bayrağı beklemesi gerekmektedir. Böyelece her bir şeritte sadece bir yarışçı koşabilir.

Aynen bunun gibi, kanallar çalışabilmek için mutekse sahip olmaları gerekmektedir. Mutekse sahip olan koşmaya yani çalışmaya başlar. Mutekse sahip olmayan, muteksin kendisine gelmesini bekler. Bir hatırlatma olarak, önceki paragraflarda sahip olmanın tetiklemek olduğundan bahsetmiştik.

İşte WaitForSingleObject ile muteksin bu kanalımıza gelmesini beklemiş oluyoruz. Ve bunu örneğimizde, INFINTE yani sonsuz süre kadar bekliyoruz. Ve muteksle işimiz bittiğinde diğer kanalların kullanabilmesi için muteksi ReleaseMutex ile serbest bırakıyoruz. Ve yine tekrar ediyorum "Bir mutekse aynı anda sadece bir tek kanal sahip olabilir."

CreateMutex ile oluÅŸturduÄŸumuz muteksin handle’nı formun OnDestroy olayında CloseHandle ile kapatmayı da unutmuyoruz. Yani kritik bölgelerde yaptığımız DeleteCriticalSection yerine

CloseHandle(birmuteks);

gibi bir şey yazmalıyız.

Bu örneği, makaleyi fazla uzatmasın diye, burada tüm kodlarını yazmayacağım. Muteks örnek projesini buradan indirebilirsiniz.

EÄŸer tek bir muteks deÄŸil de bir den fazla muteksi tetiklemesini bekelemek istersek ne olacak? Bu durumda WaiıtForMultipleObjects fonksiyonunu kullanacağız. WaitForSingleObject tek bir muteksi beklerken WaitForMultipleObject fonksiyonu birden fazla muteksi beklemektedir. Kullanım aynı olduÄŸu için bununla ilgili bir örnek yapmayacağım. Bu fonksiyon ile iligli tek söyleyebileceÄŸim ÅŸey ikinci parametrede beklediÄŸiniz mutekslerin handle’larını dizi ÅŸeklinde girmeniz olacaktır.

BaÅŸka Ä°ÅŸlemlerden Mutekslere Sahip Olma

Dediğimiz gibi, mantık olarak mutekslerin kritik bölgelerden tek farkı, başka program ve işlemlerdeki kanallar ile ortak ve eş zamanlı çalışmaya izin vermesidir. Bunun için muteksimize bir isim vermemiz gerektiğini söylemiştik. İşte bu ismi kullanarak başka bir işlem muteksin handle numarasını alabilir. Gerisinde de WaitForSingleObject ve ReleaseMutex fonksiyonlarında bu handle numarasını kullanabiliriz. Yani mevcut bir muteksin handle numarasını alabilmek için:

birmuteks := OpenMutex(0, False, 'ornekmuteks');

dememiz yeterli. Bunu yukarıdaki örneğimizde CreateMutex yerine kullanabilirsiniz. Ama unutmamanınız gereken nokta bunun ile mevcut bir muteksin handle numarasını alırız. Eğer muteks CreateMutex ile hiç oluşturulmamış ise bu fonksiyon 0 değerini dönderir.

OpenMutex fonksiyonunun parametreleri CreateMutex ile aynı olduğundan burada fazladan bir açıklama yapmayacağım.

Bu konuda bir örnek yapmak isterseniz yukarıda verdiÄŸimiz örneÄŸi iki uygulamaya bölebilirsiniz. Kanal1‘i birinci uygulamada, Kanal2‘yi de ikinci uygulamada oluÅŸturursunuz. Ve ikisinde de OnCreate olayında şöyle bir ÅŸey girersiniz:

var
  BirMuteks: THandle;
.....
procedure TForm1.OnCreate(....);
begin
  BirMuteks := OpenMutex(0, False, 'ornekmuteks');
  if BirMuteks = 0 then
    BirMuteks := CreateMutex(nil, False, 'ornekmuteks');

Kısaca burada yaptığımız işlem eğer "ornekmuteks" isminde bir mutex henüz oluşturulmamış ise oluşturuyoruz.

Bu şekilde iki veya daha fazla sayıda işlem tek bir muteks üzerinde kanallarını eş zamanlı olarak çalıştırabilirler. Bu örneği kendiniz yapmaya çalışın. Gerçi burada yapılmışı var . Ama lütfen indirip incelemeden önce kendiniz yapmayı deneyin.

—

İşte size iki adet yöntem. Ve ikisi de windows programlamada çok sık kullanılmaktadır. Kanalları beraber çalıştırmak istediğinizde, istrer muteks kullanın isterseniz kritik bölge tanımlayın. Her ikisinin de tanımlanması ve kullanılması çok kolay. Kafanızdaki "kanal kullanmak çok zordur" düşüncesini birinci bölümde aştığınızı düşünüyorum. Buraya kadar olan kısım ile de "kanalları eş zamanlı çalıştırmak zordur" düşüncesini yendiğinizi zannediyorum.

Peki muteks ve kritik bölge arasında tercih yapmak gerekirse hangisini tercih etmeliyiz. Bence performans açısından pek fark olmaz. Seçim noktanız şu olmalı. Eğer, tek bir işlemden değil de bir çok işlemden yani bir çok programdan oluşan bir gurubun kanalları ortak ve eş zamanlı kullanmasını düşünüyorsak kesinlikle muteks kullanmalıyız. Aksi durumda yani eş zamanlı çalışacak olan kanallar sadece tek bir işlemde bulunuyorlarsa o zaman seçim size kalmış. Hangisi rahatınıza gidiyorsa onu kullanabilirsiniz.

Şimdi farklı bir konuya geçiş yapalım. Hazırsanız ikinci sayfadan devem edelim.

Bu makale, ileri seviye Windows programcılığına geçiş kapısıdır. Bu makeledeki konuları öğrendikten sonra Win32 programcılığının en güçlü özelliklerini öğrenmiş olacaksınız.

Yanlız "ileri seviye" tabiri gözünüzü korkutmasın. Çünkü makeleyi bitirdiÄŸinizde thread kullanımının aslında ne kadar kolay olduÄŸunu göreceksiniz. Bununla birlikte bu makalede bu konu ile ilgili her ayrıntıyı anlatabilmemiz için yüzlerce sayfalık kitap yazmamız gereklidir. Bu yüzden burada iÅŸin mantığını kapıp, ihtiyacınız oldukça yardım dosyalarına müracaat etmeniz gerekebilir.

Kanallar hakkında hiç bir bilginiz olmayabilir. Bu makalede işin temelinden alacağız ve makaleyi bitirdiğinizde kendi programlarınıza kanal ekleyebilecek duruma geleceğinize inanıyorum.

Bu makale serisinde kanallar temelden anlatılmakla beraber, ileri seviye kanal kullanımı, VCL bileşenlerinde kanal kullanımı ve Muteksler de ana konularımız arasına girecektir.

GiriÅŸ

İlk başta bir kaç teorik bilgi ile başlamak istiyorum. Bu bilgilieri olabildiğince sıkmadan, kısa tutmaya çalışacağım.

Disk üzerindeki her bir dosya çalıştırıldığında artık windows için birer iÅŸlem(process) olurlar. Bir iÅŸlem Windows için fazla bir ÅŸey ifade etmez. Çünkü iÅŸlemler sadece hafızada belli bir bölgede var olmaktan sorumludur. Esas iÅŸlemi yapan kısım kanallardır(thread). Bir iÅŸlem en az bir adet kanala sahiptir. Win 3.1 gibi iÅŸletim sistemleri sadece bir adet kanala sahiptir. Ama Windows 95 ve üstü, Unix, OSX gibi iÅŸletim sistemleri birden fazla kanala sahip olabilirler.

Ä°ÅŸletim sistemi bir programı ya da bir DLL’i ilk baÅŸta iÅŸlem olarak hafızaya taşır. Bu esnada iÅŸlem eylemsiz olarak durur. Bu iÅŸleme ait kanallar ise bizim belirlediÄŸimiz ölçüde programın kodlarını çalıştırmaya baÅŸlar.

Her kanal, çalışma esnasında kendi eax, ebx, edx gibi register verilerini tutan bir yapıya sahiptir. Bu yapıya context(içerik) adı verilmektedir. Bu yapının Delphi’deki karşılığı TContext olup, Windows unitindedir. Bu record tipini incelediÄŸinizde bir çok register’ı barındırdığını göreceksiniz. EÄŸer buradaki Delphi ve Assembler ile ilgili makaleyi ve buradaki fonksiyon çağırım makenizmalarını okudu iseniz ÅŸimdi anlatacaklarımız size tanıdık gelecektir. Çünkü kanalların iÅŸleyiÅŸ mantığı fonksiyon çağırımlarına benzemektedir. Ama devam edebilmek için bunları okumak zorunda deÄŸilsiniz.

Her bir kanal sahip olduÄŸu önceliÄŸe göre iÅŸletim sistemi tarafından iÅŸleme alınacaktır. Bu iÅŸleme alış esnasında sahip olduÄŸu context‘deki register deÄŸerleri yüklenir. Esp, Ebp, Eip gibi registerlar da yüklendiÄŸinden, kanal önceden kaldığı yerden önceki stack deÄŸerlerine göre iÅŸlemine devam edecektir. Ve yine önceliÄŸine göre belli bir süre sonunda iÅŸletim sistemi bu kanalı durdurup register deÄŸerlerini context yapısında saklar. Daha sonra diÄŸer bir kanalın context verisini yükleyerek baÅŸka bir kanalı iÅŸlemeye geçer. Ve hakeza bu iÅŸlem tüm kanallar için devam edip gider. Ä°ÅŸletilme ve geçiÅŸ süreleri çok kısa olduÄŸundan, biz sanki aynı anda tüm kanallar iÅŸletiliyormuÅŸ gibi zannederiz. Halbuki bütün kanallar belli bir sıra ile çok kısa sürelerde iÅŸletilip diÄŸer bir kanala geçilmektedir. Yani her kanal aynı anda çalışmaz, biz öyle zannederiz. Tabi bu anlattıklarımız tek iÅŸlemci ve tek çekirdek için geçerlidir. Kanalların iÅŸletilme sürelerini ise kanalların önceliÄŸi belirlemektedir. Hangi kanal daha yüksek öncelikli ise o kanal daha fazla iÅŸletilme süresine sahip olur. EÄŸer kanal arkaplanda çalışma üzere ayarlanmış ise, diÄŸer kanallar iÅŸlemlerini tamamladıktan sonra ancak bu kanala sıra gelecektir. EÄŸer kanal çok yüksek önceliÄŸe sahip ise uzun bir süre bu kanal iÅŸleme devam edecek ve diÄŸer kanallara sıra gelmeyecektir.

Demek ki, aynı anda bir kaç iÅŸlem yapmak istiyorsak kafa patlatıp, parmak yormamıza gerek yokmuÅŸ. Çünkü iÅŸletim sistemi zaten sizin için bu sistemi kurmuÅŸtur. Sadece biraz vaktiniz ayırmanız ve kanallar nasıl oluÅŸturuluyor öğrenmeniz yeterlidir.

Kanal Oluşturma Yöntemleri

Aslında böyle bir başlıkla konuya giriş yapmak istemezdim. Ama kanal oluşturmayı öğrenmeden önce bir kaç şeyi açığa kavuşturmak istiyorum. Gerek forumlardan gerekse haber guruplarından kanallarla ilgili gelen sorulardan bir çoğu kanalların yanlış oluşturulması üzerine kaynaklanan yanlışlıklardan gelmektedir.

Normalde bir kanal windows ortamında CreateThread Windows API’si ile oluÅŸturulur. Fakat VCL bize TThread isminde bir sınıf da sunmuÅŸtur. Kullanım açısından ayırt edebileceÄŸiniz temel nokta ÅŸudur. EÄŸer kanalda yapacağınız iÅŸlemler VCL sınıflarını etkilemesi gerekiyorsa TThread sınıfını kanal oluÅŸturmak için kullanıyoruz. Yok eÄŸer VCL sınıflarını ilgilendiren bir iÅŸlem söz konusu deÄŸilse CreateThread API’sini kullanıyoruz. Bunun neden böyle olduÄŸunu ileride VCL ve Kanal kullanımı ile alakalı baÅŸlıkda vereceÄŸim. Muhtemelen Bölüm 2′de göreceksiniz. Bu yüzden biraz sabır.

BaÅŸlarken bu ÅŸekilde bir giriÅŸ yapmamın sebibi buradan kaynaklanıyor. Bir çok kiÅŸi belki de Windows API’lerine karşı bir soÄŸukluktan dolayı CreateThread ile uÄŸraÅŸmak istemiyor ve CreateThread ile ilgili kısımları gözü kapalı atlayabiliyor. Bu yüzden eksik kanal bilgisi ile ileride bir çok sorunla karşılaÅŸabiliyor. Ama ÅŸimdi göreceÄŸimiz gibi kanal oluÅŸturma iÅŸlemi sanıldığı kadar zor ve karmaşık bir iÅŸlem deÄŸil.

Bir Kanal Oluşturalım

Kanal oluşturma ile sorumlu Windows fonksiyonu CreateThread fonksiyonudur ve aşağıdaki gibi tanımlanmıştır:

function CreateThread(lpThreadAttributes: Pointer;
  dwStackSize: DWORD; lpStartAddress: TFNThreadStartRoutine;
  lpParameter: Pointer; dwCreationFlags: DWORD; var lpThreadId: DWORD): THandle; stdcall;

Bu fonksiyonun parametrelerinin kısaca açıklamasını verelim.

lpThreadAttributes: Kanalımıza atanacak olan bir çok güvenlik özelliğini belirtmemize yarar. Eğer nil girerseniz varsayılan güvenlik özellikleri kullanılacaktır. Win9x ve WinMe için bu değer nil olmalıdır. Bu konu ile alakalı daha fazla bilgi almak için sdk yardım dosyalarından SECURITY_ATTRIBUTES başlığına müracaat edebilirsiniz.

dwStackSize: Eğer kanal için özel bir stack büyüklüğü belirlemeyecekseniz bu değeri 0 olarak girmelisiniz. Böylelikle kanalın stack büyüklüğü program ile aynı olacaktır. Gerektiğinde stack boyutu otomatik olarak genişletilebilir.

lpStartAddress: Bu parametre esas iÅŸi gören parametredir. Çünkü kanal çalışmaya bu parametredeki fonksiyon iÅŸaretçisi ile beraber baÅŸlar. Burada tek yapmamız gereken fonksiyonun isminin önüne @ iÅŸareti vererek girmektir.

lpParameter: Bir önceki parametrede girdiÄŸimiz kanal fonksiyonuna parametre yollamak istiyorsanız, bu parametrelerin içinde bulunduÄŸu bir record’un adresini buraya girmelisiniz. Ayrıca record haricinde karakter veya sayı deÄŸelerini de parametre olarak yollayabiliriz.

dwCreationFlags: Bu parametre ile kanalın oluşturulur oluşturulmaz çalışıp çalışmayacağını belirliyoruz. Eğer bu parametreye CREATE_SUSPENDED girerseniz, kanal oluşturulur fakat kendisine çalışmaya başlaması için izin verilmez. Bu durumda siz ResumeThread fonksiyonu ile bu kanala çalışma talimatı vermedikçe kanal o şekilde çalışmadan duracaktır. Bir kez ResumeThread ile çalışmaya başladıktan sonra SuspendThread ile tekrar kanalı durdurabilirsiniz. Eğer bu parametreye 0 girerseniz, kanal oluşturulur oluşturulmaz çalışmak için sıraya girecektir.

lpThreadId: Bu parametreye kanal kimlik ID’si atanır. Buraya deÄŸeri olmayan bir Dword deÄŸiÅŸken giriyoruz. DeÄŸiÅŸken gireceÄŸiz çünkü "var" olarak tanımlanmış. Çünkü kanal oluÅŸturulduktan sonra Windows NT,2000 ve üstü iÅŸletim sistemlerinde kanalın ID’si bu deÄŸiÅŸkene yüklenir. Windows 9x/Me iÅŸletim sistemlerinde bu deÄŸer daima 0′dır.

Şimdi gelin bu fonksiyonu kullanarak bir kanal oluşturalım.

var
  KanalID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KanalID);

İşte hepsi bu! Tek yaptığımız sadece gerekli parametreleri kullanmak, gerisini duruma göre nil veya 0 yapmak. Bu fonskiyon çağrıldığında KanalFonksiyonu isimli fonksiyonumuz kanal içinde çalışmaya başlayacaktır.

Dilerseniz KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını şimdi yapacağımız örnek içinde verelim.

Basit Bir Örnek

Åžimdi oluÅŸturduÄŸumuz bu kanalın nasıl çalıştığını basit bir örnek ile görmeye çalışalım. Yeni bir uygulama oluÅŸturalım ve Form üzerine bir adet button ve bir adet label koyalım. Button’nun Caption özelliÄŸini "OluÅŸtur ve Çalıştır" olarak deÄŸiÅŸtirelim. Ve Button’nun OnClick olayına kanalımızı oluÅŸturan ÅŸu kodları girelim:

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KimlikID);
end;

Şimdi de kanalımızda esas işi yapan KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını girelim:

function KanalFonksiyonu(P: Pointer): Longint; stdcall;

...

implementation

...

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  i: Integer;
  Toplam: Int64;
begin
  Toplam := 0;
  for i := 0 to 1000000000 do
  begin
    Toplam := Toplam + i;
    Toplam := Toplam shl 4;
  end;
  Form1.Label1.Caption := 'Kanal işlemini tamamladı. Sonuç:' + IntToStr(Toplam);
end;

Bu fonksiyonda ekstra bir ÅŸey yapmıyoruz. Sadece bir for döngüsü var ve matematiksel bir iÅŸlem yapılıyor. For döngüsü bittiÄŸinde ise formdaki label’a bir sonuç yazdırıyoruz.

Bu for döngüsünü, ayrı bir kanalda değil de programın ana kanalında çalıştırmaya kalksaydık muhtemelen Application.ProcessMessages ve TTimer gibi çözümlere gidecektik. Bu durum da çok fazla miktarda performans düşüklüğüne sebep olacaktı. Ayrıca işlemlerimiz genelde buradaki gibi basit matematiksel işlemler olmadığından, programda çökmelere ve donmalara sebep olacaktık.

Bu programı çalıştıralım ama button’a basmayalım. EÄŸer açık deÄŸilse View menüsünden "Thread Status" penceresini ve "Event Log" penceresini açalım ve görebileceÄŸimiz bir köşeye yerleÅŸtirelim. EÄŸer BDS 2005 ve üstü kullanıyorsanız bu pencereler debug esnasında altta görünür biçimde hazır olacaklardır.

Ardından buttona bir kez basalım ve "Thread Status" penceresine yeni bir eleman eklendiğine dikkat edelim. Eğer buradaki eleman çok çabuk bir şekilde görünüp kayboldu ise işlemciniz benimkinden hızlı demektir . Bu yüzden for döngüsündeki limit değeri biraz artırıp tekrar çalıştıralım.

Button’a her tıkladığınızda "Thread Status" pencersinden de takip edebileceÄŸiniz gibi yeni bir kanal eklenecek. Tabi butona basma iÅŸini o kadar çok abartmayın. Her kanal oluÅŸturulduÄŸunda kendisine bir ID atanacak. ÖrneÄŸimizde bu deÄŸer KimlikID deÄŸiÅŸkeninde tutuluyor. "Thread Status" pencersinde ise ThreadID sütununda bu deÄŸeri görebiliriz. Her kanal iÅŸlemini bitirdiÄŸinde "Thread Status" pencersinden kaybolduÄŸunu göreceksiniz. Aynı ÅŸekilde "Event Log" pencersinde de kanal’ın ID’sine göre baÅŸlama ve bitiÅŸi ile ilgili mesajları görebilirsiniz.

Kanal çalışırken program üzerinde istediğiniz işleme devam edebilirsiniz. Formu taşıyabilir, boyutlandırabilir, başka bileşen ve nesneler var ise onları kullanabilirsiniz. Ve bunu yaparken bir yandan kanal(lar) da çalışmaktadır. Aynı kanal fonksiyonunu doğrudan çağırmaya kalktığımızda formumuza döngü bitene kadar müdahale edemeyecektik.

Gördüğünüz gibi bir kaç satır kod ile kanal oluşturuveriyoruz. Tek bilmemiz gereken kısım CreateThread fonksiyonunun parametreleri. Bunların çoğunu da kullanmadık. Ama makalenin ilerleyen kısımlarında bunları da yavaş yavaş kullanıma dahil edeceğiz. İşte bir tanesi geliyor.

Kanal Fonksiyonlarına Parametre Gönderimi

CreateThread fonksiyonunun parametrelerini açıklarken lpParameter‘den söz etmiÅŸtik ve bu parametre ile kanal fonksiyonuna istediÄŸimiz parametreyi gönderebileceÄŸimizi belirtmiÅŸtik. Åžimdi bunu nasıl yapacağımızı görelim.

Bunun için yukarıda yaptğımız örnekten faydalanacağız. İlk başta type bloğunda aşağıdaki record tanımlamasını yapalım.

  PKanalParametresi = ^TKanalParametresi;
  TKanalParametresi = record
    BirParametre: string;
  end;

Ardından kanal fonksiyonumuzu aşağıdaki gibi değiştirelim.

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  Parametreler: PKanalParametresi;
begin
  Parametreler := PKanalParametresi(P); //Parametremizi alalım.
  while True do
  begin
    Form1.Label1.Caption := Form1.Label1.Caption + Parametreler^.BirParametre;
    Sleep(1000); //İşlemcinin %99 çalışmasını istemiyiz değil mi....
  end;
  Dispose(Parametreler);
end;

En son olarak button’nun OnClick olayını da aÅŸağıdaki gibi olacak ÅŸekilde deÄŸiÅŸtirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
  Parametreler: PKanalParametresi;
begin
  New(Parametreler);
  Parametreler^.BirParametre := 'a';
  CreateThread(nil, 0, @KanalFonksiyonu, Parametreler, 0, KimlikID);
end;

Aslında çok fazla bir ÅŸey yapmadık(en azından siz kopyala yapıştır yaptınız:) ). Burada basit bir iÅŸaretçi kullanımını görüyoruz. Ve parametre olarak bir record’u kullandık. Record yerine baÅŸka veri tiplerini de kullanabilirdik. Ama genelde karşılaşılan sorunlar recordları parametre olarak yollamaktan gelmektedir.

En baÅŸta verdiÄŸimiz record tanımlamasına bakarsanız, PKanalParametresi isminde bu recordumuza iÅŸaretçi olan bir tip göreceksiniz. Parametremizi iÅŸaretçi olarak kullanacağımızdan bu tipe ihtiyacımız olacak. Ardından Button’nun OnClick olayına bakalım. Burada önceki örneÄŸe göre fazladan 2 satır ekledik. Ä°lk baÅŸta var bloÄŸunda Parametreler isminde bir record iÅŸaretçisi tanımladık. Ardından iÅŸaretçi hiç bir ÅŸey ifade etmediÄŸinden, iÅŸaretçiye ait bir recordun hafızada oluÅŸturulması için New rutinini kullandık. Devamında bu record’un deÄŸiÅŸkenlerinden birine bir string deÄŸer atadık. CreateThread fonksiyonu parametreyi iÅŸaretçi olarak istediÄŸinden buraya direk olarak Parametreler deÄŸiÅŸkenimizi girebiliriz. Çünkü bu deÄŸiÅŸken bir record iÅŸaretçsidir.

En son olarak yeni kanal fonksiyonumuza baktığımızda, iÅŸaretçi olarak gelen parametremizin nasıl kullanıldığını görüyoruz. Burada bizim için önemli olan kısım Dispose kısmıdır. Çünkü burada New ile oluÅŸturduÄŸumuz ve iÅŸaretçiye ait olan recordu hafızadan siliyoruz.

Record iÅŸaretçisi yerine normal record kullansa idik ve sonra da bunu parametre olarak geçirirken pointer olarak geçirse idik olmazmıydı. Olurdu… Üstelik New ve Dispose rutinlerini de kullanmak zorunda kalmazdık. Ama, bu durumda boÅŸ yere hafızda yer iÅŸgal edecektik. Çünkü parametre recordu sadece bir kerelik iÅŸimize yarayacak. Bu yüzden iÅŸimiz bitince Dispose ile hafızdan siliyoruz.

Bu örneğimizi de çalıştırıp deneyebilirsiniz. Ayrıca Görev Yöneticisi ile işlemciyi yüzde kaç kullandığını da görebilirsiniz. Tabi burada Sleep rutinini kullanmak yerine daha başka yapılabilecek şeyler var ama şimdilik kafa karıştırmamak için bunları sonraya bırakıyorum.

Sonuç

Bu bölümü burada noktalayalım. Gelecek bölümde kanalların nasıl birbirleri ile birlikte çalışabileceÄŸini göreceÄŸiz. Ayrıca Mutex’ler ve VCL ile kanal kullanımı da gelecek bölümde göreceÄŸimiz konular arasında olacak. Böylece kanallar konusunda hiç bir şüpheniz, korkunuz kalmayacağı gibi programlarınıza da profesyonellik katacaksınız.

Gelecek bölümde buluÅŸmak ümidi ile… Yorumlarınızı ve eleÅŸtirilerinizi bekliyorum. Yine her zaman ki gibi sorularınızı buradan yada Delphi Türkiye forumlarından iletebilirsiniz

Fatih Tolga Ata © 2007

Kaynaklar

• Windows SDK Yardım Dosyası
• Delphi 4 Unleashed, Charlie Calvert, Sams Pub., 1999