Framework Tabanlı Programlama

Hatırlayacağınız gibi bir önceki makalemizde, SQL komutlarının asenkron olarak yürütülmesi için kullanılan tekniklerden birisi olan polling modelini incelemiştik. Polling modeli basit olmakla birlikte, iş yükü fazla olan hacimli SQL komutlarının asenkron olarak çalıştırılmasında çok fazla tercih edilmemelidir. Bu tip sorguların yer aldığı asenkron yürütmelerde, CallBack veya Wait modellerini kullanmak verimliliği artırıcı etkenlerdir. Bu makalemizde CallBack modelini kısaca incelemeye çalışacağız.

Bir önceki makalemizde MARS etkisini incelemiş ve aynı bağlantı üzerinden birden fazla sayıda sonuç kümesine nasıl erişebileceğimizi görmüştük. Her ne kadar, aynı anda birden fazla sonuç kümesine erişebilsek de, hâlen MARS modeli, SQL komutları ile eşzamanlı çalışan kodlar ve asenkron yürütülebilen diğer SQL komutları için yeterli değildir. ADO.NET 2.0 ile, SQL komutlarını asenkron olarak yürütebileceğimiz birtakım yeni üyeler gelmektedir. Bu üyeler sayesinde, SQL komutlarını asenkron olarak çalıştırabilir ve hatta, diğer kod satırlarının da eşzamanlı olarak işleyebilmesini sağlayabiliriz. Bu işleri gerçekleştirebilecek üyeler şu an için sadece SqlClient sınıfında yer almaktadır. Ancak .NET Framework 2.0’ın final sürümünde bu üyelerin, diğer ADO.NET isim alanlarına da yerleştirileceklerini düşünüyorum.

Bu makalemizde, MARS (Multiple Active Results Sets) kavramını incelemeye çalışacağız. MARS kavramı ADO.NET 2.0 mimarisine monte edilmiş yeni bir yapıdır. Bu yapının bize sağladığı avantajları anlayabilmek için, ADO.NET 1.0/1.1 sürümlerinin kabiliyetlerine ve kısıtlamalarına kısaca bir göz atmak gerekmektedir.

Toplu güncelleştirme işlemleri, birden fazla SQL ifadesinin (insert, update, delete, select gibi) arka arkaya gelecek şekilde ancak tek bir seferde çalıştırılmasını baz alan bir tekniktir. ADO.NET 2.0 ile, toplu güncelleştirme işlemlerine daha fazla fonksiyonellik kazandırılmıştır. Bu koşul elbette ki toplu güncelleştirme işlemlerini destekleyen veritabanı sunucuları üzerinde geçerli olmaktadır. Şu an için, yönetimsel kodda yer alan Oracle ve SQL nesnelerinin desteklediği bu fonksiyonelliği kazanmak için aşağıda prototipi verilen ve SqlDataAdapter ya da OracleDataAdapter sınıflarına ait olan UpdateBatchSize özelliği kullanılmaktadır.

SQL Server’da bir veritabanı tablosundan, başka bir hedef tabloya veri taşıma işlemi bulk-data kopyalama olarak adlandırılır. Veritabanı yöneticileri çoğunlukla bu operasyonu gerçekleştirmek amacıyla, BCP adı verilen komut satırı aracını kullanırlar. Burada amaç, kaynak tablodaki satırların veya bir satır kümesinin farklı konumda olabilecek bir tabloya taşınmasıdır. Hedef tablo aynı veritabanında olabileceği gibi, diğer bir SQL sunucusu üzerindeki başka bir veritabanında da yer alabilir. ADO.NET 2.0’da SqlClient isim alanına eklenen yeni sınıflar yardımıyla bu işlemleri yönetimli kodda (managed-code) gerçekleştirme imkânına da artık sahibiz. Bu makalemizde, bu işlemleri gerçekleştirmek için kullanabileceğimiz yeni ADO.NET 2.0 sınıflarını incelemeye çalışacağız.

Bu makalemizde, veritabanlarında otomatik olarak artan identity alanlarının değerlerinin, çalışma zamanında uygulama ortamlarına nasıl yansıtılabileceğini incelemeye çalışacağız. Çoğunlukla, tablolarımızda yer alan satırların birbirlerinden kolayca ayırt edilebilmelerini sağlamak için, primary key alanlarını kullanırız. Genellikle bu alanları otomatik olarak artan sayısal değerler üzerinde yapılandırırız. Örnek olarak aşağıdaki tabloyu göz önüne aldığımızda, PersonelID alanının 1 sayısal değerinden başlayarak 1’er artan ve primary key özelliğine sahip olduğunu görürüz.

Bu makalemizde, CurrencyManager sınıfı yardımıyla, bağlantısız katman nesnelerinin işaret ettiği bellek bölgelerindeki veri satırları arasında navigasyon, satır ekleme, satır silme ve satır güncelleme işlemlerinin nasıl gerçekleştirildiğini incelemeye çalışacağız.

Bu makalemizde, uzak nesneler üzerindeki metodlara asenkron olarak nasıl erişebileceğimizi kısaca incelemeye çalışacağız. Remoting ile ilgili bir önceki makalemizde, çok basit hâliyle uzak nesnelerin, istemciler tarafından nasıl kullanılabildiğini incelemiştik. Geliştirmiş olduğumuz örnekte, uzak nesne üzerindeki metoda senkron olarak erişmekteydik. Yani, uzak nesnedeki metodun işleyişi bitene kadar, istemci uygulama kısa süreli de olsa duraksıyordu. Ancak bazı zamanlarda, uzak nesneler üzerinde işleyecek olan metodlar, belirli bir süre zarfında gerçekleşebilecek uzunlukta işlemlere sahip olabilirler. Böyle bir durumda istemci uygulamalar, metodların geri dönüş değerlerini beklemek zorunda kalabilirler. Oysaki, uzak nesneye ait metodlar bir yandan çalışırken, diğer yandan da istemci uygulamadaki izleyen kod satırlarının eşzamanlı olarak çalışması istenebilir. Bunu sağlamak için, uzak nesne metodlarına asenkron olarak erişilir.

Bu makalemizde, eşzamanlı olarak çalışan Transaction’larda meydana gelebilecek DeadLock durumunu incelemeye çalışacağız. Öncelikle DeadLock teriminin ne olduğunu anlamaya çalışalım. DeadLock, aynı zamanlı çalışan Transaction’ların, belirli satırları kilitlemeleri sonucunda ortaya çıkabilecek bir durumdur. DeadLock terimini kavrayabilmenin en iyi yolu aşağıdaki gibi gelişebilecek bir senaryoyu zihnimizde canlandırmakla mümkündür. Bu senaryoda söz konusu olan iki tablomuz mevcuttur. Bu tablolar SQL sunucusunda Northwind veritabanı altında oluşturulmuş olup field (alan) yapıları aşağıdaki gibidir.

Bu makalemizde, daha önceden değinmiş olduğumuz .NET remoting ile ilgili olarak çok basit bir örnek geliştirmeye çalışacağız. Remoting’de amaç, istemcilerin uzak nesnelere ait üyelere erişebilmelerini ve kullanabilmelerini sağlamaktır. Dolayısıyla, remoting sistemi söz konusu olduğunda, remote object, server channels ve client channels kavramları önem kazanır. Olaya bu açıdan baktığımızda ilk olarak bir remote object (uzak nesne) geliştirmemiz gerektiği ortadadır. Daha sonra, bu nesneyi kullanmak isteyecek istemcileri dinleyecek bir server programını yazmamız gerekir. Bu server programı aslında, remote object’i barındıran (host) bir hizmet programı olacaktır. İstemcilerin tek yapması gereken uzak nesneye ait bir örneği, çalıştıkları sistemde kullanarak bir proxy nesnesi oluşturmak ve bu nesne üzerinden server programa istekte bulunarak ilgili uzak nesneye ait metodları çalıştırmaktır. İşte bu noktada server ve client uygulamalardaki channel nesneleri önem kazanır.

Bu makalemizde, SQL izolasyon seviyelerinin, .NET uygulamalarında nasıl kullanıldığını incelemeye çalışacağız. Bir önceki makalemizde, izolasyon seviyeleri için söz konusu olabilecek 3 problemi ele almıştık. Bu olası problemler phantoms, non-repeatable read ve dirty read durumlarıdır. Eşzamanlı olarak çalışan Transaction’larda meydana gelebilecek bu problemleri, IsolationLevel numaralandırıcısı yardımıyla kontrol altına alabiliriz. Bu numaralandırıcının alabileceği değerler ve bu değerlerin izin verdiği, izin vermediği durumlar aşağıdaki tabloda yer almaktadır.

Bu makalemizde, Transaction’larda kullanılan izolasyon seviyelerini incelemeye başlayacağız. İzolasyon seviyeleri, eşzamanlı olarak çalışan Transaction’ların birbirlerini nasıl etkilemesi gerektiğini belirtmekte kullanılır. Yani bir başka deyişle, bir Transaction içinde meydana gelen değişikliklerin, başka eşzamanlı Transaction’lar tarafından nasıl ele alınması gerektiğini belirlememize olanak sağlar. İzolasyon seviyelerini anlamanın en iyi yolu, eşzamanlı olarak çalışan Transaction’larda meydana gelebilecek sorunları iyi anlamaktan geçer.

Bu makalemizde, ADO.NET ile gerçekleştirilen transaction işlemlerinde, SQL’de yer alan SavePoint’lerin nasıl uygulandığını incelemeye çalışacağız. SQL’de transaction işlemlerinde, her bir iş parçasından sonra gelinen noktanın birer SavePoint olarak kaydedilmesi sık rastlanan bir tekniktir. Bir transaction birden fazla iş parçasına sahiptir. Her bir iş parçasının başarılı olması halinde, tüm bu işlemler onaylanarak (commit) kesin olarak veritabanına yansıtılır. Diğer yandan, iş parçalarının herhangi birisinde meydana gelebilecek bir aksaklık sonucu transaction RollBack işlemini uygular ve tüm işlemler yapılmamış sayılarak veritabanı, transaction başlamadan hemen önceki hâline getirilir.

Bu makalemizde, .NET remoting sistemini anlamaya çalışacak ve .NET remoting sistemini oluşturan temel yapılar üzerinde duracağız. Öncelikle .NET remoting’in ne olduğunu ve ne işe yaradığını tanımlamakla işe başlayalım. Remoting sistemi, kısaca, farklı platformlarda çalışan uygulamalar arasında veri alışverişine imkân sağlayan bir sistemdir. Bu tanımda söz konusu olan platformlar farklı işletim sistemlerinin yer aldığı farklı ve birbirlerinden habersiz proseslerde çalışan uygulamaları içerebilir. Olayın en kilit noktası da, farklı sistemlerin veri alışverişinde bulunabilmelerinin sağlanmasıdır.

Bu makalemizde aralarında bire-çok (one-to-many) ilişki olan tablolar için hesaplanmış alanların, yani DataColumn sınıfının Expression özelliği ile oluşturduğumuz sütunların, tablolar arasındaki ilişkiler ile nasıl bir arada kullanılabileceğini incelemeye çalışacağız. Burada bir arada kullanımdan kastım, örnek olarak; ebeveyn (parent) tabloda fiziki olarak var olmayan ancak uygulamanın çalışması sırasında oluşturulacak bir sütundan, detay tablosundaki ilişkili alanlar üzerinden toplam, ortalama, miktar gibi Aggregate ifadelerinin çalıştırılmasından ve sonuçların yine parent tabloya yansıtılmasından bahsediyorum.

Bugünkü makalemizde, DataRelation sınıfı yardımıyla, veritabanlarındaki many-to-many (çoğa-çok) ilişkilerin, bağlantısız katmanda nasıl kullanılabildiğini incelemeye çalışacağız. İlişkisel veri tabanı modelinde, tablolar arası ilişkilerde çoğunlukla bire-çok (one-to-many) ilişkilere rastlarız. Ancak az da olsa, çoğa-çok ilişkilerin kullanıldığı durumlar da söz konusudur. Bu ilişkiye örnek olarak çoğunlukla, SQL sunucusunda yer alan Pubs veritabanındaki Authors ve Titles tabloları gösterilir. Bu iki tablo arasındaki ilişki şöyledir: bir yazara ait birden fazla kitap Titles tablosunda yer alabilir. Aynı şekilde, bir kitap birden fazla yazar tarafından kaleme alınmış olabilir. Bu bahsedilen iki ilişki de ayrı ayrı bire-çok ilişkilerdir. Yani bir yazarın birden fazla kitabı yazmış olması bire-çok ilişki olarak düşünülebilirken, bir kitabın birden fazla yazara ait olması da bire-çok ilişki olarak gözlemlenebilir.

Çoğu zaman, uygulamalarımızda T-Sql’in Aggregate fonksiyonlarını kullanarak, belirli sütunlara ait veriler üzerinden, toplam değer, en büyük değer, en küçük değer, ortalama değer vb. gibi sonuçlara ulaşmaya çalışırız. Bu amaçla T-Sql’in Avg, Sum, Count gibi Aggregate fonksiyonlarından yararlanırız. İşte bu makalemizde, bu fonksiyonları, DataTable sınıfının Compute metodu yardımıyla nasıl kullanabileceğimizi incelemeye çalışacağız.

Bu makalemizde, OleDbDataAdapter sınıfının olaylarını incelemeye çalışacağız. OleDbDataAdapter sınıfı aşağıdaki tabloda belirtilen üç önemli olayı içermektedir.

Bu makalemizde, OleDbDataAdapter sınıfının, veriler üzerindeki güncelleme işlemlerinin veri kaynağına yansıtılması sırasında nasıl bir rol oynadığını ve kullanıldığını incelemeye çalışacağız. Önceki makalelerimizde belirttiğimiz gibi, OleDbDataAdapter nesnesi yardımıyla veri kaynağından, uygulamalarımızdaki bağlantısız katman nesnelerine veri kümelerini aktarmak amacıyla Fill metodunu kullanıyorduk. Diğer yandan, bağlantısız katman nesnelerimizin temsil ettiği veriler üzerinde yapılan değişiklikleri veritabanına göndermek istersek, Update metodunu kullanırız.

Önceki makalemizde, OleDbDataAdapter sınıfının ne işe yaradığından bahsetmiş ve kısa bir giriş yapmıştık. Bu makalemizde, OleDbDataAdapter sınıfının diğer önemli unsurlarını incelemeye devam edeceğiz. İncelemek istediğim ilk konu, OleDbDataAdapter nesnesi yardımıyla, ilişkisel veritabanı modellerinden bağlantısız katmana aktarılan tabloların, sahip olduğu birincil anahtar (Primary Key) ve kısıtlamaların (Constraints) ne şekilde irdelendiği olacak. Konuyu iyice kavrayabilmek amacıyla aşağıdaki basit örnek ile incelememize başlayalım. Bu örneğimizde, SQL sunucumuzda yer alan bir tabloya ait verileri DataSet üzerine alıyor ve alınan alanların birtakım bilgilerini okuyoruz. Örneğin, alanların veri tipi, boyutu, null değerler içerip içermediği ve alan adları bilgilerini ekrana yazdırıyoruz.