ASP.NET Core – Genel Yapı Hakkında Bazı Notlar: Application Pipeline, Middleware, Services, Host Yapısı

.NET Core, Microsoft’un çarpraz platform ve açık kaynak yeni .NET çatısı. .NET Framework çekirdeğini yeniden ele alarak yazılan ve temel bir .NET Framework uyarlaması olan .NET Core’un resmi sürümü birkaç gün önce(27 Haziran’da) duyuruldu.

.NET Core üzerinde şu an konsol ve web uygulamaları geliştirilebiliyor. ASP.NET Core bu ortam üzerine inşa edilen web uygulama geliştirme çatısı. .NET Core gibi cross-platform, dolayısıyla Linux ve Mac işletim sistemine sahip cihazlarda geliştirme yapılabiliyor ve web uygulamaları host edilebiliyor.

Bu yazıda ASP.NET Core’un genel yapısı hakkında bazı bilgiler paylaşmaya çalışacağım. .NET Framework üzerinde yıllardır web uygulamaları geliştirmiş yazılımcılar için ne gibi yeniliklerin ve farklılıkların olduğunu da yazı içerisinde görmüş olacağız.

İlk olarak şu noktaya değinelim; nasıl ki .NET Core .NET Framework’ün devamı değilse, ASP.NET Core da ASP.NET MVC veya ASP.NET Webforms’un devamı değil. Benzer kütüphaneler üzerinde çalışıyor olsa da tamamen farklı bir çatı, farklı bir SDK, farklı bir pipeline ve farklı uygulama host yapısına sahip ASP.NET Core uygulamaları. ASP.NET Core uygulamaları MVC tasarım kalıbıyla geliştirildiği için ilk bakışta ASP.NET MVC uygulamasıyla oldukça benzer gelecektir. Detayları konuştukça aradaki farklar da anlaşılacaktır. Detaylara bakmaya başlayalım.

Modüler Yapı, Application Pipeline ve Middleware

ASP.NET Core tamamen modüler yapıda ve çoğu bileşeni tak-kullan mantığıyla uygulamanıza dahil edebiliyorsunuz. Başlangıçta tüm bileşenlerden arınmış, en yalın haliyle çalışmaya hazır bir web uygulama yapısı var. İhtiyacınız olan bileşenleri uygulama başlangıcında pipeline’a dahil ederek kullanabiliyorsunuz. Uygulamayı host edecek web server, hata yakalama mekanizması, hata sayfası yönetimi, statik dosyaların kullanılması, authentication mekanizması, URL routing… bu saydıklarımız ve daha fazlası başlangıçta yalın bir ASP.NET Core projesinde bulunmuyor, siz hangi modülleri kullanmak isterseniz onları projenize dahil ediyorsunuz ve kullanıyorsunuz.

Bu özellik ASP.NET Core uygulamasının en az donanımla ve en az bileşenle çalıştırılmasına olanak sağlıyor. Yani uygulamanız sadece belirli bir port üzerinden gelen HTTP request’ini yakalayıp, araya hiçbir mekanizma, bileşen vs. girmeden bu request’e <p>Merhaba Dünya</p> gibi bir response(veya JSON bir çıktı) gönderebiliyor. Bu da performans ve hız konusunda ciddi avantajlar sağlayabiliyor. Günümüzde bilhassa bazı Web API uygulamalarında bu tarz minimum donanıma sahip yapılar tercih edilebiliyor.

Bu yapı WebForms veya ASP.NET MVC gibi güçlü ve donanımlı yapılar üzerinde uygulama geliştiren, bir başka deyişle herşey elinin altında olan yazılımcılar için biraz yadırganabilir. “Bir de bu tarz modülleri projeye dahil etmekle mi uğraşacağız…” gibi bir soru işareti aklınıza geliyorsa hiç düşünmeyin, bu modülleri uygulamaya entegre etmeniz Startup.cs dosyasına birkaç satır kod yazmanıza bakıyor.

ASP.NET Core’da yukarıda bahsettiğimiz ve uygulamaya sonradan eklenen statik dosya yönetimi, authentication mekanizması, URL Routing… gibi bileşenlere Middleware adı veriliyor. Middleware bileşenlerini ASP.NET’teki HttpModule nesnelerine benzetebiliriz. Middleware bileşenleri aynı zamanda ASP.NET Core uygulamasının application pipeline’ını belirliyor. Uygulama başlangıcında runtime’a eklenen middleware bileşenleri, eklendiği sıraya göre pipeline’ı oluşturmakta ve bir request geldiğinde bu sıraya göre tüm bileşenler çalışmaktadır. Eğer middleware bileşeni yaptığı kontrollerde bir sorunla karşılaşırsa request’i kesip sonlandırabiliyor veya herşey yolunda gidiyorsa sırasını salıp kendisinden sonraki middleware bileşenine yol veriyor.

Projelerde varsayılan olarak gelen Startup.cs dosyasındaki Configure metodunda IApplicationBuilder nesnesi üzerinden erişilen UseIdentity(), UseExceptionHandler(), UseMvc() gibi metotlar çağrılarak middleware bileşenleri pipeline’a dahil ediliyor. Sistemde bulunan bu bileşenlere ek olarak kendimiz de custom middleware bileşenleri yazabiliyor ve ASP.NET Core pipeline’ından bu bileşenlerin bulunmasını sağlayabiliyoruz. Olayın özü bu, tabii ki biraz daha derine inildiğinde bu metotlara parametre olarak bazı ayarları geçmemiz ve detaylandırmamız gerekebiliyor.

Service Yapısı ve Dependency Injection

Nesneler arasında bağımlılık oluşturan yapıların birbirinden soyutlanması ve aralarındaki bağımlılıkları en aza indirme yaklaşımına Dependency Injection diyoruz. Çoğunuzun bu konuda bilgisi vardır diye düşünüyorum, bilgisi olmayan veya konuya tam hakim olmayanların şu yazıya göz atmalarını tavsiye ederim.

ASP.NET Core’daki temel nesnelere ve bileşenlere Dependency Injection mekanizmasıyla erişip yönetiyoruz. Bu iş için zaten .NET Core ile gelen ve minimum donanıma sahip bütünleşik bir DI kütüphanesi bulunuyor. ASP.NET Core’un yapısındaki interface ve class’lar bu DI aracı ile inject edilebildiği gibi, kendi geliştirdiğimiz interface ve class’ları da bu yapı üzerinden yönetebiliyoruz.

Webforms ve MVC projelerinde zorunlu olmayan ve ihtiyaca göre projelere dahil ettiğimiz DI yapısı, ASP.NET Core’da varsayılan olarak gelmekte ve artık geliştirme hayatımızın tam merkezinde yer almakta. Startup class’ındaki metotlara ve Controller’ların constructor metotlarına bu tipleri doğrudan bağlayarak kullanmak bu ortamdaki geliştirme hayatımızın artık doğal bir parçası.

Dependency Injection ile ilgili son olarak şu notu da düşelim; .NET Core ile gelen bu light-weight DI aracının yerine istersek Unity, Autofac gibi harici DI araçlarından birini kullanabiliyoruz.

DI ile register ettiğimiz ve proje genelinde kullandığımız yapılara ASP.NET Core’da Service adı veriliyor. Framework bünyesinde bulunan temel tiplere inject ettiğimiz servislere framework servisleri, kendi geliştirdiğimiz yapılara ise application(uygulama) servisleri adı veriliyor. Framework servisleri Startup.cs dosyasındaki ConfigurationServices metodunda, metoda parametre olarak gelen IServiceCollection nesnesi üzerinden register ediliyor. Application servisleri de genellikle bu metotta register edilmekte, ama özel durumlarda farklı yerlerden de bu servisler projeye dahil edilebilir.

Application Startup

ASP.NET Core, uygulama başlangıcı ve çalışması açısından da yeni bir yapıyla geliyor. Tıpkı konsol uygulamaları gibi ASP.NET Core uygulamalarının da bir başlangıç noktası(entry point) bulunmakta ve uygulama bu noktadan ayağa kaldırılmaktadır. Bahsettiğimiz yer aslında yazımızın önceki kısımlarında sıkça atıfta bulunduğumuz Startup.cs dosyasından başka bir yer değil.

Startup.cs dosyası uygulamamızın başlangıç noktası. Aynı zamanda uygulamayla ilgili konfigürasyonların yapıldığı, application pipeline’ı belirleyen middleware bileşenlerinin eklendiği ve service nesnelerinin register edildiği yer de burasıdır. Yine bu dosyada ortama(environment) göre yapılandırmaları yapabiliyoruz. Örneğin development ve production ortamında farklı yapılandırmalar kullanmak istersek bu dosyadaki Configure ve ConfigureServices metotlarında ortam bilgilerine göre ayarları düzenleyebiliyoruz.

.NET Core ile bütünleşik olarak gelen WebListener ve Kestrel gibi web server bileşenleri ile Windows, Mac veya Linux ortamlarda harici bir web server’a web site(application veya application pool) oluşturmanıza gerek kalmadan uygulama ayağa kalkabiliyor ve HTTP üzerinden gelen request’lere yakalayıp response’lar verilebiliyor. Hangi web server ve konfigürasyonla çalışacağınızı Startup dosyasında, yani uygulamanın başlangıcında belirleyebiliyorsunuz. Bu özellikler bir araya geldiğinde yapılan konfigürasyonlar sonrasında ASP.NET Core uygulaması self-hosted olarak çalıştırılabiliyor. Yani paketinizi alıp sunucuya atıyorsunuz, sonra command line’dan bir komut yazıp dünyaya açılıyorsunuz. Alttaki maddede bilhassa web server konusunu biraz detaylandıracağız.

ASP.NET Core Uygulamalarının Host Edilmesi

ASP.NET Core uygulamalarının en belirgin farklılıklarından biri de uygulama host yapısı. WebForms ve MVC uygulamaları için alternatifleri olsa da dönüp dolaşıp kullandığımız web server IIS’di. Ancak ASP.NET Core’da durum biraz farklı, nihayetinde cross-platform bir çatı, Linux ve Mac sistemlerde de host edilebilmesi için farklı seçeneklerimiz olması gerekiyordu.

.NET Core kütüphanesiyle gelen Kestrel web sunucusu bunun bir örneği, cross-platform bir web sunucusu ve Linux ile Mac makinalarda da uygulamayı host edebiliyor. Bu noktada Kestrel tek başına yeterli değil, Nginx, Apache veya IIS web server’ın arkasında durarak çalışabiliyor. Ee yine IIS vs. var diye düşünmeyin, web server sadece reverse proxy görevi üstleniyor burada, yani 80 vb. bir port üzerinden gelen request’i alıyor ve üzerindeki bir modül üzerinden işi Kestrel’e bırakıyor. Application pipeline tamamen Nginx veya IIS dışında kalıyor, bu web server’lar üzerinde en ufak bir konfigürasyon dahi yapmanıza gerek kalmıyor.

Yine .NET Core’da yer alan WebListener web server’ı da benzer işlevi sadece Windows işletim sistemleri üzerinde yapıyor. Gerek Kestrel, gerekse WebListener web serverları light-weight yapılar. IIS, Nginx veya Apache’yi sadece aracı olarak kullanıyorlar ve bu da geliştirdiğimiz uygulamanın self-hosted olarak çalışmasına olanak sunuyorlar. Yani siz IIS veya Nginx’te bir web application, application pool vs. tanımlamak/oluşturmak zorunda değilsiniz. Ana web server reverse proxy görevi üstleniyor, sadece gelen istekleri ufak web server’lara(yani Kestrel veya WebListener’a) iletiyor. Ufak web server’lar da requestleri işleyerek response’ları istemciye gönderiyorlar. Bu durum da uygulamayı self-hosted yani kendi çalışabilir bir uygulama haline getiriyor. Yani; uygulamayı konsoldan “dotnet run” komutuyla ayağa kaldırmak ve hizmete açmak mümkün oluyor.

Son olarak projemizin hangi web server ile çalışacağını project.json dosyasından belirleyebildiğimizi belirteyim.

Sonuç

ASP.NET Core sadece birkaç gün önce resmi sürümü duyurulan .NET Core üzerine inşa edilmiş, çarpraz platform desteği olan bir web uygulama çatısı. Henüz yeni, taze. Basit yapısı, yüksek performanslı uygulamalar vadetmesi, arkasında .NET Framework gibi olgunlaşmış, güçlü bir yapının izlerini taşıması ve sadece Windows değil, Linux ve Mac işletim sistemi olan cihazlarda da çalışabilmesi bizler için oldukça heyecan verici konular.

Bu yazıda ASP.NET Core’un .NET Framework’teki abileri olan WebForms ve MVC uygulamalarına göre en temel farklılıklarını ve yeniliklerini anlatmaya çalıştım. Farklılıklar bunlardan ibaret değil, başka konular da var. ASP.NET Core dokümantasyonunda çok akıcı ve sade anlatımlar var, mutlaka incelemenizi öneririm. İleride fırsat bulabilirsem ASP.NET Core ile ilgili farklı yazılar da yayınlamaya çalışacağım, umarım sözde kalmaz bu isteğim.