.Net Core CQRS + MediatR | CQRS Pattern | Mediator Pattern
HTML-код
- Опубликовано: 7 сен 2024
- CQRS ve Mediator Pattern'i anlatarak küçük bir örnek yaptığımız bu videoda, bu kalıpların neden ve nasıl kullanıldıklarına dair açıklamalara yaparak bir proje geliştirdik. Mediator pattern'ini uygulayabilmek için ise MediatR isimli kütüphaneyi kullandık.
#DotnetCore #CQRS #MediatR
#blazor #docker #dotnet
Kanala Abone Olmayı Unutmayın!
To Subscribe: bit.ly/3kvj2vw
Github: github.com/sal...
Uzun zamandır sizden dinlemeyi beklediğim konu. Bugün yarın mutlaka uygulayarak izleyeceğim. Teşekkürler!
Hem bu video hem de onion mimarisi videoları için teşekkürler, emeğinize sağlık
Çok iyisin yaaa aradığım bütün bilgiler kanalında mevcut ağzına yüreğine sağlık
Çok teşekkür ederim. İyi Seyirler
Zor bir konu ama gayet sade ve anlaşılır anlatılmış.
Çok güzel bir anlatım olmuş emeğinize sağlık hocam
her zamanki gibi kaliteli bir video daha
Çok teşekkür ederim. Anlaşılması zor konulardan birisi bu cqrs pattern. Umarım faydalı olmuştur
Teşekkürler. Çok faydalı oldu.
Teşekkürler hocam
Tesekkurler, güzel anlatılmış
Elinize sağlık güzel anlatım 👌
tesekkurler
Üstad uzun zamandır Onion Mimariyi sizinki gibi güzel anlatan ilk defa rastladım. Teşekkür ederim. Ek olarak sizden Elasticsearch, RabbitMq ve gRPC konularını microservis mimarisi içerisinde aktarmanızı istiyorum ama özel istirhamım RabbitMq ve gRPC'yi bazı arkadaşların yaptığı gibi email gönderme gibi yavan örnekler ile değil farklı microservisler arasında crud ve transaction işlemleri sürecinde veri tutarlılığı gibi profösyonel düzeyde sizin kalitenizde aktarmanızı rica ediyorum. Saygılar...
Merhabalar, öncelikle çok teşekkür ederim elimden geldiğinde açıklayıcı anlatmaya çalıştım. Elastic, RabbitMq ve gRPC gibi kavramlar bildiğiniz gibi çok geniş kavramlar ancak en genişi ise Mikroservisler. MicroService mimarisinde Transaction bütünlüğü, Event-Driven yöntemi, CAP Teoremine bağlı olarak sistemin devamlılığını sağlamak ise çok daha karmaşık kavramlar. RUclips'da bir kaç video da anlatmak tüm bu kavramlar için haksızlık olur. Belki küçük küçük bahsederek başlanabilir ama yine de bahsettiğiniz gibi Profesyonel yöntemleri uygulamak ve bu uygulamaları açıklayıcı olacak şekilde anlatmak biraz uzun ve büyük bir iş. Ama RabbitMQ ve gRPC konularında bir kaç video hazırlamayı planlıyorum. En azından bazı kavramlara giriş yapmış oluruz daha sonra büyük projelerde kullanırken çok fazla açıklama yapmaya gerek kalmadan hızlıca ilerlenebilir. İlginiz için teşekkür ederim.
@@TechBuddyTR Üstadım en azından farklı Microservis’ler arasındaki CRUD ve transaction işlemlerinde en azından RabbitMQ kullanımına ve gRPC konularına değinirseniz bu bile önemli bir kapı aralayacaktır. İnanın webde tek Microservis üzerinden RabbitMQ anlatımları baya kastı😀. Dört gözle bekliyor olacağım saygılar sunarım.
emeğinze sağlık hocam
Udemyde full course dersleri cekseniz iyi olur!(seviniriz) anlatim tarziniz harika!!!
Çok teşekkür ederim ama udemy nin bir miktar çöplüğe dönüştüğünü düşünüyorum. Gerçekten kaliteli kursları bulması gayet zor. Hem de kendilerinin fiyat politikasını da pek tasvip etmiyorum. Şimdilik youtube dan devam etmek istiyorum. Katkıda bulunmak isterseniz Katıl Üyesi olabilirsiniz :-)
arkadaş dur ne udemy si ya
İçerik gerçekten kaliteli. Türkçe kaynak olarak daha iyisi yok :D Bir sorum var hocam. Post isteği gönderdiğinizde yada command isteği diyelim. Geriye createdEntity'i döndürme durumuna olmaması gereken bir durum dediniz. İnternette bazı kaynaklara baktım onlar createdEntity'i dönmüşler. Bunun gibi çok durumla karşıkaşıyorum. Mesela CleanArchitecture da bazı örneklerde Infrastructere a Domain referans verilmiş bazılarında verilmemiş. Kaynaklara baktığımda verilmediğini anlıyorum. Bu ve bunun gibi bilgilerin doğruluğuna vs. Tarzında da video çekebilir misiniz ? Teşekkürler. Saygılarımla.
tüm içtenliğimle söylüyorum yorum yapmak için değil H A R İ K A
Güzel içerikler üretmişsiniz, çalışmalarınızın devamını temenni ederim, bu konu hakkında nacizane bir sorum var.
Anlatımda da bahsettiğiniz gibi genellikle CQRS farklı iki assembly üzerinden tasarlanıyor; Command için T-SQL kullanırken Query için NoSQL veya PostgreSQL kullanmak mümkün mü? böyle bir senaryoda View oluşturmak mümkün mü?
Write ve read için ayrı db ler kullanmakta sorun yok, hatta cqrs bizi buna teşvik ediyor ama buradaki problem veritabanlarının senkronize olması. Eğer write işleminden sonra db lerin sync olmasıno garanti ediyorsanız read tarafında ne kullandığınızın pek bir önemi kalmıyor. EventSourcing burada kullanılan pattern oluyor genelde ve EventStore aracı bu iş için biçilmiş kaftan. Read tarafında kullandığınız db ye göre istediğiniz view leri oluşturabilirsiniz, sonuçta veri tek db den geliyor. Daha kolay viewler oluşturabilmek için ise CouchBase tercih edilebilir nosql db olarak.
@@TechBuddyTR Detaylı cevabınız için teşekkür ederim.
Her proje çok büyük, karmaşık ve çok trafik alan bir uygulama olmuyor. Hatta çoğu proje olmuyor. Buna rağmen bazı insanlar hiç gerek olmamasına rağmen sağda solda okuduklarına özenerek microservice yapmaya ve farklı farklı mimariler alt yapılar kullanmaya çalışıyor.
Benim sorum şu; daha küçük ve geleneksel monolith projelerde Clean Achitecture + CQRS kullansak fazla abartmış olur muyuz? Özellikle CQRS için illa 2 tane veritabanı kullanmak zorunda mıyız? Daha fazla kod yazılmasına rağmen command ve query'leri bölmesi ve her birinin kendi handler'ı olması bana daha solid geliyor.
Mikroservise geçmek büyük bir karar. Basit monolith uygulamaların eğer çok büyük değillerse mikroservislerden daha mantıklı olduğu bir sürü senaryo var. Over engineering diye geçiyor bu. YAGNI diye bir ilke var. You aren't gonna need it. Kullanmayacaksan o özelliği geliştirmeye gerek yok.
CQRS için 2 veritabanı olması gerekmiyor elbette. Ama asıl kullanım ama bu yönde. Küçük uygulamalarda CQRS kullanmak ve hepsinin handler larını ayırmak keyifli olabilir ama bu sayının çok çok artmamasına dikkat etmek lazım aynı proje içinde.
CQRS bir servisin methodlarını mediatr ile çağırırken istediğim nesneyi vererek sonuç alma doğru mu anlıyorum ? Her servis methodunu class lar böyle parçalamak ayırmak çok işçilik istiyor. Güzel miii değil miii çözemedim.
CQRS'in amacı değil bu bahsettiğiniz. Bundan önceki tanım videosunu izleyebilirsiniz.
Salih hocam merhabalar, CQRS'de Create Command'larımızda DTO yerine doğrudan propertyleri mi tanımlamalıyız? mesela CreateProductCommand içerisinde ProductDto yerine ProductId, ProductName, Price şeklinde ayrı ayrı mı vermeliyiz? Bunun best practice'si bu mudur?
Evet property leri tanımlamalıyız. Çünkü bir nevi bir dto yaratıyoruz gibi düşünebiliriz dış dünyanın kullanması için.
@@TechBuddyTR teşekkür ediyorum, emeğinize sağlık.
Hocam şunu sormak istiyorum. Ben autofac ile oluşturacağım IOC konteynırımı hangi katmanda oluşturmalıyım ?
infrastructure
Merhaba, bu desing pattern’i kullandığım zaman projeme ne katmış olucam anlayamadım açıkçası. Kod okunabilirliğini arttırabilirim onun dışında aklıma gelen bir şey yok
katmanlar arası bağımlılık azalmış olacağı için, projenin büyümesi sırasında her katman kendi görevini yapacağı için, hem kod yazarken tek bir katmana yönelerek bölünmemiş olacaksınız hem de gerektiğinde istediğiniz bir katmanı denklemden çıkartıp yerine yenisini ekleyebileceksiniz çok hızlı ve kolay bir şekilde. Diyelim ki Infrasturcure katmanınızı değiştirerek, artık SQL server değil de Redis kullanacaksınız. Bu durumda değişiklikleri sadece infrasturcure katmanında yapmanız yeterli olacak. diğer noktalarda bir şey değiştirmeye gerek kalmayacak.
@@TechBuddyTR Bu kadar ayrıntılı biçimde cevapladığınız için kendi adıma teşekkür ederim tam olarak ne avantajı olduğunu anlayamamıştım
farklı bir sorum olacak. gerçek projelerinizde de id leri guid olarak mı veriyorsunuz. guid index lemelerde performans sorunları çıkarmıyor mu?
Merhabalar, Genelde Guid kullanmaya özen gösteriyorum. int ve Guid kullanmanın ikisinin de hem avantajı hem dezavantajı var. Şu linkte Guid kullanımı ile ilgili bazı bilgilere yer verilmiş. Index kullanmayı doğru bilirsek çok kötü bir performans kaybı olmuyor bizim için.
dba.stackexchange.com/a/266
@@TechBuddyTR bu konuyu baya araştırdım. Database ler den makalelere kadar. Hangi projede nasıl kullanılmış şeklinde. Profesyonel kişilerin guid kullanımındaki fikirleri önemli oluyor. Int in dezavantajı nedir. tahmin edilebilir olması sizin için bir dezavantaj mıdır. Teşekkür ederim.
Evet tahmin edilebilir olması bir problem. Veritabanları veya tablolar arası veri taşıma işlemlerinde ise int ID kullanımı yine bir dezavantaj. Çünkü tabloda o alanın unique olması gerekiyor ama başka bir tablodan taşırken her iki tablonun kendi id leri çalışabilir. Veri taşıma bulk insert gibi konularda, sadece tablo bazında unique olması genelde baş ağrıtıcı olabiliyor
Peki CQRS ile oluşturulan ve db leri ayrılan bir projede primary key ler Guid mi tercih edilmeli. Data taşıma var ama birleştirme yok.
Med yerine Feature yazsaydın, o an bittiğim an dı...
hocam font size hariç her şey güzel.
Font'u da sonraki videolarda düzelttik :)
@@TechBuddyTR Farkettim hocam eline sağlık :)