Object Oriented Programing (OOP) yazılım mantığını gözle görüp hissedebildiğimiz veri veya nesneler etrafında düzenleyen bir programlama dili modelidir. Gerçek hayatta gördüğümüz birçok nesnenin bilgisayar ortamına aktarılması yöntemidir. Bir nesnenin rengi, ismi, boyu, ağırlığı, üretim yılı, üretim yeri gibi birçok özelliklerinin bilgisayar ortamında gösterilmesi durumudur. 1960’larda ortaya çıkan bu programlama tekniği o dönemki geliştiricilerin çekmiş olduğu sıkıntılardan dolayı meydana çıkmıştır.
Nesneye yönelik programlama faktörleri gözetilerek inşa edilmiş bir programın üzerinde yapılacak bir değişiklik programın bütününde eş zamanlı bir şekilde gerçekleşir. Oluşturduğunuz nesnelerin yapıları birbirinden bağımsız olacağı için bilgi gizliliği sağlamış olursunuz. Programınızı oluştururken karşılaşacağınız süreç kısalır ve programın performansı artar. Oluşturmuş olduğunuz nesneleri herhangi bir sınıf içerisinde tüm özellikleri ile kullanma imkanınız olur. Gereksiz kod uzunluklarının önüne geçerek, daha önce oluşturmuş olduğunuz bir kod bloğunu her yerde kullanma imkanınız olur.
Değişkenlerin ve metotların bir arada tutulduğu yerdir.
Verileri saklayan ve bu veriler üzerinde işlem yapan bileşendir.
4 temel özellikden oluşur.
- Soyutlama (Abstraction)
- Kapsülleme (Encapsulation)
- Miras Alma (Inheritance)
- Çok Biçimlilik (Polmorphism)
Nesneler, sadece diğer uygulamaların kullanımı ile ilgili olan ve gereksiz olan uygulama kodlarını gizleyen iç mekanizmayı ortaya çıkarır bu konsept geliştiricilerin de zaman içerisinde daha kolay ekleme ve değişiklik yapmalarına yardımcı olmaktadır.
Her bir nesnenin uygulanması ile durumu özel olarak tanımlanan bir sınır (scope) ya da sınıf içinde tutulmaktadır. Diğer nesneler de bu sınıfa ya da değişikliği yapma yetkisine sahip değil. Ancak sadece genel işlevler ya da yöntemler listesi çağırılabilir. Veri gizlemenin söz konusu bu özelliği daha çok program güvenliği sağlamaktadır ve istenmeyen verilerin bozulmalarını da önler.
Nesneler arasındaki ilişkiler ile alt sınıflar atanabilirler ve bu sayede geliştiricilerin benzersiz olan bir hiyerarşiyi korurken ortak mantığı da tekrar kullanmalarına izin verilir. Nesne yönelimli programlamanın bu özelliği daha da kapsamlı bir veri analizini zorlar ve geliştirme süresini azaltır, yüksek bir doğruluk düzeyini sağlar.
Nesnelerin içeriğe de bağlı olarak birden çok forma girmesine izin verilir. Program, söz konusu kodun çoğaltılması gerekliliğini de azaltacak şekilde nesnenin her yürütülüşü için hangi kullanımın ya da anlamın gerekli olduğunu belirleyecektir.
Clean Code (Temiz Kod) anlaşılır, degiştirilebilir ve geliştirilebilir koddur. Yazılan bir kodun bilgisayarlar tarafından anlaşılabildiği gibi başka geliştiriciler tarafından okunabilir ve geliştirilmeye açık olması gereklidir. Bir projeye yeni başlandığında geliştirme hızı yüksektir ama proje büyüdükçe hantallaşır ve karmaşıklaşmaya başlar yada geliştiriciler değiştikçe gelişim hızı yavaşlık gösterebilir bu tür aksaklıklar yaşanmasın diye Clean Code Prensibi meydana getirilmiştir.
- Metotların hangi amaçla kullanıldığı açıktır.
- Bir süre sonra koda tekrar bakılması gerektiğinde anlaşılabilirliği kolaydır.
- Başka geliştiricilerde kolaylıkla anlayabilir.
- Daha kolay test edilebilir.
- Tekrara düşmez.
- Kodu basit ve anlaşılabilir tut.
- Standart yaklaşımları uygula.
- Bir sınıf doğrudan sadece bağımlılıklarını bilmelidir.
- Koşul ifadeleri kullanmak yerine polymorphism tercih edilmeli.
- Yapılandırılan veriyi kodun derinliklerinde değil daha kolay ulaşıp değiştirilebilen yerlerde bulundur.
- Kullanmaya başladığın yöntemi değiştirme.
- Açık ve anlaşılır değişken isimleri kullan.
- Aynı sınıflar içerisinde başka şeylerle bağımlılığı olan metotlar yazmayın.
- Açıklayıcı isimler kullanılmalı.
- İsimlendirme ile anlamlı ayrımlar oluşturun.
- Aradığınızda kolay ulaşılabilir isimlendirmeler yapın.
- Küçük olmalı.
- Bir tek iş yapmalı.
- İsmi açıklayıcı olmalı.
- Olabildiğince az argüman almalı
- Gereksiz yorum kullanımından kaçının.
- Yorumu yazma sebebinizi anlaşılır dille açıklayın.
- Kodun açıklaması şeklinde yazın.
- Test okunabilir olmalıdır.
- Hızlı çalışır olmalıdır.
- Bağımsız olmalıdır.
- Test tekrar edilebilir olmalıdır.
Bazen temiz kod kurallarına uyulmaya çalışılsa bile istenmeyen nedenlerden dolayı temiz kod kalitesinde yazamayız ve takımın deneyimsizliği, zamanın kısalığı, yönetimsel hatalar gibi sebeplerden dolayı kötü kod ortaya çıkar kodunuz ile ilgili bu tarz sinyaller alıyorsanız kodunuzda düzenlemeler yapmanız gerekir buna refactoring işlemi denir.
SOLID Prensipleri etkili, esnek ve doğru kodlama standartlarının sağlanması için takip edilen prensipler bütününe verilen addır. SOLID temel olarak 5 prensibin oluşturduğu baş harflerden meydana gelir.
Bunlar;
- Single-responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
- Kodun güncelleme ve düzenlemelere kolayca adapte olması.
- Kod değişikliğini en kısa ve kolay seviyeye indirmek.
- Temiz kod yazmayı sağlamak.
- Karmaşık kodlardan kaçınmak.
- Kodu esnek bir şekilde kullanmak
- Yazılan kodu okuyan ve geliştiren her kişi tarafından yeterince anlaşılır kılmak
Bu prensibe göre amaç bir sınıfın yalnızca tek bir sorumluluğu olmalıdır. Yazılımınızın içinde birden fazla görev yapan kısım olmamalıdır. Bu prensip, yazılım kodunda her bir sınıfın, modülün veya metodun yalnızca bir iş yapması gerektiğini savunur.
Yazılan kodlar ekleme ve geliştirilme için açık ancak köklü değişiklikler için kapalı olmalıdır. Open Closed geniş çapta uygulanabilen ancak değişmeden kalan varlıklar gerektirir. Bu noktada çok biçimlilik (polymorphism) ile özel davranışlara sahip yinelenen varlıklar yaratmamız gerekir.
Bir programdaki nesneler o programın doğruluğunu değiştirmeden alt türlerinin örnekleriyle değiştirilebilir olmalıdır yani her alt sınıf, alt sınıfa özgü tüm yeni davranışlarla birlikte temel sınıftaki tüm davranışları korumalıdır. Alt sınıf, aynı istekleri işleyebilmeli ve üst sınıfıyla aynı görevleri tamamlayabilmelidir.
İsteme özel birden fazla arayüz , tek bir genel amaçlı arayüzden daha iyidir. ISP’de sınıfların kullanmadıkları davranışları içermesi istenmez. ISP Sayesinde; Daha az kod taşıyan metotlar elde edilir. Kodun ihtiyaç durumunda güncellemesi hızlanır. Davranıştan bir metot sorumlu olduğu için davranışta karşılaşılan problem hızlı bir şekilde çözülür.
Sınıf ve doğru özellekliklerin sınıfa eklenmesi açısından en önemli Nesne Yönelimli Programla konularından biriside Abstraction (Soyulama) konusudur. Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Bunun yerine, her ikisi de abstraction veya interfacelere bağlı olmalıdır. Abstraction detaylara bağlı olmalıdır tam tersine detaylar soyutlamaya bağlı olmalıdır.
- Single Responsibility: Sınıflar iyi tanımlanmış tek bir sorumluluk almalı.
- Open/Closed: Sınıflar değişikliğe kapalı geliştirilmeye açık olmalıdır.
- Liskov Substution: Kodumuzda herhangi bir değişiklik yapmaya gerek kalmadan türetilmiş sınıfları ata sınıf yerine kullanabilmeliyiz.
- Interface Segregation: Genel kullanım amaçlı tek bir arayüz yerine özelleşmiş birden çok arayüz oluşturma tercih edilmeli.
- Dependecy Inversion: Katmanlı mimarilerde üst seviye modüller alt seviyedeki modüllere doğrudan bağımlı olmamalıdır.
Konumuz Design Pattern (Tasarım Deseni) peki nedir bu tasarım desenleri. Günlük yaşantımız içinde istemeden birçok sorun ile karşılaşıyoruz ve bu sorunlar için çözümler arıyoruz kendi imkanlarımız içinde bulduğumuz bu çözümler kimi zaman işe yararken kimi zaman daha da güç durumlar oluşmasına sebep oluyor ancak işe yarayan çözümler sonradan oluşacak benzer problemler için bize önceden bir çözüm yolu sunuyor. Peki yazılım dünyasında problemlerimizden ders çıkarıp çözümler bulup bunları tekrarlamamak isteseydik ne olurdu?
Design Pattern, yazılımcıların yazılım geliştirirken karşılaştıkları yada karşılaşabilecekleri sorunların genel çözümleridir. Yazılım tasarımında ortaya çıkan yaygın sorunlara karşı en basit biçimde yeniden kullanılabilir çözümler sağlar. Temelleri 1970 yılında ilk olarak mimarlar tarafından atılan, 1995 senesinde Dörtlü Çete tarafından yayınlanan kitap ile yaygınlaşan Design Pattern yazılım içerisinde kullanılmasında dönüm noktası olmuştur. Eric Gamma, Richard Helm, Ralph Johnson ve John Vlissides 1995’te “Design Patterns : Elements of Reusable Object — Oriented Software” kitabını çıkardılar. Bu dörtlü ayrıca “Gang of Four” olarak da bilinir. Bu dörtlü kitaplarında 3 kategoride 23 farklı kalıba yer vermişlerdir.
Tasarım Desenleri genel olarak 3 ana başlıkta incelenir. Bunlar şunlardır:
- Creational Patterns (Yaratımsal Desenler): Nesnelerin oluşturulmasında ve yönetilmesinde kullanılan bir desendir. Bu program akışında hangi nesneye ihtiyaç varsa onu oluşturmada esneklik ve kolaylık sağlar.
- Structural Patterns (Yapısal Desenler): Birden fazla sınıfın bir işi yerine getirirken nasıl davranacağını belirlemek için kullanılan desenlerdir.
- Behavioral Patterns (Davranışsal Desenler): Nesnelerin birbirleri ile ilişkisini düzenleyen desendir.
Creational Pattern (Yaratımsal Desenler) Bu tasarım deseni kendi içerisinde 5 gruba ayrılıyor.
- Singleton Pattern
- Factory Pattern
- Abstract Factory Pattern
- Builder Pattern
- Prototype Pattern
Structural Patterns (Yapısal Desenler) Bu tasarım deseni kendi içerisinde 8 gruba ayrılıyor.
- Adapter Pattern
- Bridge Pattern
- Filter Pattern
- Composite Pattern
- Decorator Pattern
- Facade Pattern
- Flyweight Pattern
- Proxy Pattern
- Visitor Pattern
Behavioral Patterns (Davranışsal Desenler) Bu tasarım deseni kendi içerisinde 10 gruba ayrılıyor.
- Command Pattern
- Interpreter Pattern
- Iterator Pattern
- Mediator Pattern
- Memento Pattern
- Observer Pattern
- Null Object Pattern
- Strategy Pattern
- State Pattern
Temelinde (Presentation, Application, Persistence, Infrastructure, Domain) olmak üzere 5 ana katmandan oluşan bu mimari Jeffrey Palermo tarafından tanıtıldı. Klasik N-tier katmanlı mimarinin ileride oluşturacağı sorunlara çözüm sunan Onion mimariyi klasik mimariden ayıran en büyük fark Domain katmanını (Entity Nesnelerini) tüm uygulamanın merkezi haline getirmesidir. Bu yaklaşım ile beraber test edilebilirlik, güvenilirlik ve sürdürülebilirlik daha da gelişmiştir. Böylece klasik mimarideki yaşanılan problemleri aşabilmemize ve olası değişiklik durumlarında daha az efor sarfedip hızlı bir çözüm sunmamıza yardımcı olur. Tüm bunlar yaşanırken uygulamanın katmanları arasında gevşek bağlılık (Loose Coupling) oluşturmamızada olanak sağlar.
Application katmanı, Domain katmanında bulunan veritabanı nesnelerinin CRUD işlemlerinin arayüzünün (Interface) tutulduğu katmandır. Burada amaç gevşek bağlı (Loose Coupling) bir sistem oluşturmaktır.
Domain katmanı, uygulamanın merkezinde bulunan katmandır. Bu katmanda bütün veritabanı nesnelerimiz bulunmaktadır.
Infrastructure katmanı bir altyapı katmanı olarakda kullanılabilmekte aynı zamanda uygulama içerisinde kullanılacak veritabanı işlemi gerektirmeyen dış kaynak servislerin eklendiği katmandır. Örnek resimde görüldüğü gibi en dış katmanda bulunduğu için başka bir iç katman tarafından referans işlemi olmamalıdır.
Persistence katmanı, veritabanı ile ilgili işlemerimizi (Context, Migration, Configuration) gerçekleştirdiğimiz katmandır. Buna ek olarak Application katmanında bulunan arayüzlerinde (Interface) bu katmanda implement işlemleri gerçekleştirilir.
Presentation katmanı, bu katmanda projenin kullanıcı ile nasıl iletişime geçeceğini belirliyoruz (Web App, Web Api, Mvc, Console App)
Entity Framework Core (EF Core), Entity Framework veri erişim teknolojisinin basit, genişletilebilir, açık kaynak ve platformlar arası bir sürümüdür. EF Core nesne ilişkisel bir eşleyici (ORM) aracı olarak görev yapabilir. DotNet geliştiricilerinin .Net nesnelerini kullanarak bir veritabanıyla çalışmasını sağlar. Aynı zamanda EF Core birden fazla veritabanı altyapısını destekler
Uygulama geliştirirken hiç şüphesiz ihtiyaç duyduğumuz şeylerden birisi veritabanı bağlantısı oluşturmaktır. Ancak bu bağlantıyı oluştururken bunun yönetiminide kullandığımız dilin yapısı ile yapmayı tercih ederiz işte tam bu noktada yardımımıza ORM araçları yetişiyor ve kod içerisindeki sql komutlarını ortadan kaldırıyor. Veritabanımızda bulunan tablolara karşılık bir sınıf, kolonlardaki alanlara karşılık gelecek property oluşturuyor bununla beraber veritabanındaki bulunan kayıtlarımızada ait olduğu sınıfta bir obje olarak erişebilmemize olanak sağlıyor. ORM sanal olarak veritabanındaki bir tablonun ona karşılık oluşturulan bir nesne ile eşleşmesidir.
Entity Framework Core konusundan bahsetmişken Fluent Api hakkında da birkaç bişey yazmak istedim ve uygulama içerisinde bir örnek verdim. Fluent Api, Entity Framework Code First yapısını kullandığımızda veri tabanı sınıflarımızın özellikleri ve bu sınıflarımızın ilişkilerini oldukça geniş bir şekilde yapılandırabilmemize olanak sağlayan bir yapıdır.
Code First uygulamada kullanılan veritabanı ile programlama dili arasında bir bağ oluşturur. Uygulamanın ihtiyacı olan veritabanı işlemlerini Visual Studio üzerinden gerçekleştirmemize imkan sağlayan bir yaklaşımdır. Code First yaklaşımı veritabanı işlemlerini veritabanı arayüzünü kullanmadan yada oldukça az ihtiyaç duyarak gerçekleştirmemizi amaçlar.
Table Per Type (TPT) Entityler arasında oluşan kalıtımsal ilişki durumunda ortaya çıkan bir davranış modelidir. Bu model ile birlikte veritabanında bulunan bir tablodaki belirli kolonların kendisinden kalıtım almış olan diger tablolarda birebir ilişki ile tutulmasıdır. Bunun ne demek olduğunu daha iyi anlamak için gerçek hayat ile ilişkili küçük bir örnek düşünelim. Bir bisiklet dükkanında 2 farklı bisiklet çeşidi bulunsun bunu veritabanında modellediğimizi düşünürsek birbirini tekrar eden alanları Bisikletler isminde dükkandaki bütün bisikletlerin kaydını tutacak bir tabloda tutarız ve bu base (temel) class'dan kalıtım alan indirimli ve ikinci el derived (türetilmiş) class'lar oluştururuz. Bu sayede her bisiklette bulunması gereken kolonların tekrarından kaçınırız aynı zamanda bu durum aralarında mantıksal bir kalıtım işlemi olduğu anlamınada gelir.
Table Per Hierarchy (TPH) Entityler arasında oluşan kalıtımsal ilişki durumunda ortaya çıkan bir diğer davranış modelidir. TPH davranış modelinde birbiri ile kalıtımsal hiyerarşi içinde bulunan tüm veritabanı nesneleri için veritabanında tek tablo oluşturulur. Veriler tutulurken base (temel) class içerisinde bulunan alanlar ve işlemi gerçekleştirdiğimiz derived (türetilmiş) class içindeki alanlar doldurulurken diger alanlar null şekilde bırakılır. Peki derived (türetilmiş) class'ları birbirinden nasıl ayırt ediyoruz işte burada EF Core tabloya Discriminator (Ayrımcı) adında bir alan daha ekliyor. Şimdi TPH davranış modelini de daha iyi anlamak için gerçek hayat örneği oluşturalım. Telefon ve tablet satışı yapan bir dükkanda tüm marka ve özelliklerin tutulduğu bir veritabanı modelleyelim bize lazım olan bir adet base (temel) class bu sınıf içerisinde satıcı bilgisi tutuyor olsun ve bu sınıftan kalıtım alan 2 tane derived (türetilmiş) class oluşturalım böylece elimizde 3 tane veritabanı nesnesi olduğu halde TPH davranış modeli bizim için bunları veritanında tek bir tablo halinde tutacaktır. Peki bu bize ne sağlar;
- Tüm veriler tek bir tabloda saklandığından CRUD işlemlerinde yüksek performans.
- Veritabanındaki minimum tablo sayısı.
Bir yazılım projesinin olmazsa olmaz konusu olan Repository Pattern hakkında biraz konuşalım. Generic Repository Pattern adından da anlaşılacağı gibi genel bir repository yapısı kurmamızı sağlıyor. Bu ne demek derseniz ortak veritabanı işlemlerimiz için merkezi ve genel bir yapı kurup her bir modelin bu yapı üzerinden işlem gerçekleştirmesini sağlamaktır. Daha anlaşılır bir örnek vermek gerekirse oluşturduğumuz her veritabanı nesnemiz için ortak olan Create, Read, Update, Delete (CRUD) işlemleri bulunmaktadır. Dont Repeat Yourself (DRY) prensibine uymak amacıyla bu CRUD işlemlerini her seferinde tekrarlamak yerine ortak bir repository sınıfı içerisinde oluşturup ihtiyaç dahilinde oluşturmuş olduğumuz sınıflarda kalıtım yoluyla kullanılmasıdır.
Command Query Responsibility Segregation (CQRS) pattern adından da anlaşılacağı gibi Command ve Query operasyonlarının birbirinden ayrılmasını savunan bir tasarım desenidir. Peki nedir bu Command ve Query operasyonları. Geliştirmiş olduğumuz projeye temelde iki çeşit istek yapılır bunlardan sistemde hiç bir değişiklik yapmadan sadece okuma/read işlemi yapanlara Query (GetAll, GetById), sistemde herhangi bir değişikliğe yol açan yeni bir veri ekleme, var olan veri üzerinde değişiklik yapma yada var olan veriyi silme gibi yazma/write işlemlerinede Command (Insert, Update, Delete) denir. Avantajları;
- CQRS, okuma ve yazma işlemlerinin birbirinden ayrılması iş yüklerinin bağımsız olarak ölçeklendirilebilmesine olanak tanır.
- Read ve write işlemleriniz için farklı veritabanları kullanabilirsiniz.
- Read ve write işlemleri birbirinden ayrıldığı için, herhangi yapılacak bir read işleminde write işlemini beklemek zorunda kalmayız.
Mediator birden çok nesne veya sınıf arasındaki iletişim karmaşıklığını azaltmak için kullanılır. Bu pattern, normalde farklı sınıflar arasındaki tüm iletişimleri yöneten ve gevşek bağlantıyla kodun kolay bakımını destekleyen bir arabulucu sınıfı sağlar. Mediator pattern Behavioural Pattern (Davranışsal Desenler) kategorisine girer. Temel olarak Mediator iki işlem gerçekleştirir.
- Gelen talebi işler ve yanıt sağlar.
- Gelen isteği kabul eder.
AutoMapper birbirinden farklı tipteki complex objeleri birbirine otomatik bir şekilde dönüştürmeye yardımcı olan kütüphanedir. Kodun kirli görüntüsünden bizi kurtararak birden fazla satırda objenin her bir elemanını tek tek birbirine dönüştürmek yerine tek satırda objenin kendisini dönüştürmemize olanak sağlayarak fazla satır ile kodun kötü görünmesini engeller
Bir yazılım geliştirici olarak yazdığımız kodun çalışması bizim için yeterli değildir, aynı zamanda sistemin düzgün ve kararlı bir çalışma göstermesini isteriz. Bu kararlılığı sağlamak için validasyon (doğrulama) işlemlerini kullanırız. Küçük sistemlerde if-else sorguları yada kendi yazdığımız basit yapıları kullanabiliyorken proje içeriği büyüdükçe işler daha da zorlaşabiliyor. Bu nedenle Fluent Validation kütüphanesinden yardım alıyoruz. Fluent Validation bir veri doğrulama kütüphanesidir. Verilere doğru şekilde kısıtlamalar eklenmesini sağlayarak kurallara uygun ve kullanıcı kaynaklı hataların önüne geçilmesinde bize yardımcı oluyor aynı zamanda birden çok if-else sorgusu yazmamıza gerek kalmadığı için kodun daha okunaklı ve anlaşılabilir olmasını sağlıyor.
Microsoft dokümantasyonu içerisinde Identity yapısını şöyle tanımlanıyor:
- Kullanıcı arayüzü (UI) giriş işlevini destekleyen bir API
- Kullanıcıları, şifreleri, profil verilerini, rolleri, istekleri, tokenları, e-posta onayını ve daha fazlasını yönetir.
Authentication (Kimlik Doğrulama) bir kullanıcının sisteme giriş yetkisinin olup olmadığının kontrol edilmesi işlemidir.
Authorization (Kimlik Yetkilendirme) sistemde var olan kullanıcının hangi yetkilere sahip olduğunun belirlenmesidir.
Role sisteme giriş yapan bir kullanıcının hangi rollere sahip olduğunu ve bu rollerin kullanıldığı yerlerde kontrol sağlayan yapıdır.
Claims sisteme giriş yapan kullanıcının kendisine ait bilgilerinin tutulduğu yapıdır Örneğin; email, username, doğrulama sorusu Claims ile tutulan bilgilerden bazılarıdır.
Third Party Authentication (Üçüncü taraf kimlik doğrulamadır) kullanıcının aktif olarak oluşturmuş olduğu sosyal medya kanalları ile giriş yapabilmesidir. Örneğin Facebook, Twitter, Google
Loglama, bir sistem üzerinde gerçekleştirilen işlemlerin kayıt altında tutulmasıdır. Örnek verecek olursak sisteme kim giriş yaptı? Sistemi kim kullanıyordu? Hata kodu nedir? Ne zaman gerçekleşti? Uygulama neden başarısız oldu? gibi kayıtlar oluşturmamızı sağlar. Loglar aynı zamanda uygulamanın runtime'da yaşadığı problemleri yönetebilmemiz konusunda da bize kolaylık sağlar.
Serilog, sistemdeki logları console, file, database vb. aktarmamızı sağlayan bir kütüphanedir. Serilog kütüphanesini diğer log kütüphanelerinden ayıran durum oldukça kullanışlı bir şekilde yapılandırılmış günlük kaydı (Structed Logging) özelliğidir. Ayrıca performans konusunda da çok başarılı bir log kütüphanesidir.
Structured Logging, bir veriyi nesne yapısında loglama ve bu yapısal veriyi kolay bir şekilde sorgulama işlemidir diyebiliriz.
SignalR, açık kaynak kodlu bir .Net kütüphanesidir, gerçek zamanlı çalışan uygulamalar geliştirmek için kullanılır. Http bağlantılarında client ile server arasındaki iletişim her istek yapıldığında yenilenirken, SignalR ile client ve server arasında sürekli bir bağlantı oluşturulur. Bunu daha iyi anlamak için şu iki kıyası yapabiliriz. Bir veri üzerinde değişiklik yapmak istedeğimizde Http protokolü vasıtasıyla bu işlemi gerçekleştirmiş olsaydık bu güncellemenin görüntülenmesi için sayfayı yenilemek durumunda kalırdık. Ancak SignalR kütüphanesinde bulunan Remote Procedure Calls (RPC) özelliği ile bir veride değişiklik olduğunda server bir javascript (js) kodu çağırarak bunu Client'lara haber verir. Bu sayede gerçek zamanlı olarak çalışan uygulamalar elde edebiliriz.