Uygulamaların geliştirildiği ortamları sayarsak
· Standalone Uygulamalar
· Client/Server Uygulamaları
· Web Tabanlı Uygulamalar
· n-Tier (çok katmanlı) Uygulamalar
Bu sıra aslında biz programcıların geçirdiği değişimleride gösteriyor. İlk olarak standalone uygulamalar ile başladık, sistemler geliştikçe veri paylaşımı gibikriterler ortaya çıktı. Bu açığı kapatmak için daha sonra client ve server mimarisine geçiş yaptık, bu mimaride iş mantığı client birimlerde, veri server’larımızda duruyordu. Ancak bu mimarinin eksikleri ise client uygulamalardaki versiyonlama problemleri ve dağıtımda yaşadığımız problemlerdi. Teknolojinin gelişmesiyle iş mantığı ile veri’yi server tarafında tutan web tabanlı uygulamalara geçtik. Web tabanlı uygulamalarda ise karşımıza kod’un tekrar kullanımı, browser karmaşaları (Browser tipleri, versiyonları...) çıkmaya başladı. Bu kez ASP üzerinde yazdığımız kodları VB gibi dillerde COM objeleri yazarak veya database serverlar üzerindestored procedure’lerle kod’un tekrar kullanımı gibi problemleri biraz olsun arttırabildik. Bu teknoloji ile giderek n-Tier uygulamalara benzemeye başladı. Gelebildiğimiz en son mimari ise genelde platform bağımlı, kodun tekrar kullanılabilirliği kötüden biraz daha iyi, performans olarak orta derecede, güvenlik olarak “fully trusted” çalışan, ve genelde dökümantasyonu olmayan kütüphaneler oldu.
Bu mimaride genelikle yaptığımız database’imizi yönetecek tüm iş mantığını taşıyan bir kütüphane yazmak, diğer kullanıcı katmanlarında ise grafik arabirimli DCOM mimarisini kullanan client uygulamalar ve/veya yine aynı kütüphaneyi kullanan asp kodlarından oluşan web arabirimlerini geliştirmekti.
.net ile bu mimaride değişecek olan şeyler ise bizim aslında eksik kalan kısımlarının tamamlanması. .net mimarisi ile gelen yeni özellikleri kaynaklardan bulabilirsiniz. Ancak burda anlatılacak olan asıl konu kodlama tekniğimizin nasıl değişeceğidir.
İlk yazılan class
İşe geliştireceğimiz kütüphanedeki en temel fonksiyonları taşıyan bir temel sınıf yazmak.
using System;namespace xfirmasi.xurunu
{
/// <summary>
/// Summary description for CBase.
/// </summary>
public class CBase
{
protected string m_Name;
public CBase()
{
Name = "undefined";
}
/// <summary>
/// Object database ID number.
/// </summary>
public int ID
{
get
{
return m_ID;
}
}
internal void setID(int ID)
{
m_ID = ID;
}
/// <summary>
/// Object name
/// </summary>
public string Name
{
get
{
return m_Name;
}
set
{
m_Name = value;
}
}
}
}
Bu class’ı daha sonra yazacağımız class’larda geliştireceğimizden içinde son derece genel işlemleri koymamız gerekli. Örnek olması için kütüphanemizde her objenin bir adı olacağından sadece Name özelliği eklendi.
.net ile gelen en önemli değişiklerden biride artık değişken, sınıf adlarına verdiğimiz “hungarian” metodundan vazgeçilerek “Pascal” standardına geçilmesi oldu. Bu standart ile artık string gibi değişkenlerin başına “sz” veya “str” gibi önekler eklenmiyor. Tabiki bu yenilik bir mecburiyet değil, ancak kodların okunabilirliği açısından bir tavsiye.
Namespace adları konusunda verilen tavsiye “firma.teknoloji.uzantı” formatında olması.
Yazılan class’ın ve Name property alanının üzerinde not benzeri açıklamalar görüyorsunuz. Bu açıklamalar Visual Studio .Net içerisinde otomatik olarak açılıyor. Bu notlar aslında programcıların hiç hoşlanmadığıdökümantasyon konusunda biraz yardımcı olacak. Bu notlar düzenli olarak yazıldığında bir tool ile dökümantasyon otomatik olarak oluşturulabiliyor. Method gibi işlemlerde geçilecek parametreleri, dönüş değerlerini v.s. gibi açıklamaları yazabiliyorsunuz. Not düşmek için 3 tane arka arkaya “/” karakteri koymanız Visual Studio’nun gerekli tagları açmasına neden olacaktır. Size sadece bu tag’ların içini doldurmak kalıyor. Ayrıca bu notları “ClassBrowser” içerisinden de görebiliyorsunuz.
Base classı içerisinde bir Name property tanımlaması görüyorsunuz. Property’ler methodlara göre çok daha kullanışlı bir tekniktir. Name özelliği okunmak istendiğinde get bloğu, değer atandığında ise set bloğu çalıştırılacaktır. Böylece gerekli değer aralığı gibi kontroller bu bloklar içerisinden kontrol edilebilir. Set bloğu içerisinde atanan değer tipi ne olursa olsun “value” keyword’u içerisinde bulunmaktadır. Ayrıca sadece get bloğu yazıldığında o özellik readonly olarak çalışacak yada sadece set bloğu yazıldığında ise writeonly bir özellik olarak kullanılabilecektir. Verilen örnekte ID özelliği readonly modda çalışmaktadır. ID alanını kendi kütüphanemiz içerisinde değiştirebilmek için ayrıca internal erişimde çalışan bir method eklenmiştir. Böylece obje ID numaralarının kendi kütüphanemiz içerisinde normal çalışması, kütüphane dışarısında çalışırken sadece readonly olarak çalışması sağlanmıştır. Bu tekniğin diğer bir avantaj ise verilen değer bizim kontrolümüzde olacak ve kabul edilirse class içerisindeki private tanımlanmış iç değişkenimizde saklanacaktır. OOP mimarisinde bunaEncapsulation adı verilir.
Tanımladığımız Base class’ından inherit edilen yeni bir sınıf yazdığımızda
using System;namespace xfirmasi.xurunu
{
/// <summary>
/// Summary description for CFile.
/// </summary>
public class CFile : CBase
{
private int m_size;
private CDir m_Parent;
public CFile(CDir Parent)
{
m_Parent = Parent;
}
public new string Name
{
get
{
return m_Name;
}
set
{
m_Application.m_db.Update("tblFiles",this.ID,"Name",value);
m_Name = value;
}
}
}
}
Base class’ı içerisinde var olan tanımlamalar aynen alınacaktır. Ancak CFile class’ı içerisinde objenin adı değiştirildiğinde verilen değer bir database’e kaydedilmesi sağlandı. CBase sınıfı içerisinde tanımlanan Name alanını yeniden tanımlamak için özellik adının başına bir “new” keyword’ü eklendi. Böylece derleyici hatalarından kurtulmuş olduk. Bu class’ı yazmamızla OOP mimarisindeki Inheritance ve Polymorphism özelliklerini kullanmış olduk. Inheritance bildiğiniz gibi başka bir sınıftan akraba özelliklerini almaktır. Inherit edilen class içerisindeki bazı özellikleri başka amaçla değiştirerek kullanmamıza ise Polymorhism denmekte.
