Tüm dünyada olduğu kadar Türkiye’de de bir fenomene dönüşmüş, milyonların sosyal paylaşım sitesi Facebook’un kurucusu Mark Zuckerberg ve arkadaşlarının öyküsü.

2003 yılının Ekim ayında alkollü bir gece, kız arkadaşından yeni ayrılmış olan Mark, üniversitenin bilgisayarlarına sızarak, kampustaki tüm kadınlarla ilgili bilgilerden oluşan bir veri tabanını içeren bir site yaratır, ardından yan yana iki fotoğraf koyarak kullanıcılardan hangisinin “daha çekici” olduğunu seçmesini ister.

Sitenin adını Facemash koyar; site bir anda virüs gibi etrafa yayılarak tüm Harvard sistemini çökertir ve görünürdeki kadın düşmanlığıyla kampusta tartışma yaratır; Mark, Facemash’ı yaratarak kasıtlı olarak güvenliği, telif hakları yasasını ve özel hayatı ihlal etmekle suçlanır. Tam o anda, Facebook’un altyapısını oluşturan iskelet ortaya çıkmıştır. Kısa süre sonra, Mark Harvard’da bir ekrandan diğerine , Ivy League üzerinden Silikon Vadisi’ne ve tüm dünyaya bir yangın misali sıçrayacak olan thefacebook.com sitesini oluşturur. Ama yaratım sürecinin karmaşasında, her şeyin nasıl gerçekleştiği, içinde bulunduğumuz yüzyılın en orijinal fikirlerinden biri olduğu açık olan bu şeyde kimlerin isminin anılması gerektiği konusunda hararetli bir mücadele doğar. Bu mücadele, dostların arasını açacak ve yasal yollara başvurmaya kadar uzanacaktır.


Bir pazar akşamı özellikle Fenerbahçe - Galatasaray maçının oynandığı saatlerde izlemek için oldukça ideal bir filmdi. Büyük keyif alarak izledim mutlaka izlemenizi öneririm.

Yazılım Mimarilerinin Temel Prensipleri -2

Merhaba Arkadaşlar, kaldığımız yerden devam ediyoruz. Bir önceki yazımızı temel mimari katmanlarına kısaca değinmiştik. Bu yazımızda bir uygulama için mimari hazırlarken hangi parameterelere bakmamız gerektiğini nelere dikkat edilmesi gerektiğine değineceğiz.

 

Konuya girmeden önce size bir sunumda karşılaştığım Sarah Winchester House'dan bahsetmek istiyorum. Evin hikayesi oldukça ilginç. Hikayesi kadar evin yapısı ve yapılış şeklide bir o kadar ilginç. Asıl dikkatinizi çekmek istediğim bir nokta evin mimarisi; Evdeki pek çok oda sonradan yapılmış. Evde 160 oda ve 4 kat (Onun en güzel döneminde evin, 7 katı vardı!) 6 mutfak, 40 yatak odası, 19 baca, 40 merdiven, 47 şömine, 52 tepe penceresi, 950 kapı, 3 asansör, 2 balo salonu ve 10 000 pencereyle!  Hiçbir Mimari detaya dikkat edilmeden sonradan eklenmiş. Hiçbir mimari detay dikkate alınmadan sonradan ilavelerde bu hale gelmiş bir yapı. Eğer uygulamalarımızı bir önceki yazımda bahsettiğim gibi bazı temel prensipler doğrultusunda geliştirmediğimiz taktirde uygulamarımızın mimarisi bu evin olmayan mimarisinden farksız olacaktır.

Mimaride modern yaklaşım tasarımın mimar ve developer için ihtayaç duyduğu her şeyi bilmediğini ve geliştirecek olduğunu farz eder. Yani mimaride developer tarafından kullanılacak her nesne mimar tarafından en az  bir sınıf türetilmiş olmalıdır. Böylelikle developer uygulamayı mimar tarafından geliştirilen freamwork üzerinden geliştirme noktasına gelir.

Örneğin; Tip dönüşümü konusuna bakıldığında  bir tipi başka bir tipe dönüştürmenin pek çok yolu vardır. Parse,Convert, pointer gibi.. Fakat developer ın bu özelliklerden hangisini kullanacağına karar vermeden mimar tarafından geliştirilmiş Core Custom Convert  methodunu kullanması istenmelidir. Tip dönüşümde hangi tipin hangi tipe nasıl dönüştürüleceği bu Facade methodun arkasında karar verilmelidir.

 

Bunun gibi tüm katmanlarda mimar - developer'ı  geliştirdiği yapılarla sarmalamalıdır. Böylelikle uygulama mimarisi üzerinde tam kontrol sağlanır. Developer ın temel görevi mimar tarafından geliştirilmiş yapıları kullanarak Uygulamayı geliştirmektir. Böylelikle Uygulama .NET Framework üzerine inşa edilmiş şirket Framework'ü üzerinde yapılacaktır.

Open Closed Prensibi : Şirketin uygulamanın üst versionlarında yapacağı teknolojik politika değişiklikleri min. kodlama maliyeti ile Uygulamaya aktarılabilir. Uygulama ile Şirket Framework'ü (kod geliştirme kültürü) arasında gevşek bağlılık olacağı için de politik değişiklikler şirket Framework'ü üzerinde yapıldığında Uygulama tarafında bir geliştirme ihtiyacı duyurmamalıdır. Bu Prensipbe Open-Close diyoruz.(Gelişime açık ama değişime kapalı) Geliştirdiğiniz mimari üzerinde kullanılmakta olan bir method un dönüş tipi ve parametrelerin tipleri ve sayıları üzerinde asla değişikliğe gitmemelisiniz. İhtiyacınız bunu gerektiriyorsa mu method un aşırı yüklenmiş bir versionun geliştirmeniz önerilir. Böylelikle yeni version yapınızda eski versionunuzu destekleyerek yeni version bir sürüm çıkartmış olursunuz.

Data Access Layer'ınızın ilk versionunda sadece string SQL kullanmış olabilirsiniz. 2.0 Versionun da aynı method un farklı parametre tiplerinde genişletmek mümkündür. Alt version katmanınızla etkileşen diğer katmanlarınız budan etkilenmeyecektir.

 

Uygulama geliştirme safhasında hangi işlemin Mimariye hangi işlemin Uygulamaya ait olduğunu ayırt etmenin basit bir yolu vardır. Bir şirketin aynı anda birden farklı 2 ürün geliştirdiğini varsayalım. Bu ürünlerin ortak parçaları (değişmeyen parçaları) mimarinin bir parçası değişen parçaları da Uygulamaya özgü parçalarıdır. Hemen bir örnekle açıklayalım; Örneğin bir uygulamada Konfigrasyon verisi okumak yada veritabanında bir işlem yapmak Uygulamanın değil mimarinin görevidir. Mimar bu işlemi yapacak olan standar methodları ve tipleri geliştirerek developer a sunar. Developer bu tipleri ve methodları kullanarak konfigrasyon verisini elde eder yada veritabanında işlemini yapar. Fakat developer konfigrasyon verisini nerden okuduğunu yada hangi veritabanına eriştiğini eriştiği veritabanının tipini versionunu bilmez. İhtiyacı olan veriyi elde etmek için optimum standartlıkta bir talepte bulunur. Böylelikle mimarın geliştirmiş olduğu bu yapılar ürün tipi değişse bile değişmeden kullanılacaktır.

Aşağıdaki UML şemasında bunun bir örneğini görmektesiniz.

 

Temel Tasarım Prensipleri;

1- Separation of Concerns (İlişkilerin Ayrılması) : Uygulamanızı mümkün olduğunca küçük fonksiyon parçalarına ve fonksiyon kümelerine bölmelisiniz. Burda önemli olan faktör uygulamadaki tüm bağlantı noktalarında  yüksek uyum ve gevşek bağlılıkta minimizasyona ulaşmaktır.Ancak fonksiyonların ayrılmasındaki yanlış sınırlar sonucun yüksek uyum ve karmışıklık arasındaki özellik hatta özellik içinde içerdiği işlevler içinde anlamlı bir biçimde örtüşmemelerini sağlamalıdır.

2- Single Responsibility (Tekil Sorumluluk):  Her komponent yada modül yanlızca bir tek spesifik görev yada  fonksiyonellikten yada fonksiyonellik kümesinden sorumlu olmaldır.

3- Princible of Least Knowledge (Min  Bilinirlik Prensibi): Uygulama katmanların birbiri ile etkileşirken birbirleri hakkında mümkün olduğunca az bilgi ve ilgi bütünlüğü ile etkileşmeleri ger
eklidir. Bu amaçlar çoğunlukla facade methodlar ve Interfaceler kullanılır.

Önemli olan log mekanizmasında logu yazan mekanizma ile logun içeriğini sağlayan mekanizma tek bir methodla etkileşip bilgi alışverişini sağlamalıdır. Loglama yöntemi ne kadar değişirse değişsin. Bu alışverişi sağlayan method bu değişimden asla etkilenmemelidir.

4- Don't Repeat Yourself (DRY) (Kendini Tekrar Etmeme):  Aynı görevi icra eden birden fazla yapı yada component olmamalıdır.

Abstract bir Class dan türeyen 2 class üzerinde abstract class da geliştirilmemiş bir fonksiyon ihtiyacı varsa bu iki class içerisinde de yazılmamalı yazılan fonksiyon abstract class a indirilmelidir.

5- Minimize upfront design (Açık Tasarımın Minimize edilmesi): Bazı durumlarda uygulamanın ön kısmında hemen UI kısmında tüm kodunuzu yazarak uygulamanızı geliştirirsiniz. Bu durumda geliştirme maliyetinin yüksek ve hata riskinin fazla olması kaçınılmazdır. ( Bu yönteme günümüzde buton altı programcılıkda diyorlar.) Bir başka durumda da özellikle Agile (Çevik) geliştirme süreçleri için ön katmanlarda geniş geliştirmeleri önlemelisiniz. Eğer uygulama gereksinimleriniz belirsiz yada tasarımınız zaman içerisinde sürekli  değişebiliyorsa, ön tarafta geniş tasarım oldukça efor ve maliyet gerektiren bir süreç olacaktır. Anahtar ilkemiz parçala ve yönet olmalıdır.

Bir uygulama yada sistem geliştirirken mimari manzara  karmaşıklığın farklı katmanlara doğru daha miminize edilmesi üzerine olmasıdır. Örneğin Kullanıcı arayüzü, iş katmanı ve veri erişimi görev ve sorumlulukları birbirinden bütünüyle ayrılmalıdır. Her parça ( Katman yada Component) sadece kendi görevine odaklanmalı ve farklı katmanların görev yada sorumluluğu içermemelidir. UI kesinlikle direk veri kaynağına (Veritabanına, dosyaya, konfigrasyon verisine ) erişmemelidir.

Tüm bu ilkeler bize daha yönetilebilir , kolay kurulabilen, hızlı test edilebilien ve min özelleştirme maliyeti ile sunulabilen ürünler uygulamalar geliştirmemize yardımcı olacaktır.

Bir sonraki yazımızda Uygulama Uygulama Tipine , Kurulum Stratejilerine ve diğer yardımcı parçaların tasarlanmasına nasıl karar verilmesi gerektiği konuları üzerinde duracağız. Her türlü sorularınızı mail adresim aracılığı ile paylaşabilirsiniz. Görüşmek üzere.


Tarık Gökhan Kızılırmak
tarikgokhan@gmail.com

Bu ve bundan sonraki yazılarımda. NET ile yazılım geliştirirken kullanmamız gereken referans yazılım mimarilerini ve bu mimarilerde kullanmamız gereken parçaları incelemeye çalışacağız.Amacımız bir fonksiyon yada kütüphaneyi anlatmak ve nasıl çalıştığını paylaşmaktan çok öte yöntem ve tecrübelerin sizlere aktarımıdır. Bu tecrübeler sadece bana ait tecrübeler olmayacak elbette Microsoft’un ünlü Mimari Takımı Pattern & Practices grubundan izler bulacaksınız yazılarımda.

İlk Sorumuzla işe başlayalım o halde; “Mimari nedir?” bu sorunun yeryüzünde pek çok cevabı vardır elbette ancak yazılım geliştirme senaryoları için en uygun olanı sanırım;
“Bir şeyin çalışmasını sağlayan sistemik, yapısal ve düzenli prensipler oluşturulması –- berrak olduğu için bilgilendiren bir ürünün, ya da fikrin, ya da politikanın itinalı üretimi (Richard Saul Wurman).”

Gerçekten de bir yapı tasarlanırken bu yapıyı oluşturan parçalar ve bunlar arasındaki uyum, yapı içerisindeki her parçanın görevini en iyi şekilde icra etmesi bütününü oluşturan mimarinin başarılı olması açısından oldukça önemlidir.

Günümüzde mimari kavramı yazılım sektörü için oldukça önem kazandı. Geliştirilen uygulamalar ve uygulamalar arası etkileşim büyüdükçe yazılan uygulamaların bazı temel prensipler doğrultusunda geliştirilmesi ihtiyacı doğdu. Projeler büyüdükçe yazılan kodun kalitesini yönetmek oldukça önemli bir sorun haline geldi. Aslında burada mevzu bahis olan sadece kalite de değil; Kalite, Güvenlik, Yönetilebilirlik, Değiştirilebilirlik ve performans kavramları çalışan uygulamalarda vazgeçilmez parametrelerdir.

Bahsettiğim parametreleri yönetmek için tüm yazılımcılarınızı aynı ve üst seviye bilgi ve beceri sahibi olmasını beklemek proje maliyetleri açısından oldukça negatif bir yaklaşım olacaktır. Ayrıca tüm yazılımcılarınızın aynı yazılım prensiplerini kullanarak yazılım geliştirmeye zorlamakta ve bunu denetlemekte oldukça güçtür.

Güvenlikle ilgili bir örnek vermek gerekirse; geliştirdiğiniz bir web uygulamasında yazılımcılarınızdan her Web Page in Load ında kullanıcının o sayfaya yetkili olup olmadığını kontrol eden kodu yazmasını beklemek ve bunu denetlemek oldukça zordur. Bunu uygulamanızın mimarisinde çözümlüyor ve Web Page düzeyinde kod yazan bir geliştiriciye bu sorumluluğu bırakmıyor olmanız beklenir.

Yazılım şirketleri açısından kaliteli ürün geliştirmek, geliştirilen ürünün pek çok farklı ihtiyaca sahip müşteriye en az özelleştirme maliyeti ile satılması oldukça önem kazanmaktadır.
Kilit noktamız farklı bilgi seviyesindeki yazılımcıları aynı projede çalıştırırken temel yazılım geliştirme prensiplerimizden vazgeçmemektir.

Günümüzde rekabetçi piyasa koşullarında bahsettiğim parametreler ışığında  kod yazma ve hızlı ürün geliştirme ihtiyacının karşılanması amacıyla şirketlerin kendi kod yazma kültürlerini ve kendi kütüphanelerini geliştirmektedir.

Mimarinin Amacı Nedir?

Mimarinin amacı, uygulamanın yapısını etkileyen ihtiyaçları karşılamaktır.

Bir mimar, tasarımla ilgili kararları verirken, parçalar arasında doğal etkileşimi düşünmelidir. Etikileşim  kullanıcı, sistem, ve iş isteklerine hitap etmeyi gerektirir. Talep edilen iş istekleri ile teknik ihtiyaçlar birbirinden ayrılmış olmalıdır. Geliştirdiğiniz mimaride iş istekleri değişiyor ama teknik ihtiyaçlarınızı karşılayan katmanlar değişmiyorsa başarılı bir altyapı geliştirilmiş olduğu söylenebilir.

Prensip; Uygulamanın değişen parçaları ile sabit parçalarını birbirinden ayrılmalı ve değişmeyen parça tekrar kullanılabilir şekilde tasarlanmalı mimariye bırakılmalıdır.

Temel Mimari İlkeleri:

Aşağıdaki Referans Mimari veri güdümlü bir uygulamanın olmazsa olmaz parçalarını içermektedir.



Referans Yazılım Mimarisi temel olarak 5 ana parçadan oluşmaktadır.

1- Presentation Layer
2- Services Layer
3- Business Layer
4- Data Layer
5- Cross – Cutting Konsept

Bu parçaların her biri ayrı birer makale konusu fakat bunları birer cümleyle özetleyelim.

1- Presentation Layer : Kısaca uygulama önyüzü olarak ifade edebiliriz. Kullandığımız bir Web Uygulaması yada Silverlight , Windows ,WPF uygulamaları Mobile uygulamalar raporlama çıktıların tamamı Presentation Layer dır. Kısaca Presentation Layer kullanıcı ile etkileşen önyüzdür.

2- Services Layer : Yapılan işlemlerin çıktılarını dış dünyaya ve Presentation layer a açtığımız servislerdir. .NET 3.x ile gelen WCF altyapısı sayesinde tam manasıyla SOA ( Services Orientede Architecture- Kavramın içerisini ilerleyen yaı) ‘ a uygun bir servis katmanı oluşturabiliyoruz.

Soru: Servis Katmanının uygulamamıza katacağı yetenek nedir ? Neden mimarimde Presentation Layer ile etkileşim kurmak için Servis katmanını kullanmalıyım? Cevap: Günümüzde yazılım geliştirme ve uygulama stratejilerinde uygulamaların birbirleri ile etkileşim ve bir sistemi kullanabilmek için ekranlara bağlı olmama ihtiyacı doğmuştur. Bu nedenle modern yazılım mimarilerinde Ekranlar (Presentation Layer) Servisler üzerinden uygulama ile iletişim kurması öngörülmektedir. Böylelikler her ekranın işlevini yapabilecek bir servisin varlığı da mümkün olacaktır.

3-Business Layer: Geliştirilen Uygulamanın Beynidir. Data Layerdan gelen veriler Uygulamanın Core Business yapısı tarafından yorumlanarak Services Layer yardımıyla Presentation Layer da son kullanıcıya sunulur. Tüm kritik algoritmalar bu yapı üzerinde barındırılır.

4-Data Layer: Geliştirilen uygulamanın kalbidir. İnsan vücudu için kan ne kadar önemli ise bir uygulama için veri aynı şeyi ifade eder. Data Layerin görevi Business layerdan gelen veriyi veritabanına kaydetmek, veritabanından yapılan sorgulamanın sonucunu da Business Layer a aktarmaktır.

5-Cross – Cutting Konsept: Konfigrasyon , Sisteme giriş doğrulama ve yetkilendirme işlemlerinin yapıldığı, istisnaların yönetildiği, Loglama işlemlerinin yapıldığı katmanlar bütünüdür. Cross Cutting Konsept birden fazla katmandan oluşmaktadır.

Bunlar ;

- Authentication
- Authorization
- Configration Management
- Operational Management
- Comminication
- Exception Management
- Logging and Insturmentation
- State Management
- Validation katmanlarıdır.

Belirttiğim bu parçaların her biri üzerinde 1-2 makale yazabileceğimiz derinlikte inceleyeceğiz. Bu makaleyi Yazılım mimarilerine giriş şeklinde ele aldım ancak girişi henüz tamamlamadık. Bir sonraki yazımda temel yazılım prensipleri ile ilgili önemli noktaları açmaya devam edeceğiz. .Her Konuda Görüş ve önerilerinizi mail atabilirsiniz. Görüşmek üzere.

Tarık Gökhan Kızılırmak
tarikgokhan@gmail.com

    Merhaba arkadaşlar uzun bir ayrılıktan sonra yeniden beraberiz. Gerçektende tarihi günler yaşıyoruz. Eğer insanlık tarihini birazcık olsun incelerseniz bir tekerleğin dahi  ne kadar uzun bir sürede bulunduğunu yazının bulunma ve gelişme sürecinde bir hayli uzun olduğunu görürsünüz. Ancak geride bıraktığımız yüzyıl insanlık adına son derece önemli buluşlarla şekillendi. Şimdi ise Adeta bir hayal dünyasında yaşıyoruz. yaşı 60ın üzerinde olan insanlar bu gelişmeleri hayretle izlerken biz gençler ise bu gelişen yeni teknolojileri öğrenmek ve kullanmak adına son derece hızlı hareket etme ihtiyacındayız. Öyle ki 1995 yılında geliştirilen bir teknoloji şu anda tarih oluyor. İşte XML dediğimiz bu kavramla Bilgisayar dünyasında kurallar ve yasaklar yıkılıyor. Öyle ki bir Bilgisayar programı yazıyorum bu programın bir tarafı bilgisayar üzerinde çalışan bir Windows Uygulaması  (windowapplication)  bir diğer parçası bir web uygulaması  başka bir kısmı da bir mobil uygulama olabiliyor. İşte bütün bu farklı teknolojileri .NET ile bir şemsiye altında toplayan temel taşımız nedir diye sorarsanız cevabım "XML" derim.  Çünkü  bütün bu platformlarda ortak bir standart haline gelmiştir. Böylece Kompleks   uygulamalar geliştirmek artık geleceğin kaçınılmaz ihtiyaçlarına cevap vermek adına bir zorunluluk haline gelmiştir. Bu yazımızda ise Windows uygulamaları üzerinde XML dosyaları üzerinde nasıl çalışılabileceğini anlatmaya çalışacağız. Konuyu VB. NET ve C# olarak ele aldım. .NET üzerine yaptığım her sohbette bana VB.NET mi C# mı kullanıyorsunuz diyorlar. Ancak ben her ikisini de kullanabiliyorum cevabını veriyorum.Her İki Dili de bilmek bir futbolcunun her iki ayağını da kullanabilmsi gibidir. Hem Sağ ayağın pratik ve çabukluğu (VB.NET) ve Sol ayağın muhteşem meziyetleri (C#).

       1-Bir XML Dosyası Oluşturmak:

Bir  XML Dosyası verinin Kendisidir. Bu nedenle verinin bir kabuk yapısı olmalıdır. Bir Notepad dosyası açarak içine bu kısmı kopyalayın. Biz üç veri grubunu XML dosyamızda saklayacağız. Personel Sicil Numarası-Adı soyadı-Görevi Şeklinde olacak.

xml version="1.0" encoding="utf-8" ?>
<isciler>

  isciler>

İsterseniz okumaya yada yazmaya geçmeden önce Bir Form tararımı yapalım. Formu Aşağıdaki gibi düzenleyiniz

       2- XML Dosyalarına Veri Yazmak:

 İster XML dosyasından veri okuyun. ister yazın XML  dosyasının  fiziksel varlığını algılayan ve diğer metotları ve işlemleri kendi üzerinden olusturan nesnemiz XMLDocument nesnesidir. Şimdi VB.NET dilini kullanarak Yaz adında bir prosedür oluşturacağız.

Public Sub Yaz()
Dim doc As New XmlDocument

doc.Load("C:\XMLFile1.xml")

Dim isci As XmlElement = doc.CreateElement("isci")

isci.SetAttribute("sicil", Val(TextBox1.Text))

Dim ad As XmlNode = doc.CreateNode("element", "ad", "")

ad.InnerText = TextBox2.Text

isci.AppendChild(ad)

Dim gorev As XmlNode = doc.CreateNode("element", "gorev", "")

gorev.InnerText = TextBox3.Text

isci.AppendChild(gorev)

doc.DocumentElement.AppendChild(isci)

doc.Save("C:\XMLFile1.xml")

End Sub

 

 

Bu Prosedürü C# ile yazmak istersek aşağıdaki kodları incelemenizi tavsiye ederim.

public void yaz()

{

                this.ListView1.Items.Clear();

                XmlDocument doc=new XmlDocument();

                doc.Load("C:\\XMLFile1.xml");

                XmlElement isci=doc.CreateElement("isci");

                isci.SetAttribute("sicil",TextBox1.Text);

                XmlNode ad=doc.CreateElement("element","ad","");

                ad.InnerText=TextBox2.Text;

                isci.AppendChild(ad);

                XmlNode gorev=doc.CreateElement("element","gorev","");

                gorev.InnerText=TextBox2.Text;

                isci.AppendChild(gorev);

                doc.DocumentElement.AppendChild(isci);

                doc.Save("C:\\XMLFile1.xml");

                this.yukle();

}

 

Yukarıda bu işin oluşunda kilit rol oynayan nesneler var öncelikle bu nesneleri size bir tablo halinde tanıtmak istiyorum.

 

Nesne Adı	Üretildiği Nesne	Görevi
XmlDocument		XML Dosyasıyla ilgili fiziksel bağlantıyı kurar ve üzerinde işlem yapılacak diğer nesneleri oluşturur. Bir nevi Connection nesnesine benzetilebilir. Ancak Connection nesnesinden çok daha farklı çalışır. Bağlantıdan çok daha fazla iş yapar.
XmlNodeList		XML üzerindeki Veri Yapılarını Listeler
XmlElement	XmlDocument CreateElement	Yeni bir Veri Yapısı (Satır oluşturur)
XmlNode	XmlDocument CreateNode	Yeni bir alt veri Yapısı (Satıra ait Sütun Oluşturur.)

 

 

 

 

 

 

       

 

       











İlk Olarak XML dosyamızın Yolu bulunuyor dosya açılıyor. Sonrasında Yeni bir XmlElement Oluşturuluyor. SetAttribute Yöntemiyle     tagına sicil isimli bir  Attribute ekleniyor.(Attribute ne olduğunu bilmeyen arkadaşlar Kasım Gülcan Arkadaşımızın ilgili yazısını okuyabilir) . Sicil Numarası bir Attributedır. Bizim HTML Taglarımızdaki "img" Tagının "src" özelliği gibi....

3- XML Dosyalarından Veri Okumak:

XML Dosyasından veri okumak için VB.NET ile aşağıdaki

Public Sub yukle()

ListView1.Items.Clear()

Dim s As String

Dim doc As New XmlDocument

doc.Load("C:\XMLFile1.xml")

Dim liste As XmlNodeList = doc.GetElementsByTagName("isci")

Dim isci As XmlNode = doc.CreateElement("isci")

For Each isci In liste

Dim x As Integer

x = Val(ListView1.Items.Count)

Dim sicil As String = isci.Attributes("sicil").Value

Dim ad As String = isci("ad").FirstChild.Value

Dim gorev As String = isci("gorev").FirstChild.Value

ListView1.Items.Add(sicil)

ListView1.Items(x).SubItems.Add(ad)

ListView1.Items(x).SubItems.Add(gorev)

Next

End Sub

Bu Prosedürü C# ile yazarsak:

public void yukle()

{

        ListView1.Items.Clear();

        XmlDocument doc=new XmlDocument();

        doc.Load("C:\\XMLFile1.xml");

        XmlNodeList liste=doc.GetElementsByTagName("isci");

        for(int i=0;i

{

                    & nbsp;       ListView1.Items.Add(liste.Item(i).Attributes["sicil"].Value);

                    & nbsp;       ListView1.Items[ListView1.Items.Count-1].SubItems.Add(liste.Item(i)["ad"].FirstChild.Value);

                    & nbsp;       ListView1.Items[ListView1.Items.Count-1].SubItems.Add(liste.Item(i)["gorev"].FirstChild.Value);

}

}

 

 

Bu Yazımızda salt bir XML dosyasından veri okuyup yazmayı inceledik XML konusundaki bir  sonraki yazımızda XML  verilerini Dataset içerisinde şekillendirmek ve XML ile Dataset üzerinden veri okumak üzerine olacak.Her Konuda Görüş ve önerilerinizi beklediğim bir mail adresim var.

  Tarık Gökhan Kızılırmak
tarikgokhan@hotmail.com