From ae9ba8fe832f686f38ae8545f5e91df713c51027 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C4=B0lyas=20Bozdemir?= <52322835+ilyasBozdemir@users.noreply.github.com> Date: Thu, 18 Apr 2024 10:18:46 +0300 Subject: [PATCH 1/5] Create service_lifecycle.md --- docs/1.0.0/service_lifecycle.md | 42 +++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 docs/1.0.0/service_lifecycle.md diff --git a/docs/1.0.0/service_lifecycle.md b/docs/1.0.0/service_lifecycle.md new file mode 100644 index 0000000..dc1f8f3 --- /dev/null +++ b/docs/1.0.0/service_lifecycle.md @@ -0,0 +1,42 @@ +# Hizmet Yaşam Döngüleri + +Bu belge, ASP.NET Core veya .NET Core projelerinde kullanılan hizmetlerin yaşam döngülerini açıklar. Hizmetlerin yaşam döngüsü, hizmet örneklerinin nasıl oluşturulduğunu ve paylaşıldığını belirler. + +## `AddSingleton` + +- `AddSingleton`, hizmetin yalnızca bir örneğini oluşturur ve uygulama boyunca aynı örneği paylaşır. +- İlk kez çağrıldığında hizmeti oluşturur ve bu örneği daha sonra tekrar kullanır. +- Singleton hizmetler, uygulama ömrü boyunca aynı örneğin kullanılması gereken durumlar için uygundur. + +Örnek kullanımı: + +```csharp +services.AddSingleton(); +``` + +## `AddScoped` + +- `AddScoped`, her HTTP isteği için yeni bir hizmet örneği oluşturur ve bu isteğin ömrü boyunca aynı örneği kullanır. + +- Her HTTP isteği bir "kapsam" (scope) oluşturur ve bu kapsam içinde hizmetler paylaşılır. +- Scoped hizmetler, web uygulamaları için kullanışlıdır, çünkü her istemci isteği için ayrı hizmet örnekleri gerekebilir. + +Örnek kullanımı: + +```csharp +services.AddScoped(); +``` + +## `AddTransient` + +- ``AddTransient``, her çağrı veya her istemci isteği için yeni bir hizmet örneği oluşturur. +- Hizmetin yaşam döngüsü, her çağrı veya her istemci isteği için yeni bir örneğin oluşturulmasını gerektiren hızlı geçici hizmetler için uygundur. +- Her isteğe veya çağrıya yeni bir hizmet örneği sağlar. + +```csharp +services.AddTransient(); +``` + + + + From 2010bbbd74ec159343070e4e4641f3b527b56f6d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C4=B0lyas=20Bozdemir?= <52322835+ilyasBozdemir@users.noreply.github.com> Date: Thu, 18 Apr 2024 10:23:17 +0300 Subject: [PATCH 2/5] Create onion-architecture-ve-mediatR.md --- docs/1.0.0/onion-architecture-ve-mediatR.md | 85 +++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 docs/1.0.0/onion-architecture-ve-mediatR.md diff --git a/docs/1.0.0/onion-architecture-ve-mediatR.md b/docs/1.0.0/onion-architecture-ve-mediatR.md new file mode 100644 index 0000000..52afad7 --- /dev/null +++ b/docs/1.0.0/onion-architecture-ve-mediatR.md @@ -0,0 +1,85 @@ +## Geleneksel 3 Katmanlı Mimarinin Dezavantajları + +Geleneksel 3 katmanlı mimari, küçük ve orta ölçekli projeler için uygun olabilir, ancak büyük ve karmaşık projelerde bazı önemli dezavantajlar ortaya çıkar: + +1. **Bağımlılık Sorunları:** Geleneksel 3 katmanlı mimaride, katmanlar arasındaki bağımlılıklar zaman içinde karmaşık hale gelebilir. Bu, uygulamanın değişikliklerini uygulamanın farklı bölgelerine yaymayı gerektirebilir ve bakımı zorlaştırabilir. + +2. **Esneklik Eksikliği:** Geleneksel 3 katmanlı mimari, iş mantığını ve veritabanı erişimini sıkıca birleştirir. Bu, iş mantığını değiştirmeyi zorlaştırabilir, çünkü veritabanı erişimiyle sıkıca bağlantılıdır. + +3. **Performans Sorunları:** Büyük uygulamalarda, geleneksel 3 katmanlı mimari, performans sorunlarına yol açabilir. Özellikle veritabanı erişimi sıkça tekrarlanan sorgular içeriyorsa, bu sorunlar daha belirgin hale gelebilir. + +4. **Test Zorlukları:** Geleneksel 3 katmanlı mimari, test edilebilirlik açısından bazı zorluklar sunabilir. Özellikle iş mantığını izole etmek ve test etmek istediğinizde, veritabanı erişimini izole etmek zor olabilir. + +![Onion Architecture](https://miro.medium.com/v2/resize:fit:720/format:webp/1*MSmpndkRsrNXFao0RlyU2A.png) + +## Onion Architecture'ın Tercih Edilme Nedenleri + +Onion Architecture, geleneksel 3 katmanlı mimarinin bu dezavantajlarını aşmak ve daha iyi bir yazılım tasarımı sunmak için tercih edilir. İşte Onion Architecture'ın neden tercih edildiğine dair bazı nedenler: + +1. **Ters Bağımlılık (Inversion of Control):** Onion Architecture, bağımlılıkları tersine çevirir. İç mantık dışa bağımlıdır, ancak dış katmanlar iç katmanlara bağımlı değildir. Bu, bağımlılık yönetimini ve değişikliklerin izolasyonunu kolaylaştırır. + +2. **Modülerlik ve Kolay Bakım:** Onion Architecture, uygulamayı modüller halinde düzenler. Her modül, kendi bağlamını ve sorumluluklarını taşır. Bu, bakımı kolaylaştırır, genişletilebilirliği artırır ve kodun daha iyi örgütlenmesini sağlar. + +3. **Bağımsızlık:** Onion Architecture, iş mantığını veritabanı veya diğer altyapı detaylarından izole eder. Bu, iş mantığını değiştirmeyi ve test etmeyi kolaylaştırır, çünkü iş mantığı altyapıdan bağımsızdır. + +4. **Performans İyileştirmesi:** Onion Architecture, okuma (query) işlemleri ve yazma (command) işlemleri için farklı modeller kullanarak performansı artırabilir. Bu, veritabanı erişimini optimize etmek için daha fazla esneklik sunar. + +5. **Test Edilebilirlik:** Onion Architecture, iş mantığını izole etmeyi kolaylaştırır ve bu, kodun daha iyi test edilmesini sağlar. Her katmanın belirli bir sorumluluğu olduğu için her birini ayrı ayrı test etmek daha basittir. + +Onion Architecture, büyük ve karmaşık projelerde daha iyi bir kod organizasyonu, bakım ve genişletilebilirlik sağlayarak geleneksel 3 katmanlı mimariye göre birçok avantaj sunar. + +# Onion Architecture, MediatR ve CQRS + +Bu belge, Onion Architecture, MediatR ve CQRS gibi yazılım tasarım kalıplarını anlamak ve uygulamak için bir giriş sunar. Bu tasarım kalıpları, yazılım projelerinizi daha düzenli, bakımı kolay ve ölçeklenebilir hale getirmenize yardımcı olabilir. + +## Onion Architecture Nedir? + +![Onion Architecture](https://miro.medium.com/v2/resize:fit:640/format:webp/1*0Pg6_UsaKiiEqUV3kf2HXg.png) + +**Onion Architecture**, yazılım projelerini katmanlara bölmeyi ve bu katmanların birbirleriyle nasıl iletişim kurduğunu düzenlemeyi amaçlayan bir mimari yaklaşımdır. Bu yaklaşım, aşağıdaki temel katmanları tanımlar: + +### Çekirdek Katman (Core Layer) + +- Bu katman, uygulamanızın iş mantığını içerir. +- Veritabanına, kullanıcı arayüzüne veya harici servislere bağımlı değildir. +- Temel iş kuralları burada uygulanır. + +### Uygulama Servisleri Katmanı (Application Services Layer) + +- Kullanıcı arayüzü (UI) ile çekirdek katman arasındaki iletişimi yönetir. +- Gelen istekleri işler ve çekirdek katmana yönlendirir. + +### Altyapı Katmanı (Infrastructure Layer) + +- Bu katman, harici kaynaklarla (veritabanı, servisler, API'lar) iletişim kurar. +- Veritabanı bağlantısı, dosya sistemi erişimi ve dış servisler burada gerçekleştirilir. + +### Kullanıcı Arayüzü Katmanı (User Interface Layer) + +- Uygulamanın kullanıcılarıyla etkileşime giren web, masaüstü veya mobil arabirimleri içerir. +- Kullanıcı taleplerini işler ve uygulamanın sonuçlarını gösterir. + +Onion Architecture, içten dışa doğru bir bağımlılık düzenlemesi sağlar. Bu, projenin her katmanının diğerlerine bağımlı olmadan geliştirilmesini ve test edilmesini kolaylaştırır. + +## MediatR Nedir? + +**MediatR**, bir olay işleme kütüphanesidir ve yazılım projelerinde olay tabanlı tasarımı kolaylaştırır. Temel özellikleri şunlardır: + +- Birçok nesnenin olaylarını işlemek için kullanılır. +- İstekte bulunan ve olayları dinleyen (handler) nesneler arasında aracıdır. +- Projedeki olayları kolayca dağıtmayı sağlar ve kodu daha modüler hale getirir. + +## CQRS Nedir? + +![Onion Architecture](https://miro.medium.com/v2/resize:fit:720/format:webp/1*TaPzEj91HM06UgZoajqGwA.png) + +**CQRS (Command Query Responsibility Segregation)**, uygulama verilerinin okuma (sorgu) ve yazma (komut) işlemleri için ayrılmış bir modeldir. Temel özellikleri şunlardır: + +- Komutlar, uygulama durumunu değiştirir. +- Sorgular, uygulama durumunu okur. +- Okuma ve yazma işlemleri için farklı veri modeli ve mantık kullanır. +- Uygulama performansını artırabilir ve karmaşık iş akışlarını daha iyi yönetebilir. + +CQRS, özellikle büyük ve karmaşık uygulamalarda işe yarar ve veri okuma ve yazma işlemlerini daha iyi ölçeklendirmenize yardımcı olabilir. + +Bu tasarım kalıpları, yazılım projelerinizi daha düzenli ve bakımı kolay hale getirerek geliştirme sürecinizi iyileştirebilir. İhtiyacınıza bağlı olarak, bu kalıpları projenizde kullanmayı düşünebilirsiniz. From 84fda873724b35ab9ef83667e83f42ae82a7f070 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C4=B0lyas=20Bozdemir?= <52322835+ilyasBozdemir@users.noreply.github.com> Date: Thu, 18 Apr 2024 10:32:03 +0300 Subject: [PATCH 3/5] Update onion-architecture-ve-mediatR.md --- docs/1.0.0/onion-architecture-ve-mediatR.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/1.0.0/onion-architecture-ve-mediatR.md b/docs/1.0.0/onion-architecture-ve-mediatR.md index 52afad7..c708419 100644 --- a/docs/1.0.0/onion-architecture-ve-mediatR.md +++ b/docs/1.0.0/onion-architecture-ve-mediatR.md @@ -81,5 +81,3 @@ Onion Architecture, içten dışa doğru bir bağımlılık düzenlemesi sağlar - Uygulama performansını artırabilir ve karmaşık iş akışlarını daha iyi yönetebilir. CQRS, özellikle büyük ve karmaşık uygulamalarda işe yarar ve veri okuma ve yazma işlemlerini daha iyi ölçeklendirmenize yardımcı olabilir. - -Bu tasarım kalıpları, yazılım projelerinizi daha düzenli ve bakımı kolay hale getirerek geliştirme sürecinizi iyileştirebilir. İhtiyacınıza bağlı olarak, bu kalıpları projenizde kullanmayı düşünebilirsiniz. From 56fc72115c206e6e28fa2faaed88dec1140b140a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C4=B0lyas=20Bozdemir?= <52322835+ilyasBozdemir@users.noreply.github.com> Date: Thu, 18 Apr 2024 10:34:21 +0300 Subject: [PATCH 4/5] Delete docs/1.0.0/onion-architecture-ve-mediatR.md --- docs/1.0.0/onion-architecture-ve-mediatR.md | 83 --------------------- 1 file changed, 83 deletions(-) delete mode 100644 docs/1.0.0/onion-architecture-ve-mediatR.md diff --git a/docs/1.0.0/onion-architecture-ve-mediatR.md b/docs/1.0.0/onion-architecture-ve-mediatR.md deleted file mode 100644 index c708419..0000000 --- a/docs/1.0.0/onion-architecture-ve-mediatR.md +++ /dev/null @@ -1,83 +0,0 @@ -## Geleneksel 3 Katmanlı Mimarinin Dezavantajları - -Geleneksel 3 katmanlı mimari, küçük ve orta ölçekli projeler için uygun olabilir, ancak büyük ve karmaşık projelerde bazı önemli dezavantajlar ortaya çıkar: - -1. **Bağımlılık Sorunları:** Geleneksel 3 katmanlı mimaride, katmanlar arasındaki bağımlılıklar zaman içinde karmaşık hale gelebilir. Bu, uygulamanın değişikliklerini uygulamanın farklı bölgelerine yaymayı gerektirebilir ve bakımı zorlaştırabilir. - -2. **Esneklik Eksikliği:** Geleneksel 3 katmanlı mimari, iş mantığını ve veritabanı erişimini sıkıca birleştirir. Bu, iş mantığını değiştirmeyi zorlaştırabilir, çünkü veritabanı erişimiyle sıkıca bağlantılıdır. - -3. **Performans Sorunları:** Büyük uygulamalarda, geleneksel 3 katmanlı mimari, performans sorunlarına yol açabilir. Özellikle veritabanı erişimi sıkça tekrarlanan sorgular içeriyorsa, bu sorunlar daha belirgin hale gelebilir. - -4. **Test Zorlukları:** Geleneksel 3 katmanlı mimari, test edilebilirlik açısından bazı zorluklar sunabilir. Özellikle iş mantığını izole etmek ve test etmek istediğinizde, veritabanı erişimini izole etmek zor olabilir. - -![Onion Architecture](https://miro.medium.com/v2/resize:fit:720/format:webp/1*MSmpndkRsrNXFao0RlyU2A.png) - -## Onion Architecture'ın Tercih Edilme Nedenleri - -Onion Architecture, geleneksel 3 katmanlı mimarinin bu dezavantajlarını aşmak ve daha iyi bir yazılım tasarımı sunmak için tercih edilir. İşte Onion Architecture'ın neden tercih edildiğine dair bazı nedenler: - -1. **Ters Bağımlılık (Inversion of Control):** Onion Architecture, bağımlılıkları tersine çevirir. İç mantık dışa bağımlıdır, ancak dış katmanlar iç katmanlara bağımlı değildir. Bu, bağımlılık yönetimini ve değişikliklerin izolasyonunu kolaylaştırır. - -2. **Modülerlik ve Kolay Bakım:** Onion Architecture, uygulamayı modüller halinde düzenler. Her modül, kendi bağlamını ve sorumluluklarını taşır. Bu, bakımı kolaylaştırır, genişletilebilirliği artırır ve kodun daha iyi örgütlenmesini sağlar. - -3. **Bağımsızlık:** Onion Architecture, iş mantığını veritabanı veya diğer altyapı detaylarından izole eder. Bu, iş mantığını değiştirmeyi ve test etmeyi kolaylaştırır, çünkü iş mantığı altyapıdan bağımsızdır. - -4. **Performans İyileştirmesi:** Onion Architecture, okuma (query) işlemleri ve yazma (command) işlemleri için farklı modeller kullanarak performansı artırabilir. Bu, veritabanı erişimini optimize etmek için daha fazla esneklik sunar. - -5. **Test Edilebilirlik:** Onion Architecture, iş mantığını izole etmeyi kolaylaştırır ve bu, kodun daha iyi test edilmesini sağlar. Her katmanın belirli bir sorumluluğu olduğu için her birini ayrı ayrı test etmek daha basittir. - -Onion Architecture, büyük ve karmaşık projelerde daha iyi bir kod organizasyonu, bakım ve genişletilebilirlik sağlayarak geleneksel 3 katmanlı mimariye göre birçok avantaj sunar. - -# Onion Architecture, MediatR ve CQRS - -Bu belge, Onion Architecture, MediatR ve CQRS gibi yazılım tasarım kalıplarını anlamak ve uygulamak için bir giriş sunar. Bu tasarım kalıpları, yazılım projelerinizi daha düzenli, bakımı kolay ve ölçeklenebilir hale getirmenize yardımcı olabilir. - -## Onion Architecture Nedir? - -![Onion Architecture](https://miro.medium.com/v2/resize:fit:640/format:webp/1*0Pg6_UsaKiiEqUV3kf2HXg.png) - -**Onion Architecture**, yazılım projelerini katmanlara bölmeyi ve bu katmanların birbirleriyle nasıl iletişim kurduğunu düzenlemeyi amaçlayan bir mimari yaklaşımdır. Bu yaklaşım, aşağıdaki temel katmanları tanımlar: - -### Çekirdek Katman (Core Layer) - -- Bu katman, uygulamanızın iş mantığını içerir. -- Veritabanına, kullanıcı arayüzüne veya harici servislere bağımlı değildir. -- Temel iş kuralları burada uygulanır. - -### Uygulama Servisleri Katmanı (Application Services Layer) - -- Kullanıcı arayüzü (UI) ile çekirdek katman arasındaki iletişimi yönetir. -- Gelen istekleri işler ve çekirdek katmana yönlendirir. - -### Altyapı Katmanı (Infrastructure Layer) - -- Bu katman, harici kaynaklarla (veritabanı, servisler, API'lar) iletişim kurar. -- Veritabanı bağlantısı, dosya sistemi erişimi ve dış servisler burada gerçekleştirilir. - -### Kullanıcı Arayüzü Katmanı (User Interface Layer) - -- Uygulamanın kullanıcılarıyla etkileşime giren web, masaüstü veya mobil arabirimleri içerir. -- Kullanıcı taleplerini işler ve uygulamanın sonuçlarını gösterir. - -Onion Architecture, içten dışa doğru bir bağımlılık düzenlemesi sağlar. Bu, projenin her katmanının diğerlerine bağımlı olmadan geliştirilmesini ve test edilmesini kolaylaştırır. - -## MediatR Nedir? - -**MediatR**, bir olay işleme kütüphanesidir ve yazılım projelerinde olay tabanlı tasarımı kolaylaştırır. Temel özellikleri şunlardır: - -- Birçok nesnenin olaylarını işlemek için kullanılır. -- İstekte bulunan ve olayları dinleyen (handler) nesneler arasında aracıdır. -- Projedeki olayları kolayca dağıtmayı sağlar ve kodu daha modüler hale getirir. - -## CQRS Nedir? - -![Onion Architecture](https://miro.medium.com/v2/resize:fit:720/format:webp/1*TaPzEj91HM06UgZoajqGwA.png) - -**CQRS (Command Query Responsibility Segregation)**, uygulama verilerinin okuma (sorgu) ve yazma (komut) işlemleri için ayrılmış bir modeldir. Temel özellikleri şunlardır: - -- Komutlar, uygulama durumunu değiştirir. -- Sorgular, uygulama durumunu okur. -- Okuma ve yazma işlemleri için farklı veri modeli ve mantık kullanır. -- Uygulama performansını artırabilir ve karmaşık iş akışlarını daha iyi yönetebilir. - -CQRS, özellikle büyük ve karmaşık uygulamalarda işe yarar ve veri okuma ve yazma işlemlerini daha iyi ölçeklendirmenize yardımcı olabilir. From aade20389a00f795bed869a45666a0b3c8050aca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C4=B0lyas=20Bozdemir?= <52322835+ilyasBozdemir@users.noreply.github.com> Date: Thu, 18 Apr 2024 10:34:52 +0300 Subject: [PATCH 5/5] Delete docs/1.0.0/service_lifecycle.md --- docs/1.0.0/service_lifecycle.md | 42 --------------------------------- 1 file changed, 42 deletions(-) delete mode 100644 docs/1.0.0/service_lifecycle.md diff --git a/docs/1.0.0/service_lifecycle.md b/docs/1.0.0/service_lifecycle.md deleted file mode 100644 index dc1f8f3..0000000 --- a/docs/1.0.0/service_lifecycle.md +++ /dev/null @@ -1,42 +0,0 @@ -# Hizmet Yaşam Döngüleri - -Bu belge, ASP.NET Core veya .NET Core projelerinde kullanılan hizmetlerin yaşam döngülerini açıklar. Hizmetlerin yaşam döngüsü, hizmet örneklerinin nasıl oluşturulduğunu ve paylaşıldığını belirler. - -## `AddSingleton` - -- `AddSingleton`, hizmetin yalnızca bir örneğini oluşturur ve uygulama boyunca aynı örneği paylaşır. -- İlk kez çağrıldığında hizmeti oluşturur ve bu örneği daha sonra tekrar kullanır. -- Singleton hizmetler, uygulama ömrü boyunca aynı örneğin kullanılması gereken durumlar için uygundur. - -Örnek kullanımı: - -```csharp -services.AddSingleton(); -``` - -## `AddScoped` - -- `AddScoped`, her HTTP isteği için yeni bir hizmet örneği oluşturur ve bu isteğin ömrü boyunca aynı örneği kullanır. - -- Her HTTP isteği bir "kapsam" (scope) oluşturur ve bu kapsam içinde hizmetler paylaşılır. -- Scoped hizmetler, web uygulamaları için kullanışlıdır, çünkü her istemci isteği için ayrı hizmet örnekleri gerekebilir. - -Örnek kullanımı: - -```csharp -services.AddScoped(); -``` - -## `AddTransient` - -- ``AddTransient``, her çağrı veya her istemci isteği için yeni bir hizmet örneği oluşturur. -- Hizmetin yaşam döngüsü, her çağrı veya her istemci isteği için yeni bir örneğin oluşturulmasını gerektiren hızlı geçici hizmetler için uygundur. -- Her isteğe veya çağrıya yeni bir hizmet örneği sağlar. - -```csharp -services.AddTransient(); -``` - - - -