.NET Core, .NET Standart ve Felsefe Taşı – Part II

Previously on : .NET Core, .NET Standart ve Felsefe Taşı – Part I

“It does not do to dwell on dreams and forget to live.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

J.K. Rowling’in de dediği gibi, hayal dünyasının içerisinde hayat sürüp yaşamayı unutmak pek olmuyor. İşte PCL’ler hayatımıza böyle girmişti fakat, hayal dünyasının içerisinde, yani teoride mantıklı bir yaklaşım, gerçek hayata uyarlandığında pek de tutarlı olmadı, olamadı. Çok mu abarttım? Olabilir. Ama bu ortada çözülmesi gereken bir durumun olduğu gerçeğini değiştirmiyor.

Soruyu tekrar alabilir miyim?

Ha, şu soru. .NET Standart neden var? Ondan öncesinde PCL’ler neden var diye sormamız gerekiyor değil mi? Çözmeye çalıştığı problem aslında yazdığınız kodların farklı .NET proje tiplerinde kullanılabilmesini sağlamak. Peki neler bu proje tipleri ? .NET Framework, Silverlight, Windows 8 (Metro), Windows Phone, Xamarin, Mono, Universal Windows Platform (UWP), XBox 360, liste daha uzuyor.

enter image description here

Evet, tabii, güzel fikir. Bir çok ihtiyacı da karşıladı aslında, bu sebeple tamamen kötülemek doğru olmaz ama bir süre sonra bu yaklaşımın eksikliklerini görmeye başladık.

Nerede benim API’ım ?

dotnet-today

Birinci problem, PCL altyapısı, uygulamayı yazarken kullanabileceğiniz API’ı, desteklemeye çalıştığınız platformların kesişimine göre belirliyor. Bir platformda olan bir API diğer platformda yoksa, o kısım çıkartılıyor. Örneğin Xamarin.iOS, Xamarin.Android ve UWP için yaratayım bir PCL dediğinizde, yapacağınız dosya okuma ve yazma işlemleri artık düşündüğünüz kadar kolay olmuyor. Çünkü bir tarafta System.IO varken, diğer tarafta Windows.Storage var. Kesişimin içerisinde bu iki API da yok. Yani, var da yok. System.IO namespace olarak var ama tanıdık olduğumuz File ve Directory yok mesela. Bu sefer kulağınızı tersten tutmaya ve şuradaki gibi bir guide’ı takip etmeye başlıyorsunuz. Bu da size hayatınızı ve mesleki kararlarınızı sorgulatabiliyor. Halbuki sadece bir dosya okumak istemiştiniz. Bu tür eksiklikleri kapatmak için ortaya PCLStorage gibi paketler çıkıyor ama bu nedense yama hissiyatı yaratıyor. Her kombinasyonda eksik kalan parçalar ve o eksiklikleri kapatmaya çalışan paketler. Sonu gelmez bir döngü.

Ama Cross-Platform oluyor değil mi ?

Aslında tam değil. Yazdığınız kod her platform için ayrı ayrı derleniyor. Evet, bir PCL paketini NuGet üzerinden çekerken bütün desteklenen platformlar için derlenen dosyalar da yanında geliyor. Şimdi, bundan iki yıl sonra başka bir .NET platformu çıksa – ki bu hızda giderse hiç de düşük bir olasılık değil – bu paket o platformda çalışacak mı? Tabii ki hayır. Çünkü paketin, bu platform da eklenerek tekrar derlenmesi gerekiyor. Bu arada kaybedebileceğiniz API’ları da bir yandan düşünseniz iyi olur. Onlara da bir “yama” gerekecek.

.NET Standart

Yani bu iki büyük soru işaretine karşı çözüm olacak yapının, öncelikle stabil bir API sunması gerekiyor. Bu ise, hali hazırdaki platformların bu API’ı implemente etmesi gerektiği anlamına geliyor ki geliştirmek istediğim platformlara göre erişebildiğim API oranı azalmasın. Aynı zamanda, sonrasında geliştirilebilecek diğer platformların da aynı API’ı implemente etmesi sağlanırsa, bu yapı için derlenen paketlerin de gelecek platformda çalışması sağlanabilir.
Buradan ise yapının görevinin, bütün .NET platformları için ortak bir API sunmak ve bunun devamlılığını sağlamak olduğunu söyleyebiliriz ve iki soru işaretimiz de böylece ortadan kalkmış olur.

Sonuç olarak ortaya .NET Standart çıkıyor.

.NET Standart sayesinde artık tek bir API kullanarak, .NET Standart API’ını implemente etmiş olan bütün .NET platformlarını destekleyebiliyoruz. Yakın zamanda 2.0 versiyonu çıkan .NET Standart tarafından desteklenen API setinin içerisinde Networking, IO ve Threading gibi önemli yapı taşları mevcut.

netstandard-apis

Bir süre sonra PCL’ler yerini .NET Standart’a bırakacak. Kişisel kanaatim, .NET Standart’ın çok daha iyi bir yaklaşım olduğu yönünde. Umarım yakın zamanda bir standarta daha ihtiyaç duymayız.

“The truth.” Dumbledore sighed. “It is a beautiful and terrible thing, and should therefore be treated with great caution.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

Bir sonraki yazıda görüşmek üzere.

.NET Core, .NET Standart ve Felsefe Taşı – Part I

Merak etmeyin, bu yazının ne Harry Potter, ne de maddeyi altına dönüştürme ile bir ilgisi yok. Bu yazı dizisinde daha çok, .NET Core ve .NET Standart’ın kendilerini, ortaya çıkmalarındaki nedenleri, ekosistemde yapacakları değişiklikleri ve bizim bu değişikliklere nasıl ayak uydurmamız gerektiği ile ilgili konuşacağız.

Giriş

Yakın zamanda .NET Core 2.0 ve ASP.NET Core 2.0 duyuruldu. Bir çok değişiklik ve güzel haber var fakat boşverin, şimdi oradan kopup, biraz daha geriye, bütün bunların başladığı zamana gidelim. Fazla değil Kasım 2014’te Microsoft, .NET Core’u (CoreFX) Open Source yaptı. Tabii kimse .NET Core’un ne olduğunu bilmiyordu. Blog yazısında, aslında bu teknolojinin içeride ASP.NET 5 (vNext) ve .NET Native’de -ki başlı başına ayrı bir konu- hali hazırda kullandıklarını, gelecekte .NET platformunun temel taşının bu yapı olacağını söylediler. Open Source olmasındaki sebep ise, .NET’in arkasında daha güçlü bir ekosistem oluşturmak ve cross-platform bir hale getirmek için hazırlıklara başlamaktı.

.NET Core’un arkasındaki ana sebep ise, .NET Framework yaklaşımının pek de doğru olmaması ve bunu değiştirmeye yönelik çalışmalar yaparken de aynı zamanda zaten olması gereken cross-platform desteğini de göz önünde bulundurmaktı. İki amaç da zamana göre daha fazla önem kazanabilir.

.NET Core’un alt yapısını anlatmadan önce size .NET Framework yaklaşımını ve yanında getirdiği problemleri biraz daha açmam gerek.

Bir Sorunun Tanımı

 

Yukarıdaki ekranı hatırladınız değil mi? Hiç görmediyseniz eğer ne mutlu size, bugünün şanslı 10.000 kişisinden birisiniz. Özetlemek gerekirse, yüklediğiniz bir uygulama, çalışmak için .NET Framework’ü gerektiriyor ve önce onu yüklemeniz gerek. Bunun sadece Windows içerisinde karşılaşılan bir durum olduğunu söylemiyorum, keza diğer sistemlerde yüklediğiniz paketler, başka paketleri gereksinim olarak isteyebiliyor, fakat buradaki ana sorun teknik değil. Ana sorun, yukarıdaki problemin son kullanıcı tarafından çözülmesinin beklenmesi. Aynı zamanda bu paket öyle elzem ki, bütün .NET uygulamaları* kullanıyor ve versiyonları var. Uygulama hangi versiyonu kullanıyorsa ona göre yüklenmesi gerek. Yukarıdaki “Yes” butonuna basınca sizi o paketin indirme sayfasına yönlendiriyor, siz de inen paketi kuruyorsunuz. Tabii paket kullandığınız işletim sistemi tarafından destekleniyorsa. Örneğin Windows 7 kullandığınızı varsayarsak ve açmaya çalıştığınız uygulama .NET Framework 4.6 kullanıyorsa eğer, SP1 yükseltmesini önceden yapmış olmanız gerek. Yapmamışsanız uygulama çalışmıyor. Yani bir uygulamayı kullanmak için önce sistem güncellemesi, sonra paket kurulumu ve en sonunda kullanmak istediğiniz uygulamanın kurulumunu yapmanız gerekebilir. Bu arada bütün bunları teknik bilgisi fazla olmayan birinin yapmaya çalıştını düşünürseniz, durum pek iç açıcı değil.

Diğer bir sorun, bu kütüphanenin içerisinde herşeyin olması. Siz bir uygulama yazarken sadece küçük bir kısmını bile kullansanız, bu o uygulamanın .NET Framework kullandığı gerçeğini değiştirmiyor. .NET Framework 4.6’nın kurulum paketi 62.4 MB. Kurulum sonrası boyutu 100 MB’ı aşıyor. Amacı iki sayı toplamak olan bir konsol uygulamasının çalışması için de bu kütüphanenin kurulması gerek.

Ha bu arada yukarıdaki bu iki uygulama da diğer işletim sistemlerinde çalışmıyor.

Sanırım yavaş yavaş problemin kaynağının ne olduğunu ve nasıl çözülebileceğini düşünmeye başlamışsınızdır. Öyle bir şey olmalı ki, uygulama herhangi bir dış kaynağa gereksinim duymamalı, yani kullandığı paketleri yanında götürmeli.

* = Bütün .NET Framework uygulamaları yani WinForm, WPF, ASP.NET gibi.

Bir Efsanenin Doğuşu

.NET Core işte bu fikrin hayata geçmiş hali. Tabi şu “kullandığı paketleri yanında götürmesi” kısmı için .NET Framework parçalara ayrıldı ve çoğu paket NuGet üzerinden referans edilebilir hale getirildi. En temel parçalar (CLR ve içerisindeki GC ve JIT) ise cross-platform çalışması için baştan yazıldı ve .NET Core CLR oluştu. Tabii hepsinin cross-platform çalışması için değiştirilen bir çok yaklaşım da oldu.

Peki Web?

ASP.NET 5 (vNext) yani ASP.NET Core ise, .NET Core’un üzerine ASP.NET mimarisinin bindirilmesi ile oluşmuş bir platform. Ocak 2016’ta ASP.NET 5 adı ASP.NET Core olarak değiştirildi çünkü ASP.NET  5 sanki ASP.NET 4.5’in bir üst versiyonu gibi anlaşılıyordu. Halbuki ASP.NET 5,  yapısal anlamda ASP.NET 4.5’i andırmıyordu bile ve bu insanlarda kafa karışıklığı yaratabilirdi. Bu sebeple isim değişikliğine gidildi.

Soru İşaretleri

Peki .NET Standart bunun neresinde. Bugün itibarıyla üç tane .NET platformu var; .NET Framework, .NET Core ve Xamarin. Her birisinin amacı ve kullandıkları altyapılar farklı. Tabii bu kullanılan dil aynı olsa bile oluşan paket uyuşmazlığı, yazılan kodların platformlar arası kullanılmasını engelliyor. Zaten her biri programlayan kişiye farklı API’lar sunuyor. Yani her türlü yazılan kod belirli bir platforma özel olmuş oluyor. Bu sorunu çözmek için üretilen PCL ise sorunu daha da büyük bir hale getiriyor.

Part II’de ise .NET Standart’ın ne olduğunu ve yukarıdaki probleme nasıl bir çözüm getirdiğini göreceğiz.

.NET Core, .NET Standart ve Felsefe Taşı – Part II