Mart, 2015 | Bayram Üçüncü

Visual Studio Solution Template Oluşturmak

25 Mar

Visual Studio geliştirme aracında yeni proje oluşturma seçenekleri arasında proje türüne göre oluşturulmuş hazır şablonlar bulunmaktadır. Sunulan seçenekler Class Library, Console Application, Asp.Net, WCF v.s gibi uzayıp gider. Seçtiğimiz proje türüne göre bir çalışma ortamı otomatik olarak hazırlanır.

Ancak birbirine benzer projeler oluştururken solution içerisine sürekli aynı proje türlerini seçerek oluşturmak zorunda kalırız.

Örneğin bir web projesi için her defasında arayüz katmanı, veri katmanı, test katmanı gibi proje türleri seçilerek işleme başlanabilir. Bunun dışında da katmanlar vardır ama bu yazıda basit olarak üç katmanı ele almak anlaşılırlık açısında uygun olacaktır.

Bu gibi durumlarda kendi proje şablonumuzu olşuturabilirsek işimiz biraz daha kolaylaşmış olacaktır. Yapmamız gereken şey öncelikle bir solution oluşturarak gerekli proje türlerini bu solution içerisine dahil etmek olacaktır.

Bu proje şeklini bir şablon haline getirmek için File->Export Template seçeneğini seçerek ilerleyebiliriz.

Bu işlemin ardından My Exported Templates içerisine DataLayer.zip şeklinde bir dosya oluşturulduğunu görebiliriz. Bu solution içerisindeki tek bir katmana ait şablondur.

MyTemplate.vstemplate içerisinde oluşturduğumuz şablona ilişkin bilgiler bulunmaktadır. İçeriği xml şeklindedir ve istediğimiz şekilde düzenleyebiliriz. Bu işlemi solution içerisindeki tüm projelere uygulayıp oluşan *.zip dosyalarını tek bir şablon içerisinde birleştirebiliriz.

Export Template işlemi ile tüm projelere ait şablonları oluşturup *.zip dosyalarını bir klasöre çıkartalım.

Klasörlerin yanına Root.vstemplate şeklinde bir dosya oluşturmamız gerekmektedir. Adının ne olduğu önemli değildir. Önemli olan *.vstemplate uzantısına sahip olmasıdır. İçerik bilgisi ise şu şeklide olmalıdır.

TemplateContent içierisindeki ProjectCollection bölümünde daha önce tek tek oluşturduğumuz proje şablonlarını listeliyoruz. Icon olarak belirlediğimiz template.png dosyasını da aynı klasör içine kaydetmemiz gerekmektedir. Son olarak bu klasörü zip şeklinde sıkıştırarak kaydetmemiz gerekmektedir.

Artık oluşturduğumuz My Web Template.zip dosyasını Visual Studio Project Templates içerisine taşıyarak çalışır hale getirebiliriz.

Şimdi Visual Studio ortamında yeni proje eklemeyi deneyelim. Proje adını da ETicaret olarak belirleyelim.

Ve mutlu son!

Asp.net Web Api ve Content Negotiation Kavramı

20 Mar

Günümüzde artık internet dünyası sadece kişisel bilgisayarlarda internet tarayıcıları tarafından görüntülenebilen web sitelerinden oluşmuyor. Mobil cihazlar, Televizyonlar, Akıllı Evler Aletleri v.b gibi birçok cihaz artık internet aleminde kaynak tüketimine dahil olmuş durumdadır. Şüphesiz bu giderek daha da genişleyecek. Bu çeşitlilik karşısında artık internet dünyasına sunulan bilgilerin nasıl temsil edildiği öne çıkmıştır. Örneğin bir cihaz JSON veri tipiyle işlem yaparken diğeri XML veri tipini tercih ediyor olabilir. HTTP üzerinden kaynak tüketimi göz önüne alındığında verilerin temsili(representation) content negotaition kavramı ile bütünleşiyor.

Bir önceki yazıda HTTP protokolüne özel bir kavram olan Content Negotiation kavramından genel olarak bahsetmiştik. Bu yazıda ise content negotiation konusunu Asp.Net Web api tarafından incelemeye çalışacağız.

Asp.net Web Api teknolojisi Content Negotiation ile uyumlu çalışmaktadır. Ancak bu kavram Web Api teknolojisinin bir parçası gibi anlaşılmamalıdır. Content Negotation kavramı W3C(World Wide Web Consortium) tarafından tanımlanmış bir internet içerik standartıdır. RFC(Request For Comment) döküman numarası 2616‘dır.

Content Negotiation kavramı Asp.net Web Api tarafında, kullanıcıların talebine göre verinin hangi biçimde sunulacağını belirlemek için kullanılan sunucu odaklı bir çözüm yöntemi olarak kullanılmaktadır. Kullanıcılar talep ettikleri ortam döküman türlerini HTTP header bilgisi olarak belirleyebilirler. Talepteki Header bilgisi Web Api tarafından değerlendirilerek uygun şekilde bir cevap oluşturulur ve HTTP protokolü üzerinden kullanıcıya sunulur.

Web Api bir kullanıcının hangi niyetle kaynak talep ettiğini anlamak için talebin(HttpRequest) Header bilgilerini kontrol eder. Header bilgilerinde içerik ile ilgili kısımlar şu şekilde sıralanabilir:

Content-Type: API Burada belirtilen formatta veri sunar.
Accept: Kullanıcı burada kabul ettiği veri türlerini belirtir. (application/json gibi)
Accept-Charset:Kabul edilen karakter kodlaması. (UTF-8 gibi)
Accept-Language: Kabul edilen dil seçeneği. (en-us, tr-tr gibi)
Accept-Encoding:Kabul edilen içerik kodlaması. (gzip gibi)

Web Api uygulamasına Fiddlr gibi bir araç yardımıyla sorgulamalar yaparak durumu inceleyebiliriz.

Örneğin http://localhost:15063/api/values için bir talep gönderdiğimizde,

Web Api için oluşturulan talepte içerik bilgisine ait bir bildirim yapılmadı. Ancak sonucun JSON formatında geldiğini gözlemliyoruz. Bunun sebebi Web Api uygulamasının varsayılan olarak JSON formatında veri oluşturmasıdır.

Şimdi içerik talebini JSON değilde XML şeklinde istemeyi deneyelim. Bu durumda Content-Type: application/xml şeklinde bir Header bildirimi yapmamız gerekmektedir.

Dikat edecek olursak aynı URI üzerinden aynı kaynağa eriştiğimiz halde dönen cevap XML formatı şeklinde oldu. Yani kaynağın temsil ediliş şeklini HTTP Content Negotiation ile değiştirmiş olduk.

Farklı formatlarda veri alma talebini bir MVC uygulaması veya Web Froms ile yapmış olsaydık ya farklı URI üzerinden (sayfa veya action metod) oluşturacaktık, ya da aynı URI adresine parametre olarak kaynak türünü xml şeklinde belirtmiş olmamız gerekebilirdi.

Kullanıcılar Web Api uygulamalarına hangi türde veri kabul ettiklerini Accept header bilgisi ile bildirirler. Örneğin üç farklı formatta veri kabul ettiğimizi bildirecek olursak: Accept: application/xml, application/json, text/javascript

Bu durumda varsayılan değer olan JSON formatı şeklinde veri döner. application/json seçeneğini kaldırırsak bu sefer de XML veri döner.

Web Api tarafında medya tiplerine göre uygun içerik üretmek için Media Type Formatter sınıfları oluşturulur ve akışa dahil edilir. Eğer JSON veya XML gibi türler dışında kendi özel türümüzü oluşturmak istiyorsak System.Net.Http.Formatting.MediaTypeFormatter sınıfından türeteceğimiz sınıflarda istediğimiz veri formatlarını oluşturabiliriz.

HTTP Content Negotiation Kavramı

16 Mar

Content Negotiation işleyişi HTTP protokolüne özgü bir kavramdır. Anlam olarak tercüme edecek olursak, client ve server arasında yapılan bir içerik anlaşması veya müzakeresidir diyebiliriz. Amacı, aynı URI ile farklı döküman türlerinde içerik sunabilmektir. Yani daha genel bir ifadeyle kaynak gösterim şeklinin kullanıcılar tarafından belirlenmesi diyebiliriz. Content Negotiation ile ilgili resmi dökümanlar buradaki w3.org sayfasında bulunmaktadır.

Kullanıcıların sunucu kaynaklarına ulaşmak için kullandıkları internet tarayıcıları kendi yetenek türlerine göre kaynak türünü seçmek için HTTP protokolünde belirlenmiş olan kurallara uygun talepte bulunurlar. Örneğin bir X tarayıcısı JPEG dökümanlarını işleyebilecek yeteneği yoksa fakat PNG dökümanlarını işleyebiliyorsa sorgu sırasında bu isteğini HTTP Accept Header (istek başlığı) bilgisi olarak sunucuya iletir. Örneğin Accept istek başlığı ile sunucuya kullanıcının medya türü tercihini Accept:image/png şeklinde belirtir.

Burada Accept istek başlıkları superset/subset biçiminde temsil edilmektedir. Örneğin Accep:image/png örneğinde “image“ superset’tir, “png“ ise subset’tir.

Örnek medya türleri için Accept Header bilgileri:

Accept: application/json
Accept: image/png
Accept: image/*
Accept: text/xml

Accept istek başlığında birden fazla tercih de belirtilebilir. Örneğin:

Accept: text/html, text/xml, image/jpeg, */*

Burada talebi gönderen taraf text/html, text/xml, image/jpeg ile açıkça belirtilmiş medya türlerinin tercih ettiğini, bunun yanında */* ile farklı medya türleri varsa onları da kabul edebileceğini ifade etmektedir. Burada sunulan bir dizi medya türü vardır. Bu medya türlerine üstünlük katsayısı vererek öncelik tercihi yapmak da mümkündür. Örneğin:

Accept: text/html, text/xml, image/jpeg, */* ; q=0.01

Üstünlük katsayısı 1.0 ve 0.0 arasında bir değer alır ve “q” ile gösterilir. Burada text/html gibi üstünlük katsayısı belirtilmemiş türlerin katsayısı otomatik olarak 1.0 atanır. Ancak */* kalıbı 0.01 gibi düşük bir öncelik olarak belirlenmiştir.

İnternet tarayıcıları medya tiplerine göre kendi öncelik katsayılarını belirlerler. İnternet tarayıcıları kullanmadan fiddler gibi bir araç yardımıyla HTTP talepleri oluşturup, Header seçeneklerini kendimiz belirleyebiliriz.

Bir kaynaktan gelen dökümanın medya türü farklı olabileceği gibi dil seçimi de farklı olabilmektedir. Aynı şekilde Accept Header bilgisinde istediğimiz dili belirtebiliriz. Örneğin, Accept-Language: tr şeklinde.

İçerikle ilgili bir diğer Header bilgisi ise Content-Type şeklinde belirtilen ve kaynağa erişmek isteyen kullanıcının hangi medya türünde döküman istediğini bildiren içerik bilgisidir. Örneğin Content-Type:application/json şeklinde belirlenen bir Header bilgisi kullanıcının JSON veri istediğini belirtmektedir.

Günümüzde kaynak kullanımı sadece tarayıcılar tarafından değil, mobil uygulamalar tarafından da ağırlıklı olarak kullanıldığı göz önüne alındığında Content Negotiation kavramı özellikle REST servisler oluşturulurken dikkat edilmesi gereken konulardan bir tanesidir. Çünkü REST servisleri HTTP tabanlı çalıştıkları için servis geliştiriciler olarak HTTP dünyasını ve kurallarını iyi tanımamız gerekmektedir. Bu sayede neyi neden kullandığımızı bilerek ilerleyebiliriz.

.Net Framework Gelişim Tarihine Genel Bakış

7 Mar

Microsoft .Net Framework ile ilgili tarihi geçmişe bir göz atarak eskiden günümüze(2015) yani 4.5.1 framework sürümüne kadar nasıl bir gelişimin olduğunu genel hatlarıyla incelemeye çalışalım.

.Net Framework 1.0: 2002 yılında duyurulmuş ilk versiyonsdur. Visual Studio .Net geliştirme aracı ile birlikte sunulmuştur.

.Net Framework 1.1: 2003 yılında duyurulan bu versiyon ile birlikte Visual Studio 2003 geliştirme aracı da piyasaya sürülmüştür. .Net Framework 1.1 ile birlikte ilk defa Asp.Net Mobile control araçları denenmiştir. Ayrıca birden fazla ve farklı Framework sürümünü aynı bilgisayarda çalıştırabilme özelliği olan side-by-side özelliği eklenmiştir. Güvenlik ile ilgili yeni gelişmeler eklenmiştir.

.Net Framework 2.0: 2005 yılında Visual Studio 2005 geliştirme aracıyla birlikte duyurulmuştur. Bu framework ile birlikte Generic, Nullable tipleri, IPV6 desteği ve CLR 2.0 gibi önemli özellikler eklenmiştir.

.Net Framework 3.0: 2006 yılında duyurulmuş olup Visula Strudio 2005 üzerinden devam etmiştir. Bu sürüm ile birlikte WCF(Windows Communication Framework), WPF(Windows Presentation Framework), WF(Workflow Foundation) gibi yenilikler geliştiricilerle buluşturulmuştur. Bu yenilikler ile iletişim, sunum ve iş akışları gibi ayrımlar ilk defa belirgin bir şekilde altyapı olarak yapılmış oldu.

.Net Framework 3.5: 2008 yılında Visual Studio 2008 gelitirme aracı ile beraber duyurulmuştur. LINQ ve Addin/Plugin Model gibi özellikler eklenmiştir.

.Net Framework 4.0: 2010 yılında Visual Studio 2010 il birlikte duyurulan bu sürümde bir çok yeni özellik eklenmiştir. Parallel Computing, Code Contracts, Lazy Initializations, Dynamic Language Runtime, In-process side-by-side hosting, Background garbage collection ve CLR 4.0 şeklinde önemli eklemeler yapılmıştır.

.Net Framework 4.5: 2012 yılında Visual Sturio 2012 ile beraber duyurulmuştur. Paralel Programlama üzerinde yeni gelişmeler async/await yöntemi, asenkron işlemler, 64-bit platformlarda 2 gigabayt’tan (GB) büyük diziler için destek, Sıkıştırılmış dosyaların boyutunu azaltmak için Zip sıkıştırma işlevinde geliştirmeler yapılmıştır.

.Net Framework 4.5.1: 2013 yılında Visual Studio 2013 ile birlikte duyurulmuştur. Derlemeler için otomatik bağlama yeniden yönlendirme, .NET Framework güncelleştirmelerinden sonra daha hızlı uygulama başlatma, çok çekirdekli JIT geliştirmeleri ve ASP.NET uygulama askıya alma gibi ek performans artışları yapılmıştır. Sunucularda arka plan çöp toplama işlemi ile daha iyi performans sağlanmıştır.

Yazılım Proje Dizin Yapısı Oluşturmak

4 Mar

Projelerimizi oluştururken kendimize bir dizin standardı belirleyip, belirlediğimiz bu düzene sadık kalarak ilerlemek işlerimizi bir nebze kolaylaştıracaktır. Şu an için kodlama standartları gibi geleneksel bir standart yayınlanmamış olsa da programcıların yaygın olarak kullandığı bir dizin yapısı vardır. Bu dizin yapısına göre kaynak kodlar, dış kaynak kütüphaneleri ve dökümantasyon gibi kavramlar ayrı ayrı tutulmak üzere belirlenmiştir.

Bir çok açık kaynak projeyi indirip incelediğimizde bu yapıya benzer bir dizin ağacına rastlarız. Bu ağaçta belirtilen kavramlar:

doc: Kod ile ilgili dökümanların bulunduğu dizindir. Geliştiricinin karşılaştığı sorunlar, çözümler, resimler, ip ucu olabilecek kısa yollar v.s bu dizinde bulunur.
lib: Proje için gerekli olan dış kaynak kütüphaneleri bu dizinde bulunur. Örneğin Nuget paketleri, Github üzerinden indirilip referans alınabiliecek başka kaynak kodlar.
src: Porjemizin kaynak kodunu barındırdığımız yer bu dizindir. Örneğin Visual Studio Solution veya Eclipse projesini bu dizine olşutururuz.

Yukarıda lib dizininde dış kaynaklı kütüphanelerin bulunacağını belirtmiştik. Burada Visual Studio ile çalışanların Nuget paketlerini otomatik olarak lib dizinine indirebilmesi için gerekli bir ayar yapılmalıdır. Proje kaynak kod dizini içerisine yani yukarıda ki şemada src olarak adlandırılmış olan dizine nuget.config adında bir ayar dosyası oluşturulmalıdır . Bu ayar dosyasına şu satırları eklemek yeterlidir.

<settings>
    <repositoryPath>..\lib</repositoryPath>
</settings>

Artık Nuget Package Manager tarafından indirilen dosyalar doğrudan lib dizinine kaydedilir.

Bu yapıda oluşturulan çalışmaları versiyon kontrol sistemlerine derli toplu bir şekilde aktarmak mümkün hale gelmektedir.

NOT: Bu ayarlar Visual Studio 2013 üzerinde başarıyla denenmiştir. Sonraki çıkacak versiyonlarda bu ayarların değişme olasılığı vardır.