Asp.Net Web API ve Mimari Özellikleri Kitabım Yayında!

By Burak TUNGUT - 22.08.2016 - Kategori Genel

Merhabalar herkese,

Güzel bir haber ile sizlerle beraberim. 6. baskıyı geçen ilk kitabım Algoritma ve Programlama Mantığı'ndan sonra eski iş arkadaşım Gökhan Gökalp ile birlikte bir kitap projesini ve videolu eğitim setlerini tamamladık.
Beraber yazdığımız bu kitabın tam ismi ise Asp.Net Web API ve Mimari Özellikleri şeklinde oldu.

Bir çok çalışma arkadaşımızdan aldığımız feedback'ler sonucu kitabımızı gereksiz ve birbirini tekrar eden örnekler ile değil, farklı, yeterli örnek ve konu ile donattık. Umarım belirlediğimiz bu strateji ile ortaya çıkardığımız kitabımızı beğenirsiniz.

Çevremizde ve bazı blog yazılarımızda aslında bu çalışmadan söz etmiştik. Özellikle bekleyen ve sıklıkla mail atıp ne zaman biteceğini soran tüm okurlarımızada teşekkür etmek isterim.

Kitabımızı internetten sipariş etmek için aşağıdaki linkleri kullanabilir ya da D&R şubelerini ziyaret edebilirsiniz.

 

Asp.Net Web API ve Mimari Özellikleri Burak Tungut Kitap
Asp.Net Web API ve Mimari Özellikleri Burak Tungut Kitap Sipariş                

 

Asp.Net Web API ve Mimari Özellikleri Burak Tungut Kitap Sipariş         

 

 

Alıştığınız teknoloji kitaplarının aksine farklı ve yeterli sayıda örneklerle donatılmış bu kitap ile Asp.Net Web API’yi tanımaya hazır mısınız?

Asp.Net Web API, Microsoft tarafından open-source olarak geliştirilmekte olan ve HTTP protokolünü kullanarak RESTful web servisler yazmanızı sağlayan bir uygulama çatısıdır. .Net platformu içerisinde önemli bir yere sahip olan bu teknoloji, birçok büyük projede kullanılmakta ve kullanımı gittikçe artmaktadır.

Bu kitap ve videolu eğitimleri ile sadece Web API’yi öğreniyor olmayacaksınız. Bunun yanı sıra Web API gibi bir teknolojinin esnek ve ölçeklendirilebilir mimariler ile profesyonel anlamda nasıl kurgulanabileceğini öğreneceksiniz. Ayrıca yazılım geliştirme süreçlerinde, olası karşılaşabileceğiniz sorunlara nasıl çözüm üretebileceğinizi de pekiştireceksiniz.

  • HTTP Protokolü
  • RESTless - RESTful
  • Multi Threading
  • .Net Task Library
  • Web API Mimarisi
  • Hosting Tipleri
  • IController ve ApiController
  • Entity ve CRUD Metodlarının Yazılması
  • IHttpController Implementasyonun Yapılması
  • HttpGet Metodu
  • Result Conversion
  • Routing ve Çeşitleri
  • Media Type Formatter’lar
  • Web API’da Media Type Formatter
  • Web API’da JSON ve XML Serialization
  • JSON Media Type Formatter
  • XML Media Type Formatter
  • JSON veya XML Formatter’ı Kaldırmak
  • Circular Reference Handling
  • Request Filtering
  • IFilter ve IActionFilter Tipleri
  • Web API’de Authentication
  • Web API’de Exception Handling
  • Inversion of Controler Container
  • Model Validation
  • Parameter Binding
  • Controller Selection Mekanizmaları
  • Handler’lar
  • Message Handler İşleyiş Mekanizması
  • DelegatingHandler Tipi
  • Web API Request-Response Pipeline
  • Global Exception Handling
  • IExceptionHandler Implementasyonu
  • ve Daha Fazlası
Devamı

Asp.Net Core Application Startup - Configure ve ConfigureService Methodları Nedir? Neden Kullanılır?

By Burak Tungut - 16.07.2016 - Kategori Asp.Net Core

Selamlar herkese,

Geçen haftaki yazımızda Asp.Net Core'a bir giriş yapmış ve ne gibi özelliklerin bizleri beklediğini incelemiştik. Bugünkü yazımızda Startup sınıfını, Configure ve ConfigureServices method'larını ve ne gibi özelliklere sahip olduklarını inceleyeceğiz.

İncelemeleri yaparken göreceğimiz ve yer yer kullanacağımız bazı tip ve özellikler aslında bu makalenin konusu değil. Bu nedenle ilgili konular hakkında detaylara bu makalede yer vermedim. Ancak bu serinin devamını oluşturacak olan makalelerde, bu konulara ait detayları çok yakında görüyor ve inceliyor olacağız :)

Hatırlarsanız Asp.Net Core Nedir? Ne Gibi Değişiklikler Bizi Bekliyor? başlıklı yazıda boş bir Asp.Net Core uygulaması yaratmış ve Program.cs sınıfını biraz incelemiştik. Yine hatırlarsanız builder pattern ile uygulamayı inşaa ettiğimiz WebHostBuilder tipine ait generic UseStartup method'u mevcut idi. Generic tip ile uygulamamızdaki Startup sınıfını (tipini) alıyordu. Gelin sırasıyla bunları bir tanıyalım;

Startup Sınıfı (Tipi)

Startup sınıfı diye bahsediyoruz ancak ismini Startup harici bir isim ile de değiştirebiliriz. Özelliği bir Asp.Net Core uygulamasının ayağa kalkmasını sağlamak olduğu için yani görevi / işlevi nedeniyle Startup ismini kullanıdığımızı söyleyebiliriz.
Startup sınıfı aslında uygulamanın başlangıç noktası olarak görülebilir. Her Asp.Net Core uygulamasında mutlaka olmalıdır. UseStartup generic method'u kullanılmadan oluşturulmaya çalışılan bir Asp.Net Core uygulaması runtime'da aşağıdaki gibi bir hata ile karşılaşacaktır;

UseStartup methodu olmayan bir Asp.Net Core uygulaması

Yine daha önce Asp.Net Core'un lightweight built-in bir dependency injection ile geldiğini söylemiştik. Instance'ı yerine generic bir method ile Startup sınıfının tipini veriyor olmamızın bir nedeni de bu. Runtime'da DI tool'u bizler için Startup sınıfını ilgili tipten üretir. Yine bu nedenle Startup sınıfının constructor method'unda resolve olmasını istediğimiz ve DI'a register edilmiş tipleri parametre olarak dahil edebiliriz.

Bahsettiğimiz bu tipleri birazdan Configure ve ConfigureServices method'larında kullanıyor olacağız. Bu method'lar ise Startup sınıfının içerisinde bulunması gereken method'lardır. Boş bir Asp.Net Core uygulamasına ait Startup sınıfı aşağıdaki gibidir;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
    }


    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.Run(async (context) =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    }
}

Şimdi bu iki method'u sırasıyla tanıyalım.

Devamı

Asp.Net Core Nedir? Ne Gibi Değişiklikler Bizi Bekliyor?

By Burak Tungut - 10.07.2016 - 2 Yorum - Kategori Asp.Net Core

Selamlar herkese!

Bir Ramazan bayramını daha geride bıraktık. Umarım herkes için güzel bir bayram olmuştur. Herkesin geçmiş bayramını kutlamak isterim :)
Beni soracak olursanız sadece 2 gün tatil yapabildim. Asıl tatilimi bir kaç hafta sonraya bırakıyorum.

Bayram tatiline çıkmadan bir kaç hafta önce Microsoft tarafında harika gelişmeler oldu diyebilirim. Uzun zamandır ben ve çoğu meslektaşım Asp.Net 5'in gelişmelerini takip ediyorduk. Hatta kulaklarını çınlatayım Yiğit ile her yeni gelişmeyi şirketin Slack kanalından paylaşıp uzun uzun tartışıyorduk. Sonra bir haber aldık ki "Asp.Net 5 Öldü". Hatta bu başlıkla bazı paylaşımlar yapıldı, Scott Hanselman'ın blog'un da dahi bulabilirsiniz.
Tabi ölen bir şey yok aslında. Sadece bu yeni mimarinin adını değiştirmeye karar vermişler. Artık .Net Core ve Asp.Net Core olarak isimlendireceğiz bu teknolojileri. 

Bu yazımı biraz sohbet havasında geçirmek istiyorum çünkü çok çok detaylı konulara değinmeyeceğiz. Asıl amacım bu yazıda Asp.Net Core'a bir giriş yapmak, ne olup, ne olmadığı hakkında bilgiler verebilmek. Yer yer official dökümanından alıntılar / çevirilerde bulabilirsiniz. Umarım çeviri yapmama çok kızmazsınız :) Giriş niteliği taşıyan bir yazıda ne kadar yaratıcılık beklenir ki :) ?

Asp.Net Core Nedir?

"Evet şimdi kitaplarımızın 18. sayfasını açıp tanımı okuyalım. Kim sesli okumak ister?" tadında bir giriş yapmayacağız tabi ki :)
Asp.Net Core aslında Asp.Net (ve .Net Framework) 'in yeniden dizayn edilerek bir çok konseptin değiştirildiği yep yeni bir teknoloji. Üstelik cross-platform çalışabilmek üzere geliştirilmekte. Diğer bir deyiş ile uygulamalarınızı sadece IIS'te Windows bir makinada host etmek zorunda değilsiniz. İsterseniz Linux'ta hatta Mac'te dahi host edebilirsiniz.

Terimlerde karışıklık olmaması adına şöyle bir not düşmek isterim;

.Net Framework bir uygulama çatısı iken, Asp.Net onun üzerine kurulmuş ve web uygulamaları yapmamızı sağlayan bir teknoloji (ya da framework diye de nitelendirebiliriz)
.Net Core ise tıpkı .Net Framework gibi bir uygulama çatısı iken Asp.Net Core onun üzerine kurulmuş ve yine web uygulamaları yapmamızı sağlayan bir teknoloji.

Halilye karşılaştırmalara yer verdiğimiz noktalarda eğer Asp.Net Core'dan bahsediyorsak karlılaştırdığımız nokta Asp.Net'te ki hali ve .Net Core'dan bahsediyorsakta karşılaştırdığımız nokta .Net Framework olacak.

Asp.Net Core Mimarisi

Asp.Net Core açık kaynak olarak geliştirmekte. Amacı ise Asp.Net'te geliştirebildiğiniz projeleri yine geliştirebilirken IoT ve cloud bazlı projelerinizi daha efektif ve esnek bir şekilde geliştirebilmek. Efektif ve esnek diyorum çünkü hali hazırda var olan .Net Framework ve Asp.Net ile de zaten IoT ve cloud bazlı projeler geliştirebiliyorsunuz. Ancak .Net Core'un getirdiği ve değiştirdiği bazı geleneksel yaklaşımlar sayesinde tüm bunları daha efektif ve esnek yapabiliyor, çok daha performanslı uygulamalar geliştirebiliyorsunuz.

Çünkü Asp.Net Core optimize edilebilir bir mimariye sahip. Asp.Net'e göre karşılaştırdığımızda sadece "Hello World" yazabilmek için dahi onlarca referansa ve System.Web'e bağımlı değilsiniz. Projenizin ihtiyacına göre pipeline'i zenginleştirebiliyor, istediğiniz modülleri NuGet üzerinden dahil edebiliyorsunuz.

Nasıl ki ORM kullanmak istediğiniz bir Asp.Net uygulamanıza NuGet üzerinden EntityFramework'ü referans olarak ekleyebiliyorsanız artık Asp.Net Core ile IIS'in dahi bağımlılığını NuGet üzerinden ekleyebileceksiniz. Daha önce duymadıysanız ilk benden duyun, artık IIS'e bağımlı değilsiniz :)

Official dökümanda bulacağınız bazı kök değişiklikleri aşağıda listeledim. Bir çoğuna ilerleyen yazılarımda detaylarıyla değineceğiz.

Devamı

SOLID Prensipleri : 03 Liskov Substitution Principle

By Burak Tungut - 15.06.2016 - 2 Yorum - Kategori Design / Architectural Patterns

Selamlar herkese,

Son 1 haftadır bazı çalışma arkadaşlarımın "Yazmaya neden ara verdin?" tepkilerine daha fazla dayanamıyor ve bu yazımızda SOLID prensiplerinden Liskov Substitution - Liskov'un Yerine Geçme prensibini inceliyor olacağız. Yazmam için sürekli beni dürten sevgili çalışma arkadaşım Barış BIYIK'a teşekkürlerimi buradan da iletmek isterim :)

Liskov Substitution aslında Prof. Barbara Liskov ismindeki bir bilim insanının tasarladığı bir prensip.
Prensip bize der ki ;

"Aynı base sınıftan üretilen tüm alt sınıflar, birbirlerinin yerine kullanılabilir olmalıdır. Alt sınıflara özel bir istisnai durum kesinlikle oluşmamalıdır."

Bazen abstract class'lar ile interface'ler arasındaki farkın ne olduğuna dair sorularda alıyor olabilirsiniz. Aslınd bu prensibin amacı bu iki tip abstraction yapmamızı sağlayan tip arasındaki en büyük farkı göstermekte. Birazdan yapacağımız örnek ile bunu çok daha iyi anlıyor olacağız.

 

Liskov Substitution Principle

 

Küçük Bir Senaryo İle Liskov Substitution Principle

Farz edelimki ürünlerin ve ürünler üzerinde çeşitli business'ları işletebilecek üyelik tiplerinin olduğu bir proje geliştiriyoruz. Çok minimal bir ürün tipi tasarlayalım. Ben aşağıdaki gibi bir şeyler tasarladım;

public class Product
{
    public string Name { get; set; }
    public decimal Price { get; set; }
    public List<string> Features { get; set; }
}

Devamı

Gerçek Hayattan Factory Method Design Pattern Örneği

By Burak Tungut - 05.06.2016 - Kategori Design / Architectural Patterns

Selamlar herkese,

Bu yazımda sizlerle gerçek bir uygulama ile Factory Method Design Pattern'in nasıl uygulanacağını paylaşacağım. Geçtiğimiz aylarda üzerinde çalıştığımız ana modüllerimizden birinde sürekli benzer istek ve değişikliklerin geldiğini fark ettik. Uygulamada ki genel gidişimizde sürekli if-clause'lar üzerine dayanmaya başlayınca buna bir dur demek istedik ve biraz sonra sizlerle paylaşacağım bir geliştirme gerçekleştirdik. Dilerseniz uygulamaya geçmeden önce ihtiyacın ortaya çıkmasına sebep olan istekleri biraz inceleyelim.

Not : Makale aşağıda listelediğim bazı konuları içerir. Aşağıdaki konular hakkında bilgi sahibi iseniz harika! Değilseniz makalenin daha anlaşılabilir olabilmesi için bir kaç saatinizi ayırarak önce bu listeyi halletmenizi önemle rica ediyorum :)

  • Thread Safety
  • Stateless-Stateful
  • Principal & Identity
  • Reflection

"Backend'i Aynı Olsun, Frontend'i Farklı"

Geliştirmekte olduğumuz bir ürünümüz başlangıçta bir kullanıcı tipine sahip iken iş birimlerimizden bu tiplerin çoğalacağı haberlerini aldık. Fakat her kullanıcı aynı veriye erişirken, verilerin gösterim biçimleri farklı olacaktı. Benzetmek gerekirse uygulamada kullanıcı tipi farketmeksızın herkes beş adet ürün görecek lakin kimi kullanıcı tipleri bunları slider ile görecek iken kimileri bir table içerisinde görecekti.

İsteğe çevik bir şekilde cevap vermek adına geliştirmeleri tamamladık. Lakin MVC projemizde fark ettik ki Controller ve Action'larımız hiç değişmez iken bunları execute ettiği View'larda sürekli if blokları yazmak durumunda kaldık. Tıpkı aşağıdaki gibi;

<h2>Product</h2>

@if (userType == FactoryMethod.Core.UserType.New)
{
    <b>Slider ile datayı görüntüle</b>
}
else if (userType == FactoryMethod.Core.UserType.Old)
{
    <b>Table ile datayı görüntüle</b>
}

Bu if-clause'ları View'dan alıp Action'lara koyarsakta çok bir değişiklik olmayacaktı. Buyrun bakalım;

public class ProductController : Controller
{
    UserType userType = UserType.Old;

    public ActionResult Index()
    {
        //Business call

        if (userType == UserType.New)
        {
            return View("IndexOfNewUsers.cshtml");
        }
        else
        {
            return View("IndexOfOldUsers.cshtml");
        }
    }
}

Bu iki yapının arasında kalsak ben kesinlikle ikinci olanı seçerdim. Sonuçta tüm business ve backend aynı iken sadece frontend değişiyor ise View'ları ayıralım. Hangi View'ın execute edileceğine ise bir önceki pipeline katmanında karar verelim.

Başka Kullanıcı Tipleri Eklenmeye Devam Ederse?

Son yaptığımız haliyle uygulama daha kabul edilebilir bir hal alabilir. Fakat bu yapıyı inşaa etmemize neden olan istekler gelmeye devam ederde yeni kullanıcı tipleri eklenmek isterse sürekli her Action'a if blokları mı yazacağız? İşte bu noktada artık bir dur dememiz gerekir.

Bizim artık öyle bir yapıya ihtiyacımız var ki ne View ne de Action bir state'e bağlı olsun. Yani stateless olsun. Action'ımız Business Engine'ler ile konuşsun, gerekli model'i intialize etsin ve View'a versin. View'da asla business içermesin gerekli veriyi istendiği gibi göstersin.

O zaman bu stateless olarak belirlediğimiz scope'un dışında kullanıcı tipine (ya da herhangi stateful bir olgu) göre akışı değiştirecek, ilgili View'ı bulup execute edecek bir yapıya ihtiyacımız var. 

Biraz detaylıda olsa problemimizi tanıdığımıza göre gerçek bir uygulama ile sorunumuzu çözmeye başlayabiliriz.

Devamı
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Facebook