B7 | Mikroservis Projesi Catalog Service | SellingBuddy

[@hikmetfazila6299]

emeğinize sağlık hocam.

[@TechBuddyTR]

Teşekkürler :)

[@erolaktepe]

Ellerinize, ağzınıza sağlık güzel olmuş.. teşekkürler..,

[@emregecer1216]

Domain icindeki CatalogItem entity yeni kolonlar eklenmis. Bu yapilan guncellemeden neden bahsetmediniz ?

[@aog.tr.6828]

Teşekkürler.

[@emregulten1874]

teşekkürler

[@dankogulsoy]

Yine bir süper video olmuş.

[@TechBuddyTR]

Çok teşekkür ederim. Umarım bu video ve bu seri faydalı oluyordur.

[@KiyidakiAsk2024]

.Net 8 için çalıştırmayı başardım :D

[@oguzhankomcu2031]

Hocam merhaba. Hocam bu category tablosunun doğru kullanımını bir türlü anlayamıyorum. E-ticaret sitelerinde kategory altıda kategoeriler var . Bunları MsSql veritabanında nasıl yapıyoruz ?

[@TechBuddyTR]

Aynı tablo içinde ParentId isminde bir alan tutabiliriz. Böylelikle bir kategori başka bir kategorinin üst kategorisi olarak işaretlenebilir.

[@elabore7297]

Merhaba, video için teşekkürler, CatalogItem aslında bizim AggregateRoot umuz diyebilir miyiz ?

[@TechBuddyTR]

Tam olarak bir AggregateRoot diyemeyiz çünkü altında Aggregate ettiğimiz pek bir şey yok gibi :)

[@alitugrul1173]

Merhaba. Öncelikle teşekkürler. Repo yu üyelere özel yaptığınızı söylemiştiniz. Fakat bu video da CatalogContextDesignFactory classı ile ilgili bir bölüm yok maalesef. Repo için ne şartlarda üyelik gerektiğini söyleyebilir misini ? Bunu daha önce de sorup cevap alamamıştım

[@TechBuddyTR]

Merhabalar, öncelikle kusura bakmayın eğer daha önce sormuş ve cevabını alamadıysanız. Sorunuza cevap olarak; Bu projenin kaynak kodları tüm Katıl Üyelikleri için açık durumdadır. Yani kaynak kodlar bazında katıl üyeliği haricinde bir sınırlama yok. Üye olunduktan sonra, email veya Discord üzerinden talepte bulunulduğunda repo için gerekli yetkiyi tanımlıyorum. Onun dışında DesignFactory class'ları proje için olmazsa olmazlardan bir dosya değil sadece EF için Migration yaratabilmek için kullanılıyor. Class'ın içeriği ise şu şekilde; public class CatalogContextDesignFactory : IDesignTimeDbContextFactory { public CatalogContext CreateDbContext(string[] args) { var optionsBuilder = new DbContextOptionsBuilder() .UseSqlServer("Data Source=c_sqlserver;Initial Catalog=catalog;Persist Security Info=True;User ID=sa;Password=Salih123!"); return new CatalogContext(optionsBuilder.Options); } }

[@alitugrul1173]

@@TechBuddyTR çok teşekkür ederim cevabınız için

[@battuhant]

hocam mikroservis reposu için size nasıl ulaşıyoruz

[@dev-tube]

Öncelikle selamlar, emeğinize sağlık. Project Catalog Service'de best practices uygulamayıp aynı API projesi altında layer'ları açtınız. OrderService'de de tamamen onion architect'e uygun şekilde. Gerçek hayatta yeni bir microservice yazarken, davranış şekliniz nasıl? Her microservice'de benzer kodları yazmak ve duplicate etmek kabul edilir bişi mi? Varsa bu pattern'in adını paylaşır mısın.

[@TechBuddyTR]

Selamlar, teşekkür ederim. Projenin RoadMap videosunda bu şekilde devam edeceğimi özellikle belirtmiştim. Yani planlanan buydu aslında çünkü tüm projelerde OnionArchitecture uygulamak videoların uzamasına sebep oluyordu. Günlük hayatımda ise buradakine yakın bir davranış gösteriyorum. Eğer proje küçükse ve ileride büyüme planları yoksa (çok küçük bir mail gönderme uygulaması, bir barkod tarayıcısı gibi) onion architecture, cqrs, mediatr kullanmak yerine tek projede hallediyorum işimi. Hem hızlı, hem anlaşılabilir oluyor. Onun dışında büyüme potansiyeli olan projelerde Onion Architecture kullanmaya çalışıyorum çünkü bu şekilde o projede çalışacak ekipleri de birbirinden ayırabiliyoruz. Hatta eklemiş olduğumuz kütüphaneleri de nuget paketleri halinde getirip öyle kullanıyoruz :-) Ekiplerin birbirinden haberi bile olmadan sadece nuget paketini güncelleyip geliştirmelerini yapmasını sağlamış oluyoruz. Bu pattern'in bir adı olduğunu sanmıyorum ayrıca :-) Her mikroserviste kodları duplike etmek hem iyi hem kötü bir şey. Kötü çünkü sürekli kendimizi tekrarlıyoruz, iyi çünkü adı üstünde micro service. Her bir mikroservisi ayrı birer şirket yazıyor gibi düşünmek lazım. Şöyle bir örnek vereyim, Garanti bankası ile ilgili bir entegrasyon yapacaksınız diyelim. Garanti bankası size bir Api Dokümanı gönderdi. Siz garanti ye dönüp şey diyor musunuz, sizin bu api de kullandığınız class'ları versenize bize projemize ekleyelim ortak olarak kullanalım? Demiyoruz çünkü ayrı ayrı firmalar, ayrı ayrı yaklaşımlar hatta belki ayrı programlama dilleri. Bu sebeple her bir servis ayrı ayrı ele alınmalı devam edilmeli. Ancak bazı Utility class'larını nuget paketi haline getirip projelerimize referans olarak eklemenin de zararı olmaz.

[@feel1989]

Hocam projenin github sayfasini bulamadim.Github linkini atar misiniz lutfen

[@TechBuddyTR]

Merhabalar, bu projenin kaynak kodları kanalın Katıl üyelerine, özel repo erişim yetkisi ile açılıyor. Bilgilerinize

[@naibresidov9662]

Hocam Bu vidodaki zip dosyasina nerden ulsa bilirim

[@TechBuddyTR]

Projenin kaynak kodlarında var, github da

[@mertigdir9130]

Microsoftun sitesinde hepsi anlatılmış link verseydin daha iyiydi

[@turaljavadov4010]

Hocam oncelikle meraba tesekkur ederim videolarin cok faydali benim eger mumkunse bi sorum olacaq ben projeni .NET 6 da aynisini yaziyorum sade bi sorunum var Catalog servicede yazdiginiz Extensions methodlardan hosta yazdiginizi nasil 6 icin uygulaya bilirim o builderin altinda gelen hosta extend olmuyor aradim amma uygulayamadim

[@AlphaTVShorts]

var builder = WebApplication.CreateBuilder(args); yerine var builder = WebApplication.CreateBuilder(new WebApplicationOptions { Args = args, WebRootPath = "Pics", ContentRootPath = Directory.GetCurrentDirectory() }); Extension'daki method'daki IWebHost 'u IHost ile değiştir ve var app = builder.Build(); altında app.MigrateDbContext((context, services) => { var env = services.GetService(); var logger = services.GetService(); new CatalogContextSeed() .SeedAsync(context, env, logger) .Wait(); });

[@emregulten1874]

@@AlphaTVShorts olmadı hocam bende bu dedikleriniz context null geliyor