Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…

ASP.NET tarafında uzun zamandır büyük bir değişiklik var, Web Forms’un yanına MVC kalıbının gelmesi, .NET Framework’ün yeni versiyonları çıktıkça MVC’nin daha popülerleşmesi, OWIN, WebAPI, SignalR falan derken, ASP.NET kavramı ilk çıktığı zamankinden çok farklı bir hal aldı. .NET Framework’ün açık kaynak olabilmesi için, ondan ortaya çıkan .NET Core ile ASP.NET 5 duyurulmuştu. Bulut için uygun, performans açısından daha gelişmiş ama aynı zamanda alt yapıdaki karmaşıklığın basitleştirildiği, WebAPI, MVC gibi kavramların tekilleştiği ve içerisinde daha bir çok geliştirmeyi barındıran bir alt yapı olarak kısa zamanda çok sık konuşulmaya başlandı. Bu arada .NET Core != .NET Framework yazımı hatırlatmak isterim. Yeni nesil .NET Core alt yapısının ne olduğu öğrenmek ya da hatırlamak isteyenler göz atabilir.

mass_confusionKısa zamanda, acaba geleneksel ASP.NET ölüyor mu, .NET Framework ne olacak gibi karmaşıklıklarda gündemde oldu. Komple yeni bir alt yapının, mevcut versiyon ağacından ASP.NET 5 diye ortaya çıkması bunun en büyük sebebi. Aynı şey Entity Framework 7 ile de olmuştu. EF 6’dan sonra, tüm alt yapıyı değiştirdik, *.edmx alt yapısını kaldırdık diye EF 7’yi duyurunca da kısa bir şaşkınlık olmuştu. Kısaca Microsoft bunu hep yapıyor… Ama hangimiz yapmıyor ki…

Hem bu kafa karmaşıklıklarını yok etmek, hem de gerçekten yeni bir alt yapı olduğu için Microsoft’daki meslektaşlarımız ASP.NET 5’in artık ASP.NET Core 1.0 olduğunu geçen ay duyurdu. Bununla ilgili Scott Hanselman‘nın duyurusundaki ilk giriş cümlesi de aslında olayı özetliyor. “Naming is hard”

Neyse…Bu isim değişikliğinden sonra yeni isimler aşağıdaki gibi oldu;

  • ASP.NET 5 –> ASP.NET Core 1.0.
  • .NET Core –> .NET Core 1.0.
  • Entity Framework 7 –> Entity Framework Core 1.0

Şu an mevcut Github içeriklerinde ya da tüm resmi sayfalarda da bu değişiklikler yayınlanmaya başladı. Bu isimlendirme değişikliğinden dolayı RTM tarihlerinde biraz değişiklik oldu dolayısıyla. Son tarihleri bilemiyoruz ama buradan roadmap’i takip edebilirsiniz.

aspnet-core

Bu isimlendirme değişikliklerinden önce, aslında paralel demek kafa karışıklığını biraz azaltır; dnx tarafında da bir değişiklik oldu. Yine DNX, DNVM,DNU neydi hatırlamak isteyenlere bu konuyla alakalı önceki yazımı tavsiye ederim. Yeni nesil .NET Core uygulamaları ve ASP.NET 5’i geliştirmek ve çalıştırmak için gerekli olan runtime ve bileşenleri(dnx,dnvm…) .NET Core Command-line şeklinde değişti ve tek dotnet komutu ile yeni nesil .NET Core uygulamaları çalıştırılabilir oldu. .NET Core Command-line(Core CLI) araçları olarak yeniden düzenlenen komutlar ASP.NET Core 1.0 RC2 ile dnx tarafının yerini alacak. Şimdilik öncesinde GitHub sitesinden de indirip kurabilirsiniz. Ya da http://dotnet.github.io/getting-started/ adresinden de ayrıntılı olarak başka bilgilere hatta docker imajına ulaşabilirsiniz.

Kısacası değişiklikler artarak devam ediyor. Bütün bu değişim içerisinde, bu yeni şeyleri kavramak, denemek oldukça zahmetli olabiliyor. Daha tam oturmamış olması, .NET Framework tarafında olup .NET Core tarafında desteklenmeyen namespace’ler olması biraz uğraştırıyor. Ama işin keyifli ve güzel yanlarından biri de bu değil mi? Son durumun özeti olması adına faydalı olduğunu düşünüyorum. Bir sonraki kafa karışıklığında görüşmek üzere :)

.NET Framework’de geliştirme yapanların, “memory” konusunda biraz daha rahat hissetmesini sağlayan ama sanıldığı kadar basit olmayan bir kavramdan bahsetmek istiyorum. .NET Framework ve “memory” diyince zaten hepimizin bildiği Garbage Collector(GC) direkt aklınızda canlanmıştır diye düşünüyorum.

Geçen hafta yaşadığım bir performans sorununu ve GC ile olan ilişkisinden dolayı bir şeyler yazmak istedim. Şimdi direkt problemden bahsetsem çok anlamlı olmayacak. Bu yüzden öncesinde GC nedir ve nasıl çalışıyor biraz bunlardan bahsetmek istiyorum.

Nedir?

Garbage CollectorManaged platformalarda(.NET, Java…) memory işlemleri bu platformların kendi içinde yönetilir. Biraz daha low-level dillerde ise memory yönetimi geliştirmecinin kontrolündedir. C/C++ ile geliştirme yapmış olanlar malloc() ve free() metodlarını hatırlar. Gerçi çok hatırlamak istemezler sanırım…Neyse…

Basitçe; yazdığımız kodlardaki sınıflar için çalışma zamanında; nesneler için memory’de belli bir alan ayırırız. Nesne ile ilgili işimizi bitirdiğimizde de bu ayrılan yeri tekrar sisteme geri bırakmalıyız ki, uygulamalarımız sorunsuz çalışsın. “Memory Leak” olmak üzere çeşitli memory problemleri oluşmasın. Neyse ki bu işi .NET tarafında GC bizim için hallediyor.

Peki nasıl hallediyor?

.NET’de CLR(Common Language Runtime) ayağa kalktığında, nesneler için, “managed heap” diye bir alan oluşturur. GC’da bu alan üzerindeki nesnelerin kullanımına göre onları yok eder ya da korur. Kullanımı derken, bu nesnelerin yaşamı olarak düşünebiliriz. Bir nesne için, managed heap üzerinden yaratılan alan, referans olarak kullanılıyorsa, o nesne yaşıyordur gibi düşünebiliriz. GC bu referans alanlarına bakarak(buna GC Roots denir) nesnenin yaşamadığı sonucuna varırsa, memory’deki o nesne için olan alanı boşaltır ve başka nesneler için yer açar.

“Managed Heap”, nesnelerin farklı jenerasyonunu tutacak şekilde tasarlanmıştır. Nesneler yaşam sürelerine göre GC tarafından bir jenerasyondan diğerine taşınır. Bu sayede “memory”de daha fazla yaşaması gereken nesneler yaşamlarına devam eder. Ki bütün olayda burada kopuyor aslında. Bu jenerasyonlar Gen0, Gen1 ve Gen2 olmak üzere 3 tanedir.

Devam

2015 Nisan ayında, Microsoft, Azure platformunda yeni bir hizmetini tanıtmıştı. Azure Service Fabric olarak adlandırılan bu hizmet ile güvenilir, kolay yönetilebilir, erişilebilir ve en önemlisi ölçeklendirilebilir dağıtık sistemler geliştirmek mümkün hale geliyordu. Hala “Preview” olan bu hizmet, bu sene farklı yeni özellikleri ile bir adım daha ileriye gelir umarım. Son bir kaç zamandır kurcalama fırsatım olduğu için, kısaca neymiş, ne değilmiş biraz bahsetmek istedim…

Azure Service Fabric(ASF), Azure içinde, kendi yönettiğimiz ölçeklendirilebilir sistemler geliştirmemiz için sunulan bir hizmet olarak da tanımlanabilir. AFS aslında Azure’un diğer başka hizmetlerinde de, Microsoft’un kullandığı bir hizmet. Azure SQL Database, DocumentDB ve Event Hubs gibi bir çok hizmet bu yapı üstünde ölçeklenip çalışıyor. Kısacası, Azure’un içindeki bir servisin dışarıya açılması da diyebiliriz, Azure Service Fabric için.

Microservices konsepti son bir kaç yıldır oldukça popüler bir konu olarak, dağıtık sistem tasarımlarında kendine yer ediniyor. Azure Service Fabric hizmetini bu noktada, Microservices mimari sitilini sistemlerinde kullanmak isteyenlere cloud tarafında olan bir çözüm olarak düşünebiliriz. Tek başına, kendi iş mantığına ve çalışma ortamına sahip bir çok servisi kullanarak geliştirilen uygulamaları ve bu servisleri Azure Service Fabric üzerinde geliştirip, barındırıp yönetebiliyoruz.

service-fabric-overview

AFS üzerinde iki farklı programlama modeli API olarak bizlere sunuluyor. Reliable Actors API ve Reliable Services API… Geliştirilecek servislerin yaptığı işler ve amaçlarına göre seçim yapılması gereken bu API’lar farklı ihtiyaçlar için tasarlanmış.

Reliable Actors API, bir birinden tamamen bağımsız, durumunu ve iş kurallarını kendi içinde tutan, dış kaynak erişimi olmayan, tek thread’li servis ihtiyaçları için tercih edilmelidir. Mesela, belli formattaki büyük Excel dosyalarını parse edip, kaydetmek için bu API’yi tercih edebilirsiniz.

Reliable Services API ise, farklı bileşenler ile konuşması gereken, geliştireceğiniz servisler içinde state gerektiren durumlar olduğunda ve servis iletişimini kendiniz yönetmek istediğinizde tercih edebileceğiniz bir programlama API’si. Önümüzdeki günlerde bunlara örnek kodlar ile daha fazla zaman ayıracağım. O yüzden şimdi kafanız biraz karıştıysa, önümüzdeki yazılarda ayınlanma yaşayacaksınız. :)

Azure Service Fabric üzerindeki servisleriniz ihtiyaçınıza göre bu iki modelden biri olabilir. Yani illa bir tanesi olmak durumunda diye bir şey yok. Bir servisiniz Reliable Actors API ile geliştirilmiş olup, diğer başka bir servis Reliable Services API ile geliştirilmiş olabilir. Bu noktada, önemli olan her iki API’de geliştirmiş olduğunuz servisler, ölçeklenebilir ve erişilebilir olacaktır.

Service-fabric-local-cluster

Bu programlama modellerinden, biraz daha Azure Service Fabric bileşenlerine geçelim. Yukarıda bahsetmiş olduğum API’lere göre geliştirdiğiniz servisler, ASF üzerinde belli bir düzen içinde bulunuyor. Kısaca ne olduklarına bakalım.

Devam

Lego’ya olan ilgimi Twitter ya da Instagram‘dan takip edenler bilir, takip etmeyenlerde bilemez, o yüzden takip etsinler; diye reklam kokan bir giriş ile uzun zamandan sonraki yazıma başlıyorum…Siz Lego falan ne alaka demeden, hala bu yaşımda Lego alıp, saatlerce onlarla uğraşan biri olduğumu belirtim. Yaşasın içimdeki çocuk… Peki ne alaka?

Lego1Efenimm, şimdi Türkiye’deki Lego distribütorlüğünü Adore Oyuncak yapıyor. Dolayısıyla zaman zaman takip ettiğim bir yer. Ama hangi ürünler gelmiş, neler bitmiş falan sürekli mağazalarına gidip bakmak her zaman mümkün değil. Gelmesini beklediğim ürünlerin gelip gelmeyeceklerinin kesin olmaması, gelirlerse ne zaman geleceklerinin de belli olmaması, içimdeki çocuğun en büyük sıkıntısı. Neyse ki, internet çağında yaşıyoruz da, firmanın internet sitesinden bir şekil kontrol edebiliyoruz. Ama içimdeki sabırsız çocuk her gün, her gün internetteki sayfasına bakmaktan da sıkılmış durumda. Lanet olsun içimdeki çocuğa…

Lego3İçimdeki çocuğu biraz olsun sakinleştirmek için, Cloud’un nimetlerinden neden yararlanmıyorum diye düşündüm bir akşam…Hani böyle sıkılırsınız ya, hiç bir şey yapmak istemezsiniz falan, ahaa da öyle bir akşam. Yoksa hiç işim olmaz, ne uğraşıcam…(yersen)

Azure’da, node.js ile basit bir iş(web jobs) yapıp hem sıkıcı akşamıma renk katmak, hem de içimdeki çocuğu biraz sakinleştirmek üzere işe koyuldum. Çok uzun uzun anlatmak istemiyorum. Oldukça basit çünkü… Madde madde özetleyerekten, hangi teknolojileri, hangi amaçla kullandığımı vurgulayarak, Cloud ve basit diğer API’ler ile neler yapabileceğimizi paylaşmak istiyorum sadece.

Basit özetlemek gerekirse yaptığım şey, belli bir zamanda, otomatik olarak çalışan bir kod parçası ile, bir web sitesini “parse” edip, belli bir alanındaki değeri bir yerde saklayıp, bu değerin değişimini e-mail olarak kendime atmak.

  • Belli bir zamanda otomatik olarak çalışması için Azure‘da ki WebJobs bileşenini kullandım.
  • Çalışan kod, sunucu tarafında event-driven I/O işlemleri için tercih edilebilecek olan node.js‘de çalışan basit bir javascript. node.js tercih etmiş olmamın sebebi, kesinlike kısa sürede yapmak istemem. Başka kodlarla yazılmış programlarıda Azure WebJobs’da çalıştırabilirsiniz. (*.exe, *.bat, *.py, *.jar, *.php…)
  • node.js’de html sitesini parse etmek için cheerio modülünü tercih ettim
  • Bildirimleri e-mail olarak yapabilmek için SendGrid e-mail alt yapısını tercih ettim. Hem ücretsiz olması, hem de Azure’da ve node.js’de modülünün olması tercih sebebimdi.
  • Azure’un Storage Service‘ini de, parse ettiğim veriyi saklamak için tercih ettim. Tek basit bir değer saklayacağım için ve Azure’un node.js’deki SDK‘sını kurcalamak için güzel bir fırsat.

Anahtar kelimeleri verdikten sonra aşağıda kodu da bulabilirsiniz. Açıkcası çok fazla ayrıntısına girmek istemedim. Basit bir ihtiyaçlarımızı, nasıl çözebileceğimizi vurgulamak ve biraz merak uyandırmak için umarım faydası olur. İlerleyen günlerde belki daha ayrıntılı olarak da bahsedebilirim ama beklemeden sorularınız olursa yorum kısmında ya da e-mail ile bana iletebilirsiniz.

Güvenlik konusu yazılım için oldukça ilginç bir nokta. Herkesin bildiği ama farkında olmadığı garip bir konu. Gerçek hayatta da aslında böyle. Başımıza kötü bir olay gelmediği sürece, güvenliğe çok dikkat etmiyoruz. Gelişen dünya düzeninde, gündelik hayatta bu farkındalık artık çok daha fazla olsa da yazılım konusunda gereken önemi hala tam veremiyoruz.

Bilişim dünyasının bir parçası olmaktan kaçınamadığımız bu çağda, teknolojinin ve yazılımın hayatımızın bir parçası olması güvenlik konusunun daha önemli olmasını sağlıyor aslında. Çoğu işimizi bilgisayar ile yapabiliyor, internet ile 7/24 her yere bağlanabiliyor ve ekonomik/sosyal ihtiyaçlarımızı elimizden düşürmediğimiz telefonlar ile her yerden karşılayabiliyoruz. Bunları yaparken son kullanıcı olarak, bu sistemleri geliştirenler olarak, yazılımları kodlayanlar olarak ya da bu sistemlere destek veren kişiler olarak hepimizin güvenlik konusunda dikkat etmesi gereken şeyler var. Kısacası, güvenlik hepimizin problemi

Guvenlik

Hepimizin problemi olduğu için, herkesin kendince dikkat etmesi noktalar var. “Şifrelerimizi doğum yılımız ya da 123456 gibi ardaşık sayılar yapmıyoruz” ya da “SSL sertifikası olmayan sitelerden kredi kartımızla alışveriş yapmıyoruz”,”Şifrelerimizi kağıtlara yazıp, sağa sola yapıştırmıyoruz” gibi şeylerden çok bahsetmeye gerek yok. Bu farkındalık daha hızlı bir şekilde oluşmaya başlıyor artık. IT sektöründe çalışan kişiler olarak, bu farkındalığın oluşmasında biz ne kadar rol oynuyoruz ya da neler yapıyoruz biraz da artık bunu sorgulamak lazım.

“123456”‘nın şifre olarak kullanılmaması gerektiğini bilmemize rağmen, şifre gerektiren üyelik sistemleri geliştirirken “123456”nın şifre olarak seçilememesine, yazdığı kodda kaç yazılımcı dikkat ediyor; merak ediyorum şahsen… Hala bir çok uygulama, üyelik aşamasında bu tarz şeylere izin veriyor. Ya da SSL sertifikası olmayan sitelerde verilerimizi paylaşmıyorken, neden kendi geliştirdiğimiz uygulamalarda SSL’i zorunlu tutmuyoruz. Statik olarak kullanıcı isimlerini ve hatta şifreleri hala uygulamaların içinde “hard-coded” tutan yazılımlar var mesela. Aynı şekilde IP adresleri de mevcut…

Guvenlik

Neler güvenli ve neden güvenli olması gerekiyor?” sorusu aslında en başta hepimizin sorması ve hepimizin beraber cevap bulması gereken bir soru. Sistem güvenliği, yazılım güvenliği, veri güvenliği ve daha farklı gruplamalar ile tüm ilgili paydaşların ilgisini gerektiren konular var. Sistem açısından; belli ağ içerisinde, belli bir sunucunun belli port’ları önemli olurken, veri sistemi tarafında da, verinin öneminden dolayı sunucu ve disk çeşiti önemli olabilir. Kritik olan, bu noktada bunların hep beraberce konuşulması. Neler güvenli ve neden güvenli olması sorularındaki cevaplar net olduğu zaman bazı şeyler daha kolay olacaktır.

Geliştirdiğimiz sistemlerin dışarıya açılan, son kullanıcıya hitap eden kısmı, “uygulamalar” oluyor genelde. Web, mobil(cep telefonu,tablet..vs) ya da masa üstü gibi farklı ön yüzler ile artık hayatımızın her alanında karşımıza çıkan “uygulamaları” geliştirirken çeşitli güvenlik prensiplerine daha fazla önem vermek gerekiyor sanırsam. Televizyondaki bir uygulamadan havale yapabiliyor olmak, ya da tüm kişisel bilgilerimizi herkesle paylaşabilmek(?) kötü niyetli insanların güvenlik açıklarını tespit etmesinde büyük motivasyon sağlıyor. Uygulamaları geliştirirken de benzer motivasyonun bizde olması lazım.

Uygulamaların girdilerinin doğrulanması, kripto işlemlerinin belli standartlar içerisinde yapılması, yetkilendirme adımlarına dikkat edilmesi gibi daha bir çok çeşitli güvenlik prensipleri artık yazılım geliştirme sürecimizin bir artık parçası olmalı. Sonradan yapılacak güvenlik iyileştirmeleri daha zorlayıcı olacağından baştan eşeği sağlam kazığa bağlamakta fayda var. Mesela yazılım geliştirirken atladığımız “input validation“lar, kötü niyetli insanlar için açık kapı oluşturabiliyor. “SQL Injection” ya da “XSS” bunun bilinen en büyük örnekleri… Kullanılan teknolojiye göre “Buffer overflow” hatalarından hafızaya müdahale edip, istenmeyen komutların çalıştırılabilmesi, hatalardan sistemin açık kapılarını bulup erişim yetkisi olmayan verilere erişim gibi konular uygulamalarımızı geliştirirken engelleyebileceğimiz bir kaç örnek. Genelde sistemlere ya da son kullanıcıya güvenip, bazı varsayımlar içerisinde bulunduğumuz için bu tarz noktalara dikkat edemiyoruz. “Hiç kimseye güvenme” yaklaşımı bu noktada geliştirdiğimiz uygulamalar içinde geçerli…Zaman kötü, kolla kodu.. 😛

Guvenlik

IoT(Internet of Things) ile uygulamaların(yazılımların) artık her yerde olacak olması ile güvenlik konuları daha önemli olacak. Güvenlik konusuna gereken özeni vermezsek, teknoloji bir çözüm olmaktan çok bir problem olmaya başlayacaktır, benden söylemesi… Umarım bilişim dünyası insanı olarak bu konulara daha fazla önem verip, nelerin, neden güvenli olması gerektiğini daha fazla sorgulayıp, güvenli sistemler geliştirmeyi amaçlarız.

Microsoft’un geliştiriciler için sanal olarak düzenlediği Connect(); etkinliğinde bugün neler oldu kısa kısa özetlemeye çalışacağım. Merak edenler için derlemiş olalım. Daha fazla ayrıntı ve etkinliğin videoları için tabi ki https://channel9.msdn.com adresini ziyaret etmenizi öneririm.

Connect()

.NET Core ve ASP.NET 5 RC versiyonu çıktı.

1 yılı aşkın zamandır açık kaynak olarak geliştirilen .NET Core ve ASP.NET 5, Release Candiate olarak bugün itibari ile RTM versiyonuna yaklaştı. Bir derleme yazısı olduğu için, uzun uzun neler değişti, neler geldi tek tek anlatmayacağım. Yayınlanan “Release Notes”‘lardan tüm ayrıntılara bakabilirsiniz.

RC ile hem .NET Core’un hem de ASP.NET 5’i “Go Live” lisans modeli ile üretim ortamlarında da isterseniz kullanabilirsiniz. ASP.NET 5’in son versiyonunu http://get.asp.net adresinden indirebilirsiniz.

Entity Framework 7 RC versiyonu çıktı.

.NET Core ile beraber Entity Framework 7‘nin de Release Candiate versiyonu çıktı. Takip edenleriniz bilecektir. EF 6.x ve EF 7 şeklinde bir farklılaşma oldu. Yaklaşım 1 yıldır, .NET Core ve açık kaynak vizyonuna uygun bir şekilde EF 7 de geliştirilmekteydi. Biraz daha lightweight olması ve cross-platform olması ile geliştirme yatırımın büyük bir kısmı buna gidiyordu. Bugün itibari ile RTM’e en yakın versiyonu yayınlanmış oldu. RTM’e kadar bu versiyonuna yeni bir özellik eklenmeyecek ve bildirilen bug’ların düzeltilmesi ve dökümantasyon geliştirilecek. Entity Framework 7 ile ilgili geliştirmelere başlamak, neler oldu, neler değişti bunları takip etmek için http://docs.efproject.net/en/latest/ adresini takip edebilirsiniz.

System.Data.SqlClient da artık cross-platform

.NET Framework’ün veri erişim yöntemleri açısından en çok tercih edilen System.Data.SqlClient da artık cross platform. Yani OS X ve Linux’da da bu uzayadının sınıflarını falan kullanmak mümkün artık. Tabi ki eksiklikleri var. Named Pipes desteği yok, sadece TCP bağlantı desteği var gibi bir kaç handikapı olsa da ilerleyen zaman içerisinde bütün bu eksiklerde giderilecektir. https://gist.github.com/cartermp/3c826e1d15577268eda6 adresinden biraz daha ayrıntılı bilgilere ulaşabilirsiniz.

Visual Studio Code açık kaynak oldu…

Cross-platform olarak geçtiğimiz aylarda Visual Studio Code ile tanışmıştık hatırlarsanız. Artık kendisi de açık kaynak dünyasında yerini aldı. Node.js’den, Go’ya, PHP’den Javascript’e, C#’a, HTML’e kadar aklınıza gelebilecek bir çok geliştirme dilini yazabildiğimiz bu basit ama etkili text editörü aynı zamanda “extensions” özelliğini kazandı. Yani artık bu editör için eklenti yazıp, eklenti indirebileceğiniz.

Visual Studio MarketPlace Preview oldu…

Eklenti demişken, daha önce Visual Studio Gallery olarak bildiğimiz, Visual Studio’nun eklenti havuzu çeşitlendi ve Visual Studio MarketPlace duyuruldu. Daha sonra Visual Studio Gallery’nin de yerini alacak bu eklenti havuzu, Visual Studio versiyonları için çeşitli eklentiler indirip, eklentiler yükleyebileceğiniz bir yer olacak. https://marketplace.visualstudio.com/ adresinden eklentilere göz atabilirsiniz. Şimdilik biraz az ama kısa zamanda hızlı bir şekilde artacaktır. Aynı zamanda buradan Visual Studio üyelik modeli de sunulmaya başlanıyor. Yıllık ya da aylık üyelik seçenekleri ile Visual Studio’nun özelliklerinden yararlanabileceksiniz.

Visual Studio Online’da isim değişikliği ve dahası…

Daha önce de isim değişikliği olmuştu ama bu sefer sanırım artık son. Visual Studio’nun TFS ile entegre olan “cloud” ürünü Visual Studio Online artık Visual Studio Team Services. Tabi ki sadece isim değişikliği söz konusu değil. Code Search özelliği, JMeter ile Load test özelliği, test adımlarında yeni özellikler ve daha bir çok buradan öğrenebilirsiniz.

Azure Service Fabric, microservice tabanlı uygulamalar için Preview oldu…

En son Build// etkinliğinde duyurulan, microservices tabanlı uygulamalar geliştirmek ve yönetmek için Azure’da hizmet veren Azure Service Fabric bugün Preview oldu.

Azure ile ilgili tabi başka yeniliklerde duyuruldu. Mesela Azure SDK 2.8 versiyonu çıktı.

 

Geliştiriciler için yeni Visual Studio Dev Essentials programı…

Microsoft, geliştiriciler için yeni bir ücretsiz programı da bugün duyurdu. Visual Studio Dev Essentials adı altındaki bu programla, geliştiricilerin bir çok Microsoft ürününe ücretsiz erişim sağlaması mümkün olacak. Xamarin, Pluralsight gibi farklı şirketlerin ürün ve servislerini de içerecek bu programdan yararlanmak için https://www.visualstudio.com/products/visual-studio-dev-essentials-vs adresini ziyaret etmeniz yeterli.

Microsoft artık çok hızlı çıktı üreten bir yazılım ve servis firması haline geldi. Dolayısıyla yetişmek zor. Umarım başlangıç için bu derleme biraz faydalı olmuştur. Zamanınız olursa, yarın da sanal olarak devam edecek etkinlik. Kaçırmayın derim.

 

vNext kavramı ile tanıştığımız Microsoft’un farklı işletim sistemlerinde de çalışan yeni framework’ü .NET Core ile ilgili önceki yazılarda birşeyler paylaşmaya çalışmıştım hatırlarsanız. Önümüzdeki günlerde RC1, 2016’nın ilk çeyreğinde de RTM versiyonun çıkması planlanan bu framework’e ben de ilerleyen zaman içerisinde biraz daha değinmek istiyorum. Bu zamana kadar çok fazla değinmek istemedim çünkü hala gelişmekte olan ve tam stabil halini almış bir versiyon henüz yok. Ama yavaş yavaş RTM’e yaklaştığımız için, yavaş yavaş ben de karalayabilirim sanırım artık.

.NET Core, Microsoft tarafından açık kaynak olarak geliştirilen, dışarıdan da katkı alan bir framework. Dolayısıyla tüm gelişme anına tanıklık edebiliyorsunuz. GitHub‘dan takip edip, siz de katkıda bulunabilirsiniz. Bunu özellikle hatırlattıktan sonra .NET Core içindeki Dependency Injection(DI) kavramından bahsetmeye çalışacağım. DI, .NET Core’un bir parçası olarak, ASP.NET 5’in de temel bir bileşeni olarak karşımıza çıkıyor. Tüm framework içerisindeki bağlılıkları yönetmek ve geliştirmek bu yeni yaklaşım ile beraber daha kolay bir hal alıyor. Kısaca ve basitçe yeni DI yaklaşımı ile .NET Core’da, tek bir yerde uygulamamızın bağlılıkları yönetebiliyoruz.  Farklı DI bileşenlerini de, bu yapının yerine geçebilecek şekilde kullanabiliyoruz tabi ki.

.NET Core içinde DI yapısı, Service Locator tasarım kalıbı ile tasarlanmış. Microsoft.Framework.DependencyInjection.IServiceCollection arayüzünden geliştirilen ServiceCollection üzerinden bağlılıklar oluşturuluyor. Uygulamalardaki bağlılıkları, uygulamaların kullandığı servisler olarak düşünebilirsiniz yani.

            var services = new ServiceCollection();

ServiceCollection sınıfı ile servisleri, yaşam döngülerine göre ekleyebiliyoruz.

            services.AddTransien<IUserService>(s=> new UserManagementService());
            services.AddInstance(typeof(IUserService),new UserManagementService());
            services.AddScoped(typeof(IUserService),s=> new UserManagementService());
            services.AddSingleton(typeof(IUserService),s=> new UserManagementService());

Bağlılıkları 4 tane farklı yaşam döngüsü ile tanımlayabiliyoruz.

  • AddTransient: Her seferinde bağlı nesnenin tekrar yaratılmasını sağlar
  • AddSingleton: Bağlı nesneye erişildiğinde tek bir nesne yaratılmasını sağlar
  • AddInstance: Her nest çağrısında, tanımlanan nesneyi sağlar
  • AddScoped: ServiceCollection’nın kapsamına göre nesnenin yaratılmasını sağlar.

Bu yaşam döngülere göre oluşturulan nesnelere; daha doğru isim ile servislere, IServiceProvider arayüzünden geliştirilen sağlayıcı sınıfı ile ulaşabiliyoruz.


            IServiceProvider provider = services.BuildServiceProvider();
            
            IUserService userService = provider.GetService<IUserService>(); 
            var userName = userService.GetUserName();

Yine tabi ki kendi sağlayıcı sınıfımızı yazmak mümkün. Sağlayıcı sınıfından gelen GetService() metodu ile bağlı olan nesneye/servise erişebiliyoruz.

VS Code

DI yeni ASP.NET 5 ve MVC 6’da built-in bir özellik olarak karşımıza çıkıyor. MVC tarafında çeşitlik konfigürasyon yöntemleri ile web uygulamalarındaki bağlılıkları yönetmek oldukça kolaylaşıyor. Bu yazıda bahsettiğim konunun örnek kodunu GitHub’a ekledim, buradan eklemeler ve düzenlemeler yapabilirsiniz diyerekten bitirelim.Bu giriş yazısı ile umarım biraz merak uyandırmayı başarmışımdır.

Bu yazıyı CoreCLR’ın Beta8 versiyonu ile yazdım. Bu versiyondan sonra Microsoft.Framework.DependencyInjection.* namespace’i Microsoft.Extensions.DependencyInjection.* olarak değişiyor.