JQuery aracılığıyla bir formu ASP.NET sayfasına doğrudan POST veya GET ile gönderebilmek için Form Serialize işlemi gerçekleştirilir. Bu amaçla .serialize() veya .serializeArray() yordamları kullanılır.

Özellikle Internet Explorer ortamında bir formu serialize edip ASP.NET sayfasında okumaya çalıştığımızda Türkçe Karakter sorunu yaşanmaktadır. Örneğin “öçşğüİ” değeri Ã¶Ã§ÅŸÄŸÃ¼Ä şeklinde görünmektedir. Bu karakterlerin UTF-8 olarak gönderilmesi için aşağıdaki örnekte gösterildiği gibi “application/x-www-form-urlencoded; charset=utf-8″ şeklinde content teype belirmek gerekiyor.

var formValue=$("#aspnetForm").serializeNoViewState();

$.ajax({
	type: "POST",
	url: "OrnekSayfa.aspx?Prm=1",
	data: formValue,

	beforeSend: function (xhr) {
	    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded; charset=utf-8");
	},

	contentType: "application/x-www-form-urlencoded; charset=utf-8",
	dataType: "json", 

	success: function (msg, status) {
		alert(msg);
	},
	error: function (xhr, msg, e) {
	    alert("Hata Oluştu!\n" + xhr.responseText +"\n"+msg );
	},

	complete: function() {
		alert('İstek başarıyla gönderildi.');
	}
});

ASP.NET sayfasına POST işlemi yaptığımızda post edilen metin içerisinde “<>” gibi web safyaları için tehlike oluşturabilecek değerler gönderildiği zaman ASP.NET WP, “A potentially dangerous Request.Form value was detected from the client” hatasını fırlatır. Bu hatayı engellemek yani kullanıcının bu tür değerleri girmesine izin vermek için ASP.NET sayfasının tanımlama satırına validateRequest=”false” ibaresi yazılır. Aynı şekilde uygulamadaki tüm sayfalar için bu ayarın geçerli olması için Web.Config dosyasına aşağıdaki gibi ekleme yapılabilir.

<pages validateRequest="false" />

Cross-site scripting (XSS) attack riskini engellemek için ASP.NET tüm sürümlerinde request validation özelliği varsayılan olarak aktifdir. ASP.NET’in önceki sürümlerinde bu doğrulama işlemi sadece ASPX sayfaları için yapılmaktaydı. 4.0 sürümüyle birlikte doğrulama işlemi doğrudan BeginRequest aşamasında devreye alınacak şekilde düzenlendi. Böylece uygulamaya gelen tüm istekler için yani sadece ASPX sayfaları değil, Web Servisi çağırma, HTTP handler çalıştırma gibi tüm ASP.NET kaynaklarına istek gönderildiği zaman doğrulama işlemi devreye alınmış oldu.

Bazı durumlarda .NET Framework 4.0 altında eski sürüm ugyulamalarını çalıştırma durumumuz olabilir. Bu durumda hangi sürüm algoritmasının kullanacağını belirtmek için requestValidationMode niteliği kullanılır.

<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>

Bağıntı/İlişki Sınıfları (Association Classes)

Bağıntı sınıfı, iki nesne arasında kurulmuş bağıntı ile başka bir sınıfın ilişkilendirilmesidir. Bu yöntem ana nesneler arasındaki bağıntının kendisine yeni nitelikler kazandırmak için kullanılır. Örneğin öğrenci-ders bağıntısında öğrencinin kayıt tarihi, kayıt ücreti ve kredisi gibi nitelikler ancak öğrenci o derse kayıt olduktan sonra anlam kazanır. Bu nitelikleri bağıntının kendisine tanımlamak gerekir. Diyagram üzerinde bağıntı sınıfları bağıntıya kesik çizgi ile bağlanır.

Genelleştirme İlişkisi (Generalization)

Bir nesnenin bir diğerinin özel türü olduğunu göstermek için kullanılır. Diyagram üzerinde nesneler genelden özele doğru ağaç görünümünde yerleştirilir. Nesne yönelimli programlamadaki karşılığı kalıtım (inheritance) kavramıdır. Alt nesneler içi boş bir ok simgesiyle üst nesneye bağlanır. Aşağıdaki örnekte bir şirkete ait kişilerin genellemesi gösterilmiştir.

Bu gösterime göre “Müdür” nesnesi “Kişi” nesnesinin özel türüdür. Genelleştirme işleminin temelinde sınıflandırma işlemi yapılır. Alt nesneler farklı kriterlere göre gruplandırılabilir. Örneğin önceki gösterimde soldaki nesneler cinsiyetlerine göre, sağdaki nesneler ünvanlarına göre sınıflandırılmıştır.

Bağımlılık ilişkisi (Dependency)

İki nesne arasındaki anlamsal ilişkiyi modellemek için kullanılır. Bir sınıfın başka bir sınıfı kullanması durumunda ortaya çıkar. Bu ilişkide rol oynayan sınıflardan biri bağımlı diğeri bağımsız niteliktedir. Bağımlı nesnenin niteliklerinden biri bağımsız nesneyi referans olarak kullanır. Bu durumda bağımsız nesnedeki değişiklik bağımlı nesnenin anlamını değiştir. Bağımlılık ilişkisi, bağımlı sınıftan bağımsız sınıfa doğru kesikli çizgi ile ifade edilir.

Sağdaki üç nesne Alışveriş nesnesinin yordamlarında parametre olarak kullanılmaktadır. Yani Alışveriş nesnesi bu nesneleri kullanır. Bu yüzden bu nesnelerde yapılacak bir değişiklik Alışveriş nesnesinde değişikliğe neden olur.

Gerçekleştirim ilişkisi (Realization)

Arabirim yapılarından türemiş nesne yapısını modellemek için kullanılır. Bilindiği gibi arabirimler bir sınıfın temelde hangi üyelerden oluşacağını belirleyen şablonlardır. Bu şablonlar, oluşturulacak sınıflara öncülük eder ve içermeleri gereken üyelerin tanımlamaları için yol gösterir. Arabirimler nitelik içermez sadece fonksiyonlar içerir. OOP’deki karşılığı gerçekleştirmek olan gerçekleştirim ilişkisi kesikli bir çizgiye sahip iç boş bir üçgenle ifade edilir. Aşağıdaki örnekte Müşteri sınıfı IKişi arabirimini uygulamıştır.

Gerçekleştirim ilişkisi aşağıdaki şekilde de gösterilebilir.

Ardışıllık (Etkileşim) Diyagramları (Sequence Diagrams)

Sınıf diyagramı sistemin durağan yapısını gösterir. Fakat gerçek yaşamda olduğu gibi sistem üzerinde nesneler zamanla durumlarını değiştirir ve birbirleriyle etkileşime geçerler. Bu dinamik davranışları modellemek için ardışıllık (etkileşim) ve durum diyagramları kullanılır. Nesneler arasındaki etkileşim yordamlar üzerinden gerçekleşir. Ardışıllık diyagramları, nesneler arasında yordam çağırma işlemlerinin zaman çizgisindeki sıralı gösterimini modeller. Zaman çizgisi dikey eksen üzerinde yukarıdan aşağı, ilişkili nesneler ise yatay eksen üzerinde en üstte soldan sağa sıralanır. Bir nesneden diğer bir nesneye mesaj gönderileceği zaman mesaj yönüne uygun bir ok çizilir ve mesaj okun üzerine yazılır. Geri dönüş mesajı kesik çizgili ok ile ifade edilir.

Durum Şeması Diyagramları (Statechart Diagrams)

Nesnelerin sistem içerisinde meydana gelen olaylara karşı nasıl davranış sergilediğini modellemek için kullanılır. Nesneler olaylar aracılığıyla tetiklenerek durumlarını değiştirirler ve bu esnada tanımlı bazı işlemleri de çalıştırabilirler. Bir nesnenin durumları arasındaki geçiş transition simgesiyle ifade edilir. Nesnenin yaşamı sonlandığında, aldığı durum final state simgesiyle ifade edilir. Aşağıdaki diyagramda sipariş sürecinin durumu modellenmiştir.

Örnek: Bir e-ticaret uygulamasında sipariş

Bir e-ticaret projesinin önemli nesnelerinden birisi olan sipariş ve onunla ilgili nesneler bir sonraki sayfada verilen UML diyagramında olduğu gibi modellenebilir.
Verilen diyagram aşağıdaki gibi yorumlanabilir:

• Bu projede iki tür müşteri bulunmaktadır; genelleştirme (generalization). Müşteriler ya doğrudan İnternet’ten kendileri sipariş verebilir veya bir mağazaya gidip oradan sipariş verebilirler.
• Müşteri nesnesi için bir koşul/kısıt (constraint) tanımlanmıştır. Bu koşula göre, ancak ve ancak siteye üye girişi yapmış kişiler sipariş verebilir.
• Müşteri ile sipariş arasında ilişki vardır. Bir müşterinin 0 veya daha fazla sayıda siparişi olabilir (0..*). Fakat bir sipariş ancak bir tek müşteriye (1) bağlı olabilir. Bir siparişte en az 1 ürün vardır (1..*) ve bir sipariş en az bir ödeme şekline sahiptir (1..*).



• Sipariş ile “sipariş detay” arasında oluşum (composition) bağıntısı vardır. Sözkonusu sipariş silindiği zaman o siparişe ilişkin ayrıntı detay kayıtlar da silinir. “Sipariş detay” ile ürün arasında içerim (aggregation) bağıntısı vardır. Bu durumda sipariş detay kaydı silindiği zaman o kayıtla ilişkili ürün nesnesi silinmez.
• Bir müşterinin sistemde 0 (sıfır) veya daha fazla sayıda adresi tanımlı olabilir. Her siparişin bağlı olduğu iki adres vardır. Bu adreslerden biri fatura adresi diğeri teslimat adresi olarak kullanılır ve her sipariş için ancak 1 (bir) fatura adresi ve 1 (bir) teslimat adresi tanımlanabilir.

Bir yazılım projesinde herşeyden önce o proje ile ilgili yol haritası olan proje taslağı oluşturulmalıdır. Proje taslağı onun başarısıyla doğru orantılı olup projenin zaman ve iş gücü açısından verimli sonuçlanmasını sağlar. Bu yöntem aynı bir inşaat projesinde olduğu gibi bir yazılım projesinde de başarı faktörü olarak karşımıza çıkar. Proje/iş tasarlamanın ilk adımı proje içerisindeki aktif oyuncuların anlayabileceği standart bir modelleme yapmaktır. Bir mühendislik yaklaşımı olan modelleme, karmaşık bir sistemin şekil ve metinlerle basit bir dil ile ifade edilmesidir.

Yazılım mühendisliğinde modelleme için çeşitli çalışmalar yapılmış olsa da bunlardan en önemlisi ve geçerli olanı ilk olarak 1998 yılında OMG (Object Management Group) tarafından kabul gören UML 1.1 (The Unified Modeling Language / Birleşik Modelleme Dili) standardıdır. [Aytaç-2006]

UML, bir programlama dili olmayıp karmaşık yazılım projelerinin programlama dillerinden bağımsız, daha basit bir şekilde ifade eden görsel modelleme dilidir. Yazılım mühendisleri UML yöntemini geliştirme sürecinin ilk iki basamağı olan analiz/çözümleme ve tasarım süreçlerinde kullanırlar. UML, projedeki teknik ve teknik olmayan kişiler arasındaki iletişimi kolaylaştırır. UML aynı zamanda gerçek sistemin resmini gösterdiği için hem sistemin özellikleri ve eksikliklerini gösterir hem de bakım sürecini kolaylaştırır; yazılım projelerinin, özellikle nesneye yönelik programlama dili kullanılıyorsa, daha sağlıklı bir süreç içerisinde geliştirilmesine yardımcı olur. Ayrıca, projenin davranışını da açıkça gösterir.

Geniş bir kullanım alanına sahip olan UML yalnızca yazılım geliştirme alanında değil iş süreçleri, ağ yapıları ve veri sistemlerini modellemek için de kullanılır. Bu modelde standart işaret ve metinler kullanıldığı için ortaya çıkan tasarım, uzmanlığı ve dili farklı olsa da birçok kişi tarafından kolayca anlaşılabilir.

UML tasarımı, elemanlar ve bunların oluşturduğu diyagramlardan oluşur. Elemanlar, nesnelere ait özellikleri, işlevleri ve nesneler arasındaki yapısal ilişkiyi temsil eder. Diyagramlar ise, sistemin farklı süreçlerdeki yapısını ve davranışını temsil eder. UML tasarımında 9 temel diyagram kullanılır.

Bir sistem gereksinimlerinin modellenmesi kullanıcı senaryosu diyagramı ve etkinlik diyagramı aracılığıyla gerçekleştirilir.
Sistemin tanımı ve yüzeysel içeriği bileşen diyagramı ile nesne diyagramı aracılığıyla gerçekleştirilir.
Sistemin tasarımı ve ayrıntılı içeriği sınıf diyagramı, ardışıl (etkileşim) diyagramı, işbirliği diyagramı ve durum şeması diyagramı aracılığıyla gerçekleştirilir.
UML tasarımı için birçok araç bulunmaktadır; araç seçiminde dikkat edilmesi gereken unsur onun VS.NET ile bütünleşik çalışıyor olmasıdır; kod üretimine sahip olması ve mümkünse .NET Framework dillerine destek vermesidir. Ayrıca kullanıcı dostu ekranlara da sahip olması tercih nedeni olabilir. Bu amaçla MS Visio, Rational Rose, SmartDraw, Metamill veya Visual Paradigm araçları kullanılabilir. Kitabımızdaki UML tasarımları için “MS Visio” tercih edilmiştir. Aynı şekilde bu dillerdeki bir koda ait analiz ve tasarım modeli de oluşturulabilir. Ancak konumuz .NET olduğu için UML elementlerinin .NET Framework’teki hangi yapılara denk geldiğinin verilmesi yararlı olacaktır.

.NET Framework ve karşılık düşen UML elementleri:

İsim-uzayı (Namespace): İsim-uzayının UML tarafındaki karşılığı package elementidir.
Sınıf (Class): Sınıfın UML tarafındaki karşılığı class elementidir; new, internal gibi sınıfı yapıcıları UML tarafında desteklenmez.
Arabirim (Interface): Arabirimin UML tarafındaki karşılığı interface elementidir.
Numaralandırma türü (Enumerated type): Numaralandırma türünün UML karşılığı <<enum>> şablonunu (stereotype) kullanan data type elementidir. Stereotype ifadeleri mevcut UML modelini genişletmek amacıyla modele yeni özellik ve element eklemek için kullanılır.
Yapı (Struct): Yapının UML karşılığı <<struct>> şablonunu kullanan data type elementidir.
Özellik (Property) ve Yordam (Method): Özellik ve yordamların UML dilindeki karşılığı operation kavramıdır. Yordam parametreleri UML parameter kavramıyla karşılanır.
Delege/Temsilce (Delegate): Temsilcinin UML karşılığı <<delegate>> şablonunu kullanan data type elementidir.
Sabit (Constant) ve Değişken (Variable): Sabit ve değişkenlerin UML dilindeki karşılığı attribute kavramıdır.

Kullanıcı Senaryosu Diyagramları (Use Case Diagrams)

Yazılım geliştirme sürecinde az kullanılan bu diyagram/çizelge, sistem üzerindeki muhtemel kullanıcı senaryolarını modellemek için tercih edilir. Belirlenen senaryolarda sistemin ne yaptığı yüzeysel olarak aktarılır; sistemin amacını ve ayrıntılarını vermez. Bu modelde aktör olarak tanımlanan kullanıcı bir senaryoyu başlatır ve varsa oluşan sonucu başka bir kullanıcıya aktarır. Diyagram üzerinde senaryolar elips şeklinde çizilir. Kullanıcı ile senaryo arasındaki ilişki düz bir çizgiyle belirtilir. Bu modelde senaryolar arasında içerme (inclusion) ve genişleme (extension) olmak üzere iki tür ilişki kurulabilir. İçerme ilişkisi bir ana senaryonun bir alt senaryo içerdiğini belirtir. Söz konusu alt senaryo birden fazla senaryo tarafından kullanılır. Bu senaryolar arasında noktalı bir çizgi çizilir ve üzerine <<include>> (Visio’da <<uses>>) ifadesi yazılır. Genişleme ilişkisi mevcut senaryoya yeni bir senaryo eklemek için kullanılır. Bu ilişkiyi belirtmek için noktalı çizginin üzerinde <<extension>> ifadesi yazılır.

Kullanıcının sipariş oluşturması için öncelikle sisteme giriş yapması ve sözleşmeyi kabul etmesi gerekir. Müşteri siparişini iptal ettikten sonra sistemin log dosyasına not düşmesi de ek bir adım olarak eklenmiştir.
Sonuç olarak kullanıcı senaryosu (use case) diyagramı aracılığıyla bu modele bakan birisi sistemin ne yaptığının kabaca anlayabilir, görebilir.

Sınıf Diyagramları (Class Diagrams)

Projenin durağan yapısının modellenmesi için kullanılır. Nesne yönelimli programlama yaklaşımının temelini teşkil eden sınıflar (class) tıpkı gerçek yaşamda olduğu gibi modellenir; onlara ait özellikler ve davranışlar belirlenip diyagram üzerinde çizilir. UML dilinde sınıflar üç bölümden oluşan dikdörtgen şekliyle temsil edilir. Dikdörtgenin birinci bölümüne sınıfın adı, ikinci bölümünde sınıfa ait özellikler, üçüncü bölüme de sınıfın sahip olduğu işlevler yazılır. Her sınıfın mutlaka özelliği olmak zorunda değildir. İşlevler, sınıfın yeteneğini ifade eder. İşlevler tanımlanırken aldıklar veya geri döndürdükleri parametreler de girilir. Ayrıca sınıflar için ek notlar ve koşullar, kısıtlamalar da diyagram üzerinde tanımlanabilir. Aşağıdaki şekilde Kitap sınıfı ve ona ait karakter ve davranışlar gösterilmiştir.

Diyagram üzerinde sınıflar erişim belirleyicilerine göre işaretlenir. Örneğin özel (private) üyeler ‘-’, herkese açık (public) üyeler ‘+’, korumalı (protected) üyeler ‘#’ ile gösterilir.
Sınıf diyagramı üzerinde aynı zamanda varsa sınıflar arasındaki ilişkiyi de görüntüleyebiliriz. UML yaklaşımında sınıflar arasında genel olarak 4 tür ilişki kurulur:

• Bağıntı ilişkisi (Binary association) / İçerim (Aggregation), Oluşum (Composition)


• Genelleştirme ilişkisi (Generalization)


• Bağımlılık ilişkisi (Dependency)


• Gerçekleştirim ilişkisi (Realization)

Bağıntı İlişkisi (Binary Association).
Bir nesnenin başka bir nesneyle olan yapısal bağını gösterir. Bu bağ diyagram üzerinde düz bir çizgiyle gösterilir. İki sınıf arasında ilişki kurulduğunda ilişki alanının üzerinde sınıfların ilişkideki görevi, ilişkinin yönü, türü ve ilişkinin çokluğu da belirtilir. Sınıflar arasında “bire-sıfır”, “bire-bir”, “bire-çok” türünde ilişkiler kurulabilir. Bu ilişkinin tanımları daha önce işlediğimiz “Entity Relationship (ER) Modeling” konusunda verildi. UML diyagramlarında bağıntının yönü ‘►’ simgesiyle gösterilir; nesnelerin bağıntıdaki rolleri kendilerinin alt tarafında, ilişki çokluğu gösterilir. İlişkinin türü “1,* – sayı/çokluk” şeklinde belirtilir. Muhtemel ilişkileri temsil eden simgeler aşağıdaki tabloda gösterilmiştir:

Aşağıda verilen şekilde bağıntı ilişkisi örneklendirilmiştir:

Müşteri-sipariş ilişkisinde bağıntının yönü müşteri nesnesinden sipariş nesnesine doğru verilmiştir. Bu gösterimi soldan sağa doğru okuduğumuzda “her müşteri 0 ya da herhangi bir sayıda siparişe sahiptir (0..*)“, “her sipariş yalnızca bir müşteri tarafından verilebilir (1..1)” sonuçları çıkar.
Aşağıdaki gösterim ise “bir şirketin en az 1 işçisi vardır” ve “bir işçi 0 veya herhangi bir sayıda şirkette çalışmış olabilir” olarak yorumlanabilir.

Bu basit bağıntı türü dışında içerim (aggregation/shared) ve oluşum (compo-sition) olmak üzere iki özel bağıntı türü daha vardır.
İçerim bağıntı türü iki sınıf arasındaki “sahiptir” veya “içerir” ilişkilerini modeller. Diyagram üzerinde bu bağıntı, içeren (sahiplenen) sınıf tarafına yerleştirilen boş bir baklava dilimi simgesiyle gösterilir. “n:m” çokluk değerine sahiptir.
Oluşum/kompozisyon bağıntı türü, içerimin daha güçlü özel bir durumu olup parça-bütün ilişkisini modellemede kullanılır. “Parça” nitelikli nesne, “bütün” nitelikli nesneyle anlam kazanır. Bu bağıntı “bütün” sınıf tarafında yerleştirilen dolu bir baklava dilimi simgesiyle gösterilir. “1:n” çokluk değerine sahiptir.

Bu iki bağıntı türü yüzeysel olarak birbirine benzese de aralarında iki önemli fark bulunmaktadır.

• İçerim bağıntı türünde ikinci nesne birinci nesne dışında da sistem içinde kullanılabilir; yani aynı “parça” başka bir “bütün” tarafından da kullanılabilir. Örneğin bir öğrenci birden fazla öğretmenin öğrencisi olabilir. Oluşum bağıntı türünde ise ikinci nesne birinci nesneden bağımsız olarak kullanılamaz; yani bir “parça” aynı anda tek bir “bütün”e ait olabilir. Örneğin her motor tek bir otomobil tarafından kullanılabilir. Bu farktan dolayı bazı kaynaklarda içerim bağıntı bağımsız iyelik, oluşum bağıntı da bağımlı iyelik olarak isimlendirilir. Bununla birlikte her oluşum bağıntısı aynı zamanda bir içerim bağıntısıdır.


• Oluşum türünde “parça”nın yaşam süresi doğrudan bütünün yaşam süresine bağlıdır. “Bütün” nesnesi oluşturulmadan “parça” nesnesi oluşturulamaz ve “bütün” nesnesi silindiğinde “parça” nesneler de onunla birlikte silinir. Örneğin “ürün grup” nesnesi silindiğinde o grupla ilişkili ürünün yaşamı da sonlanır. İlişkisel veritabanı sisteminde aralarında oluşum bağıntısı tanımlanmış tablolarda ana kayıt silindiğinde ayrıntı tablosundan da ilgili kayıtların silinmesi gerekir.

  

  Son olarak, iki sınıf arasında birden fazla bağıntı çizilebilir veya bir sınıf kendisiyle ilişkilendirilebilir. Örneğin, şirket bileşeni için “işçi” diye bir nesne tanımladığımız bir müdür, hem işçi hem de yönetici rollerine sahiptir. Aşağıdaki örneği inceleyelim:



• Bir futbol takımının 11 oyuncusu vardır. Bunlardan birisi kaptandır. Yani oyuncular iki gruba ayrılmıştır. Bir grup normal oyuncu diğer grup kaptan olarak görev yapar.


• Bir oyuncu yalnızca bir takım için oynayabilir.


• Takımın kaptanı normal oyuncuları yönetir.

CETURK, 7 Şubat Cumartesi günü Microsoft Türkiye İstanbul Ofisi‘nde benim de Ado.Net 3.5 / Ado.Net Entity Framework konusuyla konuşmacı olarak katıldığım Microsoft Teknolojileri Etkinliği‘ni düzenledi. Benim açımdan iş ve sosyal hayat olarak yoğun bir haftaya denk gelmesi, hediye olarak verdiğimiz kitapları yetiştirmek için ciddi bir zaman harcamış olmam ve bunun sonucunda kendi sunum saatine yetişemememden dolayı etkin bir performans sergileyememiş olsam da benim için faydalı oldu. Konu katılımcı profiliyle ne kadar uyuştu veya onların ne kadar ilgisini çekti bilemiyorum ancak birkaç arkadaşın bu konularda ürün çıkaracak kadar çalışıyor olmaları beni daha da cesaretlendirdi. Tüm katılımcılara ve etkinliği düzenleyen CETURK ekibine de teşekkür ederim. Oturumumla ilgili sunumu aşağıda bulabilirsiniz.

Etkinlikle ilgili detayları http://www.ceturk.com/etkinlikkayit.asp?id=63 adresinde bulabilirsiniz.

Özel şekillendirilmiş kontrol olarak tanımlayacağımız bu kontroller, Control veya WebControl sınıflarından doğrudan türetilmiş olup, programcı tarafından belirlenmiş HTML içeriği render eder. WebControl sınıfı, Control sınıfından inherit edilmiş olup Control sınıfının özellikleriyle beraber kontrollerin renk, font gibi görsel yönlerinin yönetilmesini sağlayan özellikler sunar. Bu yöntemle geliştirilmiş kontrolün tag yapısını ve içeriğini genellikle programcı HTML ifadeler yazarak oluşturur. Bunu da daha önce kendisinden bahsettiğimiz HtmlTextWriter nesnesi aracılığıyla yapar. Bu bölümde daha detaylı göreceğimiz HtmlTextWriter sınıfı, kontrolleri render edip HTML çıktısını oluşturma, elementlere ait attribute tanımlamaları yapma, style attribute oluşturma gibi servisleri sağlar. HtmlTextWriter sınıfının bu amaçla kullanılan önemli metodları şunlardır;

AddAttribute(): RenderBeginTag() metodu tarafından açılmış HTML tagına attribute ekler.

AddStyleAttribute(): RenderBeginTag() metodu tarafından açılmış HTML tagına CSS attribute ekler.

RenderBeginTag(): Bir başlangıç HTML tagını render eder.

RenderEndTag(): Bir bitiş HTML tagını render eder.

Write(): Browserda görünmek üzere düz metin yazdırır.

WriteBreak(): <br/> HTML tagını yazdırır.

AddAttribute() veya AddStyleAttribute() methodlarını ihtiyacımız kadar birden fazla kullanabiliriz. Bu tür metodları, RenderBeginTag() metodundan önce çağırmaya dikkat etmeliyiz. RenderBeginTag() metodu çalıştığı zaman bütün attributeler açılış tagına eklenmiş olur.

HtmlTextWriter sınıfına ait bu metodlar parametre olarak string veya aşağıdaki enumeration türündeki değerleri alır;

HtmlTextWriterTag: En çok kullanılan HTML taglarının listesini içerir.

HtmlTextWriterAttribute: En çok kullanılan HTML attributelerinin listesini içerir.

HtmlTextWriterStyle: En çok kullanılan CSS attributelerinin listesini içerir.

Özel kontrol geliştirirken işlemlerin doğru zamanda gerçekleşmesi açısından taban aldığımızın sınıfın(Control veya WebControl) hangi metodlarını override edeceğimiz önem arzetmektedir. Control ve WebControl sınıfların ortak ve ayrık metodları bulunur. Yeri geldikçe bu metodlardan bahsedeceğiz. Şimdilik WebControl’ün başlangıç için bilmemiz gereken metodlarından bahsedelim;

RenderBeginTag(): Açılmış HTML tagını açılma aşamasında özel bir içerikle render etmek için kullanılır. Parametre olarak HtmlTextWriter türünde değer alır.

RenderEndTag(): Açılmış HTML tagını kapatılma aşamasında özel bir içerikle render etmek için kullanılır. Parametre olarak HtmlTextWriter türünde değer alır.

ApplyStyle(): Web kontrolüne style uygulamak için kullanılır. Parametre olarak System.Web.UI.WebControls.Style türünde değer alır.

CopyBaseAttributes() : Bir web server kontrolünün Style sınıfından türememiş olan property’lerini bu metodu çağıran kontrole kopyalamak için kullanılır. CopyBaseAttributes() metodu, WebControl türünde parametre alıp kaynak kontrolün AccessKey, Enabled, ToolTip, TabIndex ve Attributes property’lerini kopyalar.

Render(): HtmlTextWriter türünde değer alarak kontrolün istemci tarafındaki HTML element içeriğini oluşturur.

Bir ASP.NET sayfası çalıştırıldığı zaman, sayfa içerisindeki web kontrollerinin RenderControl() metodlarına HtmlTextWriter nesnesi gönderilerek çağrılır. RenderControl() metodu, kontrole ait protected modundaki Render() metoduna elçilik eder. Render() metodu, RenderBeginTag(), RenderContents() ve RenderEndTag() metodlarını uygular. Bu üç metod da daha önce parametre olarak RenderControl() metoduna gönderilmiş aynı HtmlTextWriter nesnesini kullanılır. Her metod, görevleri doğrultusunda oluşturduğukları HTML çıktıyı, HtmlTextWriter nesnesine ekler. Bu metodların tamamlanmasından sonra ASP.NET engine, kontrolden geri dönen HtmlTextWriter nesnesini handle eder ve ona göre browsera gönderilecek HTML çıktıya ekler. Custom kontrol geliştiriken bu metodların hepsi kullanılmak zorunda değildir. Sadece Render() veya RenderContents() metodlarıyla ilgili HTML çıktı oluşturulabilir.

Doğrudan Control sınıfından inherit edilmiş custom kontrollerde genellikle Render() metodu kullanılır. Aşağıdaki örnekte basit bir custom kontrol kodu gösterilmiştir. Bu kontrol, büyüklüğü ve rengi bizim tarafımızdan belirlenen bir başlık oluşturur.

[Baslik.vb]

Imports System.Web.UI 'Control,HtmlTextWriter

Namespace OrnekWebKontrol
    Public Class Baslik : Inherits Control
        Private _boyut As Integer
        Private _metin As String

        'Başlığın font büyüklüğü
        Public Property Boyut() As Integer
            Get
                Return _boyut
            End Get
            Set(ByVal value As Integer)
                _boyut = Value
            End Set
        End Property 'Boyut

        'Başlığın içeriği
        Public Property Metin() As String
            Get
                Return _metin
            End Get
            Set(ByVal value As String)
                _metin = Value
            End Set
        End Property 'Metin

        Protected Overrides Sub Render(ByVal writer As HtmlTextWriter)
            writer.Write("<font size=" & _boyut & ">")
            writer.Write(_metin)
            writer.Write("</font>")
            MyBase.Render(writer)
        End Sub
    End Class 'Baslik
End Namespace 'OrnekWebKontrol

[Baslik.cs]

using System.Web.UI; //Control,HtmlTextWriter

namespace OrnekWebKontrol
{
    public class Baslik : Control
    {
        private int _boyut;
        private string _metin;

        //Başlığın font büyüklüğü
        public int Boyut
        {
            get
            {
                return _boyut;
            }
            set
            {
                _boyut = value;
            }
        }//Boyut

        //Başlığın içeriği
        public string Metin
        {
            get
            {
                return _metin;
            }
            set
            {
                _metin = value;
            }
        }//Metin

        protected override void Render(HtmlTextWriter writer)
        {
            writer.Write("<font size=" + _boyut + ">");
            writer.Write(_metin);
            writer.Write("</font>");
            base.Render(writer);
        }
    }//Baslik
}//OrnekWebKontrol

<%@ Register Assembly="OrnekWebKontrol"
	Namespace="OrnekWebKontrol" TagPrefix="cc1" %>
. . . . .

    
    

Örneğimizi, konunun başında bahsettiğimiz metodları kullanarak ta oluşturabiliriz. Baslik dosyasına ZeminRenk isimli bir property ekleyip Render metodunu aşağıdaki gibi düzenleyelim.

[Baslik.vb]

Public Class Baslik : Inherits Control
        . . .
        Private _zeminRenk As String

        'Fontun zemin rengi
        Public Property ZeminRenk() As String
            Get
                Return _zeminRenk
            End Get
            Set(ByVal value As String)
                _zeminRenk = Value
            End Set
        End Property 'ZeminRenk

        Protected Overrides Sub Render(ByVal writer As HtmlTextWriter)
            writer.AddAttribute("size", _boyut.ToString())
            writer.AddStyleAttribute("background-color", ZeminRenk)
            writer.RenderBeginTag("font")
            writer.Write(_metin)
            writer.RenderEndTag()
        End Sub 'Render
    End Class 'Baslik

[Baslik.cs]

public class Baslik : Control
{
    . . .
    string _zeminRenk;

    //Fontun zemin rengi
    public string ZeminRenk
    {
        get
        {
            return _zeminRenk;
        }
        set
        {
            _zeminRenk = value;
        }
    }//ZeminRenk

    protected override void Render(HtmlTextWriter writer)
    {
        writer.AddAttribute("size", _boyut.ToString());
        writer.AddStyleAttribute("background-color", ZeminRenk);
        writer.RenderBeginTag("font");
        writer.Write(_metin);
        writer.RenderEndTag();
    }//Render
}//Baslik

Kontrolü, bu haliyle tasarım anında sayfanın üzerine eklediğimizde küçük bir nokta olarak görülecektir. Property’lerini set etmeden mouse ile onu seçmek pek kolay olmayacaktır. Bunu aşmak için _metin değişkenine default bir değer verilebilir.

Private _metin As String = “Başlık giriniz!”
private string _metin=”Başlık giriniz!”;

Böylece kontrol, sayfanın üzerine taşındığında Metin property’si “Başlık giriniz!” olarak set edilmiş olur.

PÜF
TextBox gibi bazı kontrolleri, form elementi içerisinde kullakmak zorundayız. Eğer bu kontrolleri, form elementi dışında tanımlarsak “…must be placed inside a form tag with runat=server” hata mesajıyla karşılaşırız. Bu şekilde geliştirdiğimiz kontrollerin, “runat=server” özellikteki form elementinin içerisinde render edilmesini zorunlu kılmak için Page.VerifyRenderingInServerForm() metodu kullanılır. Custom kontrol, bu metoda parametre olarak geçilir. Bu işlemin, AddAttributesToRender() veya Render()/RenderContent() metodlarında yapılması tavsiye edilir.

Protected Overrides Sub AddAttributesToRender(ByVal writer As HtmlTextWriter)
    Dim page As Page = Me.Page
    If (Not page Is Nothing) Then
        page.VerifyRenderingInServerForm(Me)
    End If
    . . .
End Sub

protected override void AddAttributesToRender(HtmlTextWriter writer)
{
    Page page = this.Page;
    if (page != null)
    {
        page.VerifyRenderingInServerForm(this);
    }
    . . .
}

Önceki bölümde özel web kontrol geliştirmeyle ilgili giriş yapmıştık. Bu bölümle birlikte kontrol geliştirme örneklerine geçeceğiz. İlk örnek olarak Inherited Control türündeki kontrolleri işleyeceğiz.

Inherited Control
.NET Framework ile birlikte gelen ve System.Web.UI.WebControls altında bulunan bir kontrolü taban alarak geliştirilen kontrollerdir. Bunu yapmamızın nedeni var olan kontrolü özelleştirmek veya ona yeni özellikler kazandırmaktır. Bu yönteme örnek olarak web sayfalarında kullanılan “hover button” kontrolünü hazırlayacağız.

Visual Studio içinde ismi OrnekWebKontrol olacak şekilde yeni bir Class Library projesi oluşturalım. Kendisinin oluşturduğu Class1 (Modul1 VB.NET) dosyasını silip yerine projeyi sağ tıklayıp “Add » New Item” bölümünden ismi HoverButton olan bir Class dosyası ekleyelim. Bu classı ImageButton’dan inherit edilecek şekilde düzenleyelim. HoverButton, mouse üzerine gelince zemin resmi veya rengi değişen butondur. Dolayısıyla burada kontrole ait tagın içeriğini oluşturmaktan ziyade (ki bu içerik, ImageButton’dan gelecek) oluşan elemente nitelik ekleyeceğiz. Bunun için override edilecek en uygun metod, AddAttributesToRender() metodudur. System.Web.UI.WebControls.WebControl üyesi olan bu metod, render edilmiş HTML elementine attribute ekleme aşamasını temsil eder. AddAttributesToRender() metodu, parametre olarak System.Web.UI.HtmlTextWriter türünde nesne alır. Bu bölümde yoğun kullanacağımız HtmlTextWriter nesnesi, ASP.NET server kontrollerinin istemciye gönderilecek içeriğine markup karakteri(</,/>,<,> vb.) veya herhangi bir metin eklemek için kullanılır. Bu amaçla çoğu overload edilmiş geniş bir metod listesine sahiptir. Örneğin kontrole attribute eklemek için, AddAttribute() metodu kullanılır veya doğrudan stream üzerine bir metin eklemek için nesnenin yapıcı yordamları kullanılır. Bu metodları daha sonra ele alacağız.

Projeye, “System.Web” kütüphanesini referans olarak eklemeyi unutmayalım. Özel bileşen geliştirirken çoğu System.ComponentModel kütüphanesinde bulunan tasarıma dayalı attributeler kullanılır. Bunları detaylı göreceğiz ama bu örnekte editörün “Properties” penceresinde bölümlendirme yapmak için Category isimli niteliği kullanacağız.

[HoverButton.vb]

[HoverButton.vb]
Imports System.Web.UI 'HtmlTextWriter
Imports System.Web.UI.WebControls 'ImageButton
Imports System.ComponentModel 'Category niteliği

Namespace OrnekWebKontrol

'ImageButton'dan türetilsin
Public Class HoverButton : Inherits ImageButton
    'Butonun üzerine gelince çıkacak resim için değişken tanımlıyoruz.
    Private _hoverResim As String = ""

    'Bu yerel değişkenlerin Properties penceresinden ayarlanması için property tanımlayalım. Propertynin başında kullanılan Category niteliği bu propertynin görüneceği grubu tanımlar.
    <Category("Hover Resmi")> _
    Public Property HoverResim() As String
        Get
            Return Me._hoverResim
        End Get
        Set(ByVal value As String)
            Me._hoverResim = value
        End Set
    End Property

    Protected Overrides Sub AddAttributesToRender(ByVal writer As HtmlTextWriter)
        'Eğer kullanıcı HoverResim propertysine değer girmişse.
        If _hoverResim <> "" Then
            'JavaScript ile butonun üzerine gelindiğinde(onMouseOver) veya geri çekildiğinde(onMouseOut) butonun resmini değiştireceğiz.
            Me.Attributes.Add("onMouseOver", "this.src='" & _hoverResim & "'")
            Me.Attributes.Add("onMouseOut", "this.src='" & MyBase.ImageUrl & "'")
        End If
        MyBase.AddAttributesToRender(writer)
    End Sub
End Class

End Namespace

[HoverButton.cs]

using System.Web.UI; //HtmlTextWriter
using System.Web.UI.WebControls; //ImageButton
using System.ComponentModel; //Category niteliği

namespace OrnekWebKontrol
{
//ImageButton'dan türetilsin
public class HoverButton : ImageButton
{
    //Butonun üzerine gelince çıkacak resim için değişken tanımlıyoruz.
    private string _hoverResim = "";

    /*
     Bu yerel değişkenlerin Properties penceresinden ayarlanması için property tanımlayalım. Propertynin başında kullanılan Category niteliği bu propertynin görüneceği grubu tanımlar.
     */
    [Category("Hover Resmi")]
    public string HoverResim
    {
        get
        {
            return this._hoverResim;
        }
        set
        {
            this._hoverResim = value;
        }
    }

    protected override void AddAttributesToRender(HtmlTextWriter writer)
    {
        //Eğer kullanıcı HoverResim property'sine değer girmişse.
        if (_hoverResim != "")
        {
            //JavaScript ile butonun üzerine gelindiğinde(onMouseOver) veya geri çekildiğinde(onMouseOut) butonun resmini değiştireceğiz.
            writer.AddAttribute("onMouseOver", "this.src='" + _hoverResim + "'");
            writer.AddAttribute("onMouseOut", "this.src='" + base.ImageUrl + "'");
        }
        base.AddAttributesToRender(writer);
    }//AddAttributesToRender

}//HoverButton

}//OrnekWebKontrol

Böylece basit kişisel bir kontrol geliştirmiş olduk. Konuya detaylı devam etmeden önce kontrolleri, uygulamalarda nasıl kullanacağımızı öğrenmek için deployment konusundan bahsetmek faydalı olacaktır.

Custom Kontrol’ün deploy edilmesi

Geliştirdiğimiz custom kontrolleri web uygulamalarında kullanmak için kontrolü, uygulamaya referans olarak eklememiz gerekir. Eğer web projesi, custom kontrol projesiyle aynı solution içerisinde bulunuyorsa VS.NET 2005, custom kontrolü, otomatik olarak Toolbox’a ekler. Bu yöntem özellikle ayrıntılı kontrollerde bazen sorunlar çıkarsa da custom kontrolümüzü test etmek için en pratik yöntemdir. Bir custom kontrolü, deploy etmek için .dll dosyasının uygulamanın BIN klasörüne veya sunucunun GAC klasörüne kopyalayıp. Kontrolün Assembly’sini kullanılacak uygulamaya register etmeliyiz.

VS.NET 2005′te eğer aynı Solution içinde bir web projesi oluşturursak, projenin Toolbox’ında otomatik olarak HoverButton görünecektir. Başka bir Solution içindeki web projesinde bu kontrolü kullanmak için Toolbox’ı sağ tıklayıp “Choose Items” menüsünü kullanarak açılan pencerede “.NET Framework Components” sekmesinde “Browse” butonu kullanılır.

Kontrolü, aspx sayfasında kullanılmak üzere sayfanın üzerine taşıdığımızda kontrolün .dll dosyası, uygulamanın BIN klasörüne kopyalanır ve HTML tarafında aşağıdaki gibi tag tanımlama satırları eklenir.

<%@ Register Assembly="OrnekWebKontrol" Namespace="OrnekWebKontrol" TagPrefix="cc1" %>
. . . . .

    

VB.NET’te aşağıdaki gibi olur.

<%@ Register Assembly="OrnekWebKontrol"
Namespace="OrnekWebKontrol.OrnekWebKontrol" TagPrefix="cc1" %>
. . . . .

    

VB.NET’e özel olarak;
Namespace değerinde geçen OrnekWebKontrol ifadesinden birinci Assembly adı(Root Namespace) diğeri de içinde classı yazdığımız namespace’dir. Sadece birini yazmak için ya classı namespace’siz yazarız ya da projenin property’sinden Application sekmesinde “Root namespace” alanını boş geçeriz. Fakat “bir kontrolün namespace alanı boş olmamalı” kuralından dolayı custom kontrol uygulamalarında iki seçeneği de uygulayamayız.

Sayfaya eklenmiş ilk satır, kontrolün register işlemiyle ilgilidir. Bir kontrolü, sayfamızda kullanmak için o kontrolü öncelikle projeye register etmeliyiz. Yani projeyi, bu kontrol hakkında bilgilendirmemiz gerekir. Görüldüğü gibi @ Register belirtecinde kullanılacak kontrolün register edilmesi sağlanmıştır. Bu satırda kontrolün assembly bilgileri ve TagPrefix’i belirtilmiştir. Kontrolleri, kullanılacak her sayfada @ Register belirtecinde kayıt ettirmek zorundayız. Bu da zahmetli bir iş olduğu için buna alternatif olarak Web.Config kullanılabilir. Bir custom kontrolü, aşağıdaki yazımda gösterildiği gibi Web.Config dosyasında register edebiliriz.

[Web.Config]

Custom kontrole ait Assembly, kullanıldığı projenin BIN klasöründe bulunmalıdır. Eğer custom kontrol, web server üzerinde bulunan tüm web uygulamaları tarafından erişilecekse, GAC’a eklememiz daha mantıklı olur.

Eğer custom kontrol, web uygulamasıyla aynı solution içerisinde değilse, kontrolün .dll dosyasını sürükle-bırak işlemiyle VS.NET’in Toolbox bölümüne taşıyarak ta kontrolü kullanabiliriz.

Kontrolün ImageUrl property’sine örnek bir resim yolu girip sayfayı kaydedelim. Sayfayı bu şekilde çağırdığımızda istemci tarafında generate edilecek HTML elementi aşağıdaki gibi olur.

Görüldüğü gibi sadece ImageUrl property’sini set ettiğimiz için onMouseOver ve onMouseOut nitelikleri boş tanımlandı. Dolayısıyla HoverButton kontrolü, kullanıcı HoverResim propertysine değer girildiği zaman anlamlı olacaktır yoksa normal bir ImageButton’dan bir farkı olmayacaktır. Eğer HoverResim property’sini set edersek çıktığı aşağıdaki gibi oluşur.

Aynı işlemi PreRender() veya Render() metodlarında da yapabilirdik. Render() metodu, Web controlün, asıl render edildiği metoddur. Genellikle türetilmiş kontrollerde kontrol öncesi veya sonrası özel bir metin eklemek için kullanılır. Örneğin HoverButton kontrolünün bizim tarafımızdan yazıldığını HTML comment olarak istemci tarafında gönderelim. Class içinde Render() metodunu da override ederek aşağıdaki ifadeleri ekleyelim.

Public Class HoverButton : Inherits ImageButton
    . . .
    Protected Overrides Sub Render(ByVal writer As System.Web.UI.HtmlTextWriter)
        writer.Write("")
        MyBase.Render(writer)
        writer.Write("")
    End Sub
End Class

public class HoverButton : ImageButton
{
    . . .
    protected override void Render(HtmlTextWriter writer)
    {
        writer.Write("");
        base.Render(writer);
        writer.Write("");
    }
}

Bu eklemeden sonra, HoverButton, istemci tarafında aşağıdaki gibi görünecektir.

Component kavramı, yazılımın en küçük yapı birimini temsil eder. Bu kavram, 80′lı yılların sonunda uygulama geliştirme sürecinde uygulamayı bileşenlere ayırma ve gerektiğinde bu bileşenleri daha sonra yeniden yazılmaksızın diğer uygulamalarda kullanma ihtiyacından doğmuştur. Bunun sonucunda bileşen tabanlı yazılım geliştirme mimarisi ortaya çıkmıştır. Bu mimariyi desteklemek amacıyla Microsoft tarafında ActiveX, COM, Java tarafında Applet gibi teknolojiler piyasaya sürülmüştür. Bu makalede bileşenlerin nasıl hazırlanacağı ve dağıtılacağını işleyeceğiz.

Yüzeysel bir tanım yapacak olursa, Component, herhangi bir user arabirimi olmayan, tasarım ortamını desteklemeyen ve başka nesnelerle etkileşimli olabilen bileşenlerdir. Control ise tasarım ortamıyla etkileşimli olan bileşenlerdir. .NET terminolojisinde Component, System.ComponentModel.IComponent arabiriminden türemiş olup desing-time nitelikleri olarak tanımlanan özel nitelikleri destekleyen yapılardır. Örneğin Timer bileşeni bir componenttir. Control ise Asp.Net TextBox gibi yine bir component türü olup user-interface yeteneğine sahip bileşenlerdir. Bu tanımlar sonucunda bütün kontroller, birer componenttir ama tersi doğru değildir diyebiliriz.

.NET Framework, client-side Windows Form Control (System.Windows.Forms.Control) ve ASP.NET Server Control (System.Web.UI.Control) olmak üzere iki tür kontrol kümesi sunar. .NET Framework’teki bütün kontroller dolaylı veya dolaysız bu iki kütüphaneden üretilmiştir.

ASP.NET Framework’ün en güçlü özelliklerinden biri de custom kontrol ve component geliştirmeye destek vermesidir. Sunduğu kütüphaneler aracılığıyla programcılar, kalabalık kodlar, detaylar arasında boğulmaktan kurtulmuştur. Kontrol geliştirmeyi kolaylaştırdığı gibi tasarım veya çalışma esnasında onları daha yetenekli kılmak ve toolboxa taşıyarak uygulamalarında bu kontrolleri kullanacak programcıların işlerini kolaylaştırmak için çeşitli ek bileşenler sunmaktadır. Bu bölümde ASP.NET Framework ortamında kendimize ait kontrolleri nasıl geliştireceğimizi veya varolan kontrolleri nasıl yönetebileceğimizi işleyeceğiz.

Özel bir web kontrolü geliştirmek için aşağıdaki sınıf türlerinden biri referans alınır;

• System.Web.UI.Control class

• System.Web.UI.WebControls.WebControl class
• System.Web.UI.WebControls.CompositeControl class
• System.Web.UI.HtmlControls.HtmlControl class
• Var olan Asp.NET veya HTML server control

Asp.NET platformunda bütün kontroller, doğrudan veya dolaylı olarak System.Web.UI.Control sınıfını taban alır.

Bir custom server kontrol geliştirirken ya var olan bir kontrolden ya da Control, WebControl, CompositeControl veya HtmlControl sınıflarından inherit edilir.

• Control sınıfı, tüm web kontrollerinin taban sınıfıdır. Kontrollerdeki standart üyeleri içerir. System.ComponentModel.IComponent arayüzünden inherit edilmiştir. Her iki kontrol türünün de, “sürükle bırak” özelliğini desteklemesi veya VS.NET içindeki properties penceresiyle etkileşimli çalışması Control sınıfından gelen bir özelliktir.

• WebControl sınıfı ise web controllerinin stil, renk ve font ayarları gibi görsel niteliklerini içerir. Aspx sayfalarında kullandığımız ve “<asp:…” önekle başlayan temel kontroller bu sınıftan türemişlerdir.
• CompositeControl sınıfı, .NET 2.0 ile birlikte gelmiş yeni bir sınıf olup, birden fazla kontrol(child control) içeren bileşik kontrol geliştirmek için kullanılır.
• HtmlControl sınıfı, HTML server kontrolleri için ortak olan metod, property ve eventleri kapsar.
• TemplateControl sınıfı, data-bound(GridView,DataList . . .), page control(Asp.NET sayfaları) ve templated kontrol gibi zengin kontrollerin taban sınıfıdır. Ayrınca Microsoft’un user control olarak isimlendirdiği ve bir çok .aspx sayfası tarafından ortak kullanılan kontroller de bu classtan türemiştir(.ascx dosyaları). Bu kontrolleri ASP’deki include dosyaları gibi düşünebiliriz.

Daha önceden var olan bir kontrolü taban alarak gerçekleştirilen kontrollere Inherited Control denilir. Doğrudan Control veya WebControl sınıflarından türemiş kontrollere Custom Rendered Control denilir. CompositeControl sınıfından türetilmiş kontrollere Composite Control denilir. TemplateControl sınıfından türemiş kontrollere de Templated Control denilir.

Eğer bir user interface(UI) veya başka görsel bir element geliştirilecekse bunun için WebControl veya bundan türetilmiş sınıfların kullanılması tavsiye edilir. Eğer HTML hidden veya meta tag gibi görsel olmayan(non-visual elements) basit bir element geliştirilecekse Control sınıfının taban alınması daha doğru olur.

Web tabanlı özel kontrol geliştirirken request-response sürecindeki yol haritasını, Asp.NET yaşam döngüsünü bilmek gerekir. Asp.NET’in sayfa yaşam döngüsünde her request işleminde page nesnesi ve içindeki kontroller yeniden oluşturulur ve işlem sonucunda yok edilir. Bilindiği gibi bu oluşma-yok olma sürecinde bazı evre ve olaylar gerçekleşir. Bu evre ve olaylar, kontrollerin de yaşam döngüsüyle ilintili olduğu için konunun detaylarına girmeden önce Asp.NET yaşam döngüsünü hatırlayacak kadar burada özetlememiz faydalı olacaktır. Aşağıdaki tabloda sayfa ve kontrol bazlı yaşanan evreler gösterilmiştir.

Döngünün bu evrelerinde zamanı geldikçe ilgili event ve metodlar otomatik olarak tetiklenir. Bunları da şu şekilde özetleyebiliriz;
1.Page_PreInit
IsPostBack property’si okunup sayfanın ilk defa process edilip edilmediği öğrenilebilir. Dinamik kontrollerin oluşturulması, master page‘in programatik olarak uygulanması, theme propertysinin dinamik olarak set edilmesi bu metod içinde yapılır. Ayrıca bu metod içinde profile property’si okunabilir veya set edilebilir.
2.Page.Init + Control.Init
Döngünün ilk aşaması olan Initialization evresinde sayfaya ait control tree, tanımlı kontrollerle şekillenir ve önce page nesnesine ait Init eventi daha sonra her kontrolün ayrı Init eventi tetiklenir. Viewstate bilgisi henüz yüklenmemiştir.
3.Page.LoadViewState
Initialization aşamasından sonra ASP.NET, sayfanın Viewstate’ini yükler. Viewstate, sayfanın sunucuda en son process edilmiş durumunu içerir.
4.Page.ProcessPostData
Request ile birlikte gelmiş Postback data okunur ve ilgili kontrollere yüklenir
5.Page.Load + Control.Load
Sayfa üzerindeki kontroller, tümüyle yüklendikten sonra Load eventleri tetiklenir. Bu metoda, genellikle sayfa ilk defa çağrıldığı(Postback edilmediği) zaman yapılacak data binding işlemleri yazılır.
6.”Change” Events
Kontrollerin yeni değerleri(Postback) ile orijinal değerleri(Viewstate) karşılaştırılır ve durumu değişmiş kontrollerin ilgili eventleri tetiklenir.(TextChanged, SelectedIndexChanged …)
7.Validate
Sayfa üzerindeki validatorlerin server side eventleri tetiklenir. Böylece doğrulama işlemi sadece istemci tarafına bırakılmamış olur.
8.”Postback” Events
Postback işlemine neden olmuş kontrollerin eventleri çalışır. Örneğin bir buton tıklandığı zaman yapılacak işlemleri bu aşamada Button.Click, Button.Command gibi metodlarda bildiririz.
9.Page.PreRender + Control.PreRender
Sayfa render edilmeden ve Viewstate kayıt edilmeden önce yapılacak işlemler bu metodlarda yazılabilir. Özellikle kontroller üzerinde yapılacak son değişiklikler bu aşamada yapılır.
10.Page.SaveViewState
Kontrollerin yeni değerleri ve sayfanın durumu sunucuya yapılacak bir sonraki dönüşte hatırlansın diye Viewstate nesnesine kayıt edilir.
11.Page.Render
12.Page_Unload
Temizlik işlemlerinin yapıldığı bu evrede sayfa istemciye gönderilmiştir. Bu metodu açık kalmış dosya ve database bağlantıları kapatmak veya request-response ile ilgili loglama yapmak gibi işlemler için kullanılabilir.

Microsoft firması .NET Framework 3.0 ile birlikte ADO.NET’in yeni bir versiyonunu yayınlamadı. .NET Framework 3.5 ile birlikte yeni eklentiler kazandırılmış ADO.NET 3.5 sürümü yayınlandı.
Microsoft, ADO.NET 3.5 sürümleriyle birlikte veritabanı uygulama mimarisinde büyük kolaylık sağlayan Object Relational Mapping (O/R Mapping) yöntemini destekleyecek önemli adımlar attı. Bu amaçla ADO.NET Entity Framework aracı geliştirildi. Konunun ayrıntılarına geçmeden önce bu kavramları tanımlayalım ve neden yeni bir yaklaşıma ihtiyaç duyulduğunu açıklayalım.

Günümüzde özellikle veritabanına dayalı uygulamalar, katmanlı mimari (multi-tier architecture) üzerine kurulur. Bu konsept dahilinde uygulamalar, veri (data), iş (business logic) ve sunum (presentation) olmak üç temel katmandan oluşur. Tasarım sürecinde ilk sırada bulunan veri katmanı oluşturulurken çeşitli veri modelleri kullanılır. “Verileri mantıksal düzeyde düzenlemek için kullanılan kavramlar, yapılar ve işlemler bütününe veri modeli denir.”
70′lı yıllardan bu yana Veritabanı Yönetim Sistemleri’nin (Database Management System – DBMS [VTYS]) değişmesiyle birlikte çeşitli veri modelleri geliştirildi:

• Sıradüzensel veri modeli (Hierarchical data model)
• Ağ veri modeli (Network data model)
• İlişkisel veri modeli (Relational data model)
• Nesneye yönelik veri modeli (Object oriented data model)

Her VTYS’nin kendine özgü veri modeli bulunur. Veri modeli kullanılarak veritabanının kavramsal ve dış şemaları oluşturulur. Burada bu modellerle ilgili kavramları tanımlayacağız ve VTYS’den bağımsız tasarım yapmamızı sağlayan ER modelini ayrıntılı ele elacağız.

Entity Relationship (ER) Modeling

Günümüzde bir veritabanı uygulamasının başarılı olmasını sağlayacak ilk parametre, iyi bir veritabanı tasarımına sahip olmasıdır. Bir uygulama geliştirileceği zaman öncelikle bu uygulamanın ne tür bir uygulama olduğu ve ne tür verileri içereceği belirlenir. Veritabanı tasarımı, bu soruların yanıtları doğrultusunda şekillenir. İlişkisel veritabanı sistemlerinde veritabanı tasarımının ilk adımı veri modellemedir.
Veri modelleme, veritabanı verilerinin ve bunların arasındaki ilişkinin organizasyon içindeki herkesin rahatlıkla anlayabileceği metin ve şekillerle ifade edilmesidir. Bilindiği gibi organizasyon içindeki kullanıcı, tasarımcı ve programcı gibi teknik veya teknik olmayan kişilerin veriye bakış açıları ve veriyi tanımlamaları farklılık arzeder. Hazırlanacak olan veritabanı tasarımında bu kişilerin hepsinin rolü olduğu için bu kişiler arasında ortak bir dil oluşturmak gerekir. Bu dilin temeli hiç şüphesiz gerçek dünya varlıklarıdır. Veritabanını kullanacak olan kullanıcı, tasarlayacak olan tasarımcı ve kodlayacak programcı ihtiyacını ancak gerçek varlıklar (nesneler) üzerinden daha kolay anlatabilir. Fakat gerçek dünyada varlıklar daha karmaşık özellik ve yeteneklere sahip olduğu için bu varlıklar üzerinden ifade edilmiş yapıyı, veri modellemesi aracılığıyla daha anlaşılır hale getirmek gerekir. Buradaki amaç, organizasyon içindeki herkesin gördüğü zaman kolaylıkla anlayabileceği ve veritabanı yapısını gözünde canlandırabileceği bir veri modeli çıkarmak ve bu model üzerinden organizasyon ihtiyaçlarını doğru şekilde karşılayacak fiziksel bir veritabanı tasarımına zemin hazırlamaktır.
Veritabanı modellemenin üç türü vardır. Bu türler aynı zamanda veritabanı model veya tasarımın aşamalarını da bildirir.

Kavramsal tasarım (Conceptual design): Veri tabanının hangi verileri içereceğinin ve bu veriler arasındaki ilişkilerin belirlendiği aşamadır. Bu aşamanın en önemli özelliği veritabanı nesneleri herhangi bir VTYS şemasına bağlı kalınmadan modellenir. Bu aşamada organizasyon içindeki herkes aktif olabilir. Kavramsal modelleme, mantıksal modellemenin çözümlenmesini ve tasarımını kolaylaştırmak için atılmış bir adımdır.

Mantıksal tasarım (Logical design): VTYS’nin tanımlandığı aşamadır. Kavramsal tasarımda modellenen yapı, karar verilmiş olan VTYS’ye uygun şemaya dönüştürülür. Veritabanında kullanılacak veri türleri, tablo üzerindeki anahlarlar, tablo satırlarının birbirleriyle ilişkileri bu aşamada belirlenir. Bu aşamada daha çok tasarımcı ve programcı rol oynar.

Fiziksel tasarım (Physical design): Verilerin hangi disk veya başka fiziksel depolama sistemlerinde nasıl tutulacağı, ne tür işlemci yapılarının kullanılacağı, aygıtların verilere hangi yol ve kurallar dahilinde ulaşacağı ve bunların doğrultusunda VTYS yazılımın hangi işletim sistemi üzerinde koşacağı belirlenir. Daha çok veritabanı programcısının aktif rol oynadığı bu aşamada oraya çıkan modelin daha önce organizasyon elemanlarıyla birlikte karar verilmiş olan kavramsal ve mantıksal modelle olan uyumluluğu test edilir. Kısaca, kavramsal ve mantıksal tasarım aşamasında, veritabanı şemasına karar verildiğini, fiziksel tasarım aşamasında da veritabanının fiziksel yapısına karar verildiğini söyleyebiliriz.

Bu aşamalardan sonraki süreç, uygulama programının yazılarak kullanıcıların belirlenmiş yetkiler ölçüsünde veriye ulaşmasıdır.

Kendisi soyut bir yapı olan veri modeli, ANSI-SPARC mimarisine göre kavramsal (conceptual), dış (external) ve iç (internal) olmak üzere üç seviyeli soyutlama derecesine sahiptir. Bu seviyeler, veri ortamının organizasyon içindeki kişiler tarafından görünen görünümü temsil eder. Dış seviye, veritabanının kullanıcıya olan görüntüsü ifade eder. Her kullanıcının özgül bakışı ve bilgisi doğrultusunda birçok dış görünüm oluşturulabilir. Bu görünümler kullanıcı programları veya doğrudan SQL cümleleriyle oluşturulur. Daha çok veritabanı sahiplerinin hazırladığı ve veritabanının üst düzeyde soyutlanmış hali olan kavramsal seviye, veritabanının kuş bakışı görüntüsünü temsil eder. Bu seviyede veritabanında hangi verilerin saklandığı ve bu veriler arasındaki ilişki görünür. Kavramsal modelde veritabanı yazılım ve donanımla ilgili bilgi bulunmaz yani VTYS’den bağımsız bir görüntü sunar. İç seviye ise VTYS’ye bağımlı olup veritabanının VTYS’ye göre hazırlanmış şemasını belirtir. Veritabanının en alt düzeyde soyutlanmış olan bu seviyede verilerin veritabanın nasıl saklandığı ifade edilir. Aynı zamanda fiziksel seviye olarak ta bilinir.

Veritabanı tasarımı konusunda bu kadar giriş yapmamız yeterli olacaktır. Asıl konumuz; kavramsal tasarım aşamasında en çok kullanılan yöntem olan Varlık-İlişki (Entity-Relationship, ER) modelidir. ER modeli, kavramsal veri modelini herhangi bir VTYS şemasına bağlı kalmadan ana hatlarıyla ER diyagramı üzerinde şematik olarak gösterme tekniğidir. Bu teknik, organizasyon içerisindeki teknik veya teknik olmayan kişiler arasında verinin farklı görünümlerini ortak bir kalıba dönüştürür ve veritabanı uygulamalarının daha kolay geliştirilmesini sağlar. ER çizenekleri için, genellikle UML gösterimleri kullanılır.

ER yönteminin çıkış amacı tasarımcıların oluşturduğu nesne modelini, nesne kavramını anlamayan ilişkisel veritabanı yönetim sistemlerine kolaylıkla uyarlayabilmektir.
ER modeli, teknik olarak varlıklar (entities) ve ilişkiler (relationships) koleksiyonundan oluşur. ER modelinin temelinde bu bölümün de anahtar kelimesi olan varlık bileşeni bulunur. Varlık ifadesi, Yazılım Mühendisliği literatüründe gerçek dünyadaki anlamıyla kullanılır. Yani soyut veya somut olarak var olan ve benzerlerinden ayırt edilebilen her şeye varlık denilir. Örneğin gerçek dünyada insanoğlu, araba, devlet nesneleri varlık olarak nitelendirildiği gibi nesne tabanlı programlamada sınıflar, veritabanı yönetim sisteminde de tablolar varlık olarak nitelendirilir. Her varlık, kendisini diğer varlıklardan ayırteden öznitelik (attribute) olarak bilinen karakteristiklere sahiptir. Veritabanındaki tablolar, satır ve sütunlardan oluşur. Tablo satırlarının her biri bir tek varlığı temsil eder. Varlığın her bir niteliği bir sütunda temsil edilir. Örneğin bir elektronik ticaret projesinde “Musteri” bir varlık, müşterinin “AdSoyad” bilgisi, bu varlığa ait bir nitelik olarak tanımlanabilir. “AdSoyad” bilgisinin “Murat Şensoy” olarak belirlenmesi bu niteliğin değeridir (data value). Özniteliğin alabileceği veya aldığı değerler etki alanı (domain) olarak tanımlanır.

VTYS’ler varlık kümesi ve onların arasındaki etkileşimden oluşur. Varlıklar arasındaki etkileşim, varlık ilişkisi olarak tanımlanır. Varlıklar arasında üç tür ilişki kurulur:

Birden çoğa ilişki (one-to-many relationship): Bir tablonun bir kaydına karşılık ikinci tabloda birden fazla kaydın olmasıdır. “Siparis” ve “Musteri” tabloları arasındaki ilişkidir. Bir sipariş, sadece bir müşteriye ait olabilir fakat bir müşterinin birden fazla siparişi olabilir. Bu ilişki 1:M ile temsil edilir.

Çoktan çoğa ilişki (many-to-many relationship): Bir tablonun birden fazla kaydı, diğer tablonun birden fazla kaydıyla ilişkilidir. M:N ile temsil edilen bu ilişki genellikle üçüncü bir tablo üzerinde oluşturulur. “Ogrenci” ve “Kurs” tablolarını örnek olarak verebiliriz. Bir öğrenci birden fazla kursa katılabilir aynı şekilde bir kursa birden fazla öğrenci katılabilir. Bu ilişki “OgrenciKurs” tablosunda tutulur.

Birden bire ilişki (one-to-one relationship): Bir müşterinin bir şifresi var ve her bir şifre bir müşteriye aittir. Bu durum, bir tablo ilişkisinden ziyade ikinci tablonun birinci tablonun uzantısı olmasıdır.

Tasarım aşamasında varlık ve onlara ait öznitelikler belirlendikten sonra varlıklar arasındaki ilişkiler belirlenir ve öğe ilişki çizeneği çıkarılır (entity relationship diagramming – öğe ilişki çizeneği). Bu çizelgede veritabanı varlıkları, varlıkların türleri, varlıklar arası ilişkiler ve ilişki kuralları gösterilir. ER diyagramı hazırlayabilmek için Microsoft Visio, Sybase Power Designer gibi araçlar kullanılır. Aşağıdaki çizelgede üç tablonun yapısı ve ilişkileri gösterilmiştir.

Sonuç olarak ER tekniğinin, veritabanı oluşturulmadan önce veritabanı tasarımını kolaylaştırmak amacıyla veritabanının hangi varlıklardan oluştuğunu ve bu varlıkların nasıl ilişkilendirildiğini çeşitli şemalarla belirtme yöntemi olduğunu söyleyebiliriz. ER modelinin en önemli özelliği bu mantıksal tasarımı VTYS şemasına bağlı kalınmadan yapmasıdır.

VTYS tarafında, tasarımcılar tarafından oluşturulmuş olan nesne modelini VTYS’de saklamak için aracı olarak ER modelini kullanıyoruz. Bu ek işlem, şu anki VTYS’lerin nesne yönelimli (Object Oriented) olmamasından kaynaklanmaktadır. Aynı sorun kullanıcılarla veritabanı arasında iletişim sağlayacak veritabanı uygulamaları yazılırken de yaşanır. Özellikle nesne yönelimli bir programlama dili kullanıldığı zaman class, inheritance, property, method gibi OOP varlıkları VTYS tarafından desteklenmediği için iş katmanında OOP ve ilişkisel veritabanı özellikleri iç içe kullanılır. Uygulamaların iş katmanındaki bu iş yükünü azaltmak amacıyla O/R Mapping isimli nesne-ilişki eşleştirme yöntemi kullanılır.

Nesne-İlişkili Haritalama (Object-Relational Mapping – O/R Mapping)

Günümüzde en çok kullanılan veri modeli, ilişkisel veri modelidir. Aynı şekilde uygulamaların iş katmanı yazılırken en çok nesne odaklı programlama modeli tercih edilir. Uzun yıllardır kullanılan bu iki yöntem, uygulama geliştiriciler için ciddi kolaylıklar sağlamıştır. Bununla birlikte bu iki yöntemin kullanıldığı geniş çaplı kurumsal uygulamaların en önemli sorunu, bu uygulamaların tasarım ve geliştirme süreçlerinin yönetimi zor ve zaman alıcı bir hal almasıdır. Özellikle iş katmanında veritabanı sorgulama işlemlerinde yoğun bir şekilde SQL dilinin kullanılıyor olması ve uygulama kodlarının veritabanı şemasına bağlı kalması, uygulama geliştiricilerinin veritabanı tarafında çok zamanını almaktadır. Veritabanında yeni bir kolon ekleme, kolon değiştirme gibi tablonun şemasının değişmesi durumunda uygulamanın iş katmanındaki veri erişim kodlarının yeniden gözden geçirilmesi gerekir. Bir veritabanı uygulamasında, kodun üçte birinin veri erişimiyle ilgili olduğunu göz önünde bulundurduğumuzda veri erişim katmanında her modül için sorgulama, ekleme, güncelleme, silme gibi işlemleri yeniden kodlamak birçok yazılım mühendisi için sıkıcı ve zaman alıcı olabilmektedir.

Ayrıca iş katmanında nesne odaklı programlama tercih edildiği halde veriye nesnesel olmayan yöntemlerle erişilir. Yani veritabanında veri tutmaya yarayan tabloları, uygulama geliştirme tarafında gerçek varlıkları temsil etmek için kullandığımız nesnelerle ifade edememekteyiz. Aynı şekilde uygulama tarafında oluşturulmuş bir nesneyi de veritabanı tarafında uygun bir şekilde temsil edememekteyiz. Bu işlemleri yapabilmek için diğer veri modeli olan ve gerçek dünyayı daha iyi modelleyebilecek “nesneye yönelik veri modeli”nin gelişmiş olması lazım. Şu ana kadar bu modeli desteklemek amacıyla Nesne Yönelimli VTYS (Object Oriented DBMS – OODBMS) üzerinde çalışmalar yapılmışsa da ciddi sonuçlar elde edilemedi. Bu yüzden sözkonusu sorunları aşmak için şimdilik yapabileceğimiz ancak yöntemin iyileştirilmesi olacaktır. Bu amaçla ilişkisel veritabanı ile nesneler arasında bağlantı kurma ve eşleştirme yapma yöntemi olarak bilinen Nesne/İlişkisel Eşleme (O/R Mapping-ORM) modeli kullanılır. Bu model, uygulamaların iş katmanında kod yazımını kısaltarak veritabanı işlemlerinin daha kısa sürede geliştirilmesini, veritabanı işlemlerinde OOP yeteneklerinin kullanılmasını sağlar ve sonuçta yazılım bakımını kolaylaştırır. Bu cümleleri biraz daha detaylandıralım.

ORM yöntemi, en çok tercih ettiğimiz nesne odaklı programlama modeli ile ilişkisel veritabanı modeli arasında ilişki kurup ilişkisel veritabanındaki öğelerin, nesne odaklı dildeki nesnelere nasıl karşılık geleceğini yönetir. Tabloları sınıflara (class), satırları nesnelere (instance), kolonları bu nesnelerin özniteliklerine (attribute) bağlar, oluşturulan sınıf yordamları, tablo seviyesinde, nesne yordamları da satır seviyesinde işlemler yapmak için kullanılır. Böylece verileri sorgularken, güncellerken, eklerken, silerken nesnesel ifadeler kullanmamıza olanak tanır. VTYS tarafındaki öğelere karşılık gelen uygulama nesnelerine alan nesnesi (domain object) denilir. Bu kalıcı sınıflar, uygulama tarafında, veri erişim katmanı (persistence layer) olarak isimlendirilen alanda yaşar.

Bir anlamda uygulamayı, veritabanından soyutlamış olan ORM yaklaşımı, veri işleme katmanını daha hızlı oluşturmamızı, veritabanı işlemlerinde daha az SQL kodu yazmamızı ama bununla birlikte verileri en az SQL kadar güçlü bir yöntemle sorgulamamızı ve performans açısından otomatik ön bellekleme yapılmasını sağlar. Ayrıca veritabanı şemasında yapılan bir değişiklikte (veri erişim katmanındaki sınıflar doğrudan veritabanına bağlı olmadığı için) veri erişim kodlarını gözden geçirmek yerine daha önce oluşturulmuş olan xml tabanlı nesne-tablo eşleştirme dosyasının düzenlenmesi yeterli olacaktır.

O/R Mapping yönteminde kullanılmak üzere birçok araç geliştirilmiştir bunların en popüleri ilk olarak Java platformu için çıkarılmış ama daha sonra .NET sürümü de geliştirilmiş olan açık kaynak NHibernate ürünüdür (www.hibernate.org). Bunun dışında başta LLBLGen ürünü olmak üzere .NET platformunda kullanılacak birçok O/R Mapping aracı bulunmaktadır. Günümüzde birçok yazılım evi, uygulamalara ait ORM kodu üreten framework’ler geliştirmiştir. Bu araçlar kullanılarak sorgulama cümleleri elle yazılmak yerine otomatik olarak üretilir ve veri erişim katmanı kısa sürede oluşturulmuş olur. Dolayısıyla yazılım mühendisinin veri erişim ve sorgulama için ayıracağı kodlama zamanını iş katmanındaki algoritmaya ayırması, o alana odaklanması, veri erişim katmanını düşünmemesi sağlanmış olur.

Bir diğer konu da ugulamalar içerisinde veritabanı işlemleriyle ilgili kodların çalıştırılma yönteminin ne olacağıdır. Bu yöntemin ne olacağı yazılım uzmanları arasında birçok tartışma konusu olmuştur. .NET Framework’ün ilk sürümlerinde iş katmanında dinamik SQL yerine SQL yordamlarının (stored procedure) kullanılması tavsiye edilmiştir. Bu yöntemin daha fazla güvenlik ve hız kazandırdığı dile getirildi. Ancak günümüzde bu yöntemin güvenli olduğu kabul edilse de performans ve kullanım konusunda fikir birliği sağlanamamıştır. Stored procedure yerine dinamik SQL kullanılmasını tavsiye edenlerin dayanağı; stored procedure’lerin versiyonlama, taşınma ve kurulumun kolay olmaması ve büyük ölçekli kurumsal uygulamalarda iş kurallarının genişlemesiyle birlikte yönetimi ve bakımı zorlaşacak çok sayıda procedure yazmak zorunda kalınmasıdır. Aslında asıl sorun iş katmanı ve veri katmanı sınırlarının iç içe geçmesi ve ilk paragraflarda bahsettiğimiz gibi uygulama geliştiricinin veri katmanında çok zaman harcamasıdır. Veritabanının doğası gereği görevi veri arama, tarama olduğu için kod güvenliği, matematiksel işlemler, koşula dayalı işlemler gibi ek faaliyetlerle uğraşmaması gerekir. Bununla birlikte farklı türden veritabanı üzerinde çalışma ihtimali olan paket haline getirilecek bir ürün için iş kurallarını stored procedure üzerinde oluşturmak uyarlama sürecini zorlaştıracak, zaman kaybına neden olacaktır. Stored procedure’lere alternatif olarak dinamik SQL yapısının kullanılması da uygulamayı, veritabanı şemasına bağımlı hale getirecektir. Bu yüzden O/R Mapping yöntemini kullanarak iş katmanını SQL kodlarından temizleyip bu katmanın sadece iş mantığı algoritmasını içermesini ve uygulama geliştiricinin de sadece o katmana odaklanmasını, T-SQL ile boğuşmak yerine sadece OOP destekli dil ile işlemlerini yürütmesi sağlanmalıdır. ORM yöntemini tercih ettiğimizde aşağıdaki gibi bir T-SQL cümlesi veya stored procedure yerine

UPDATE Musteri SET AdSoyad='Murat Şensoy'
WHERE MusteriId = 10

aşağıdaki gibi bir kod yazmış olacağız.

Musteri.AdSoyad = "Murat Şensoy"
oRm.Save(Musteri)

Görüldüğü gibi CRUD (create, read, update, delete) işlemlerini OOP kurallarına göre yazmış oluyoruz. Böylece iş katmanını kodlayan yazılımcının yöntem alışkanlığı bozulmamış olmaktadır.

O/R Mapping modelinin geliştirme sürecinde kolaylık sağlamasına karşılık çalışma zamanında klasik yöntemle kıyaslandığında performans konusunda yeterince iyi olduğunu söyleyemeyiz. Bunun nedenlerini şu şekilde sıralayabiliriz:

• ORM, uygulama mimarisine veri erişim isminde yeni bir katman ekler.
• Veri katmanı, veritabanına doğrudan erişemez.
• SQL dilinin kompleks sorgu oluşturma ve çözmedeki gücünden yararlanılmaz.
• ORM, uygulamanın veritabanı bağımsız olmasını sağladığı için o anda kullanılan VTYS’nin yeteneklerinden yararlanılamaz.

Sonuç olarak O/R Mapping yönteminin zorunlu bir yöntem olmadığını ancak kompleks iş katmanına sahip büyük ölçekli kurumsal uygulamalarda veri erişim katmanını daha az kodla ve kısa sürede üretmeye yardımcı olduğu ve sonuçta yazılım mühendisinin üzerindeki yükü hafiflettiği için tercih nedeni olabileceğini söyleyebiliriz. Bu yöntemi kullanıp kullanmamak birazcık ta “uygulama içerisinde klasik veri sorgulama ifadelerini (select, insert, update, delete) SQL ile manual mi oluşturacağız yoksa bunlar otomatik mi oluşturulmalı?” sorusuna vereceğimiz yanıta bağlıdır.
Tanımını, avantaj ve dejavantajını verdiğimiz ORM yönteminin .NET cephesindeki durumunu inceleyelim.

ADO.NET Entity Framework

Microsoft, ADO.NET 2.0 ile birlikte sunduğu ObjectSpaces (OS.Net) ürünüyle O/R Mapping çözümüne ilk adımını atmış oldu. ADO.NET 3.5 ile birlikte ObjectSpaces ürününü yeniden düzenleyerek ADO.NET Entity Framework isimli eklentiyi geliştirerek O/R Mapping alanındaki adımlarını daha da belirginleştirdi.

Entity Framework eklentisi, sadece bir O/R mapping aracı veya bir code generator olmanın ötesinde bunları da içinde barındıran ve uygulama içerisindeki varlıkları ve ilişkilerini sorgulamamızı sağlayan servisler bütünüdür. Entity Framework’ün servisleri aşağıdaki şekilde gösterilmiştir.

ADO.NET Entity Framework’ün bir parçası olarak Framework ortamında ER modelinin oluşturulması için Varlık Veri Modeli (Entity Data Model-EDM) isimli konsept sunulmaktadır. EDM’yi veritabanı şemasını kavramsal ve mantıksal boyutta gösteren ve ilgili ORM haritasını oluşturan bir araç olarak değerlendirebiliriz. EDM, varlıklarla ilgili şemayı XML belgelerinde (CSDL, SSDL, MSL) saklar. Bu üç dosya, Entity Framework’ün üç temel boyutu olan kavramsal (conceptual), mantıksal (logical) ve haritalama (mapping) modelleriyle ilgili bilgileri içerir.

CSDL (Conceptual Schema Definition Language): Varlıkların ve onlara ait ilişkilerin tanımlandığı dosya olup uygulamanın çekirdek veri modelini (core data model) teşkil eder. Uygulama katmanında varlıklar (nesneler), CSDL şeması referans alınarak oluşturulur. Bu şema, kavramsal şema formatına sahiptir.

SSDL (Store Schema Definition Language): Veri kaynağı olarak kullanılacak veritabanına ait üstveri (metadata) bilgisini içerir. Mantıksal model için oluşturulan bu dosya, varlıklarla veri kaynağı arasındaki iletişimi kurar.

MSL (Mapping Specification Language): CSDL dosyasındaki varlıkları SSDL dosyasında belirtilmiş tablolarla eşleştirir.

Entity Client, SQLClient, OracleClient gibi ADO.NET’in bir yönetilebilir veri sağlayıcısı (managed provider) olup EDM tarafından tanımlanmış olan veriye erişmeyi sağlar. Diğer sağlayıcılar gibi bunun da EntityCommand, EntityConnection ve EntityTransaction bileşenleri bulunur.

Object Services bileşeni, veri nesneleri üzerinde CRUD (Create, Read, Update, Delete) işlemleri için gerekli sorguları oluşturur. Bu sorgulama servisi, “Entity SQL” ve “LINQ to Entities” türü sorgulama destekler. Entity SQL (eSQL) ismindeki sorgulama dili, T-SQL’ dilinden türemiş olup EDM modelindeki varlıkları ve aralarındaki ilişkileri sorgulamak için kullanılır. LINQ to Entities bileşeni de daha sonra yazılarda anlatacağımız LINQ teknolojisinin varlıkları sorgulamak için sunduğu bir sağlayıcıdır.

Farklı veritabanları üzerinden çekilmiş olan XML verisinin bir dosyaya kayıt edilip ilgili alana FTP ile gönderildiği projede ihtiyaç duyduğum küçük bir örneği paylaşmak istiyorum. Düz metin formatında bulunan XML datasının standart XML formatından girintili olarak gösterilmesi.

Ahmet KaymazEvin Adresiİşin Adresi

Bu düz metni aşağıdaki gibi XML yapısında biçimlendirelim.

  
    Ahmet Kaymaz
    
      Evin Adresi
      İşin Adresi
    
  

Böylece daha okunaklı bir format elde edilmiş olunur.

using System;
using System.IO;
using System.Text;
using System.Xml;

public class Program
{

    static void Main()
    {

        Console.WriteLine(XmlBicimlendir("Ahmet KaymazEvin Adresiİşin Adresi"));
        Console.ReadLine();
    }

    public static String XmlBicimlendir(String XmlIcerik)
    {

        MemoryStream oMs = new MemoryStream();
        XmlTextWriter oXWrt = new XmlTextWriter(oMs, Encoding.Unicode);
        XmlDocument oXDoc = new XmlDocument();

        try
        {
            // XML içeriğini XmlDocument ile yükleyelim
            oXDoc.LoadXml(XmlIcerik);

            //XmlTextWriter nesnesini girintili olacak şekilde biçimlendirelim
            oXWrt.Formatting = Formatting.Indented;

            //XmlDocument içeriğini XmlTextWriter nesnesine yazdıralım
            oXDoc.WriteContentTo(oXWrt);
            //Nesnelerin sahip olduğu buffer alanını temizleyelim
            oXWrt.Flush();
            oMs.Flush();

            //MemoryStream'ın içeriğini okumak için alanın başladığı alana geri saralım
            oMs.Position = 0;

            //MemoryStream içeriğini bir StreamReader nesnesine aktaralım
            StreamReader oSr = new StreamReader(oMs);

            //StreamReader nesnesinden metni okuyalım
            XmlIcerik = oSr.ReadToEnd();
        }
        catch (XmlException ex)
        {
            XmlIcerik = "Hata Olustu." + ex.Message;
        }
        finally {
            oMs.Close();
            oXWrt.Close();
        }

        return XmlIcerik;
    }
}

Imports System
Imports System.IO
Imports System.Text
Imports System.Xml

Public Module Module1

    Sub Main()
        Console.WriteLine(XmlBicimlendir("Ahmet KaymazEvin Adresiİşin Adresi"))
        Console.ReadLine()
    End Sub

    Function XmlBicimlendir(ByVal XmlIcerik As String) As String

        Dim oMs As New MemoryStream()
        Dim oXWrt As New XmlTextWriter(oMs, Encoding.Unicode)
        Dim oXDoc As New XmlDocument()

        Try
            ' XML içeriğini XmlDocument ile yükleyelim
            oXDoc.LoadXml(XmlIcerik)

            'XmlTextWriter nesnesini girintili olacak şekilde biçimlendirelim
            oXWrt.Formatting = Formatting.Indented

            'XmlDocument içeriğini XmlTextWriter nesnesine yazdıralım
            oXDoc.WriteContentTo(oXWrt)
            'Nesnelerin sahip olduğu buffer alanını temizleyelim
            oXWrt.Flush()
            oMs.Flush()

            'MemoryStream'ın içeriğini okumak için alanın başladığı alana geri saralım
            oMs.Position = 0

            'MemoryStream içeriğini bir StreamReader nesnesine aktaralım
            Dim oSr As New StreamReader(oMs)

            'StreamReader nesnesinden metni okuyalım
            XmlIcerik = oSr.ReadToEnd()
        Catch ex As XmlException
            XmlIcerik = "Hata Olustu." & ex.Message
        Finally
            oMs.Close()
            oXWrt.Close()
        End Try

        Return XmlIcerik
    End Function
End Module