ServiceComposer: güçlü tipli view model'ler coupling'i geri getirir mi?
Mauro Servienti, ServiceComposer'da güçlü tipli view model'lerin ViewModel Composition ile kaldırılmak istenen bağımlılığı nasıl geri getirebileceğini inceliyor. Yanıt modelleri için servis başına arayüz, istek modelleri için ise servis başına ayrı model önerisini ve somut sınıfı kaldırabilecek DispatchProxy fikrini ele alıyor. Dağıtım riskleri ve özellik adı çakışmaları gibi ödünleşimler için makaleye bakmaya değer.
Kilit noktalar
- Güçlü tipli view model'ler hataları derleme zamanında yakalar, ama ortak bir model her servisi aynı assembly'ye bağlar.
- Handler'lar GetComposedResponseModel<TArayüz>() ile yalnızca kendi servislerine ait özellikleri görebilir.
- Somut view model tüm servis arayüzlerini uygular ve genellikle composition host içinde internal tutulur.
- Yeni servis arayüzü eski composition host ile dağıtılırsa çalışma zamanında tip yükleme hatası oluşabilir.
- Arayüzlerde aynı ada ve aynı tipe sahip özellikler sessizce aynı değeri paylaşır; isimlendirme kuralı kullanın.
- ASP.NET model binding bilinmeyen özellikleri yok saydığı için istek modelleri servis başına ayrılabilir.
ServiceComposer, tek bir HTTP yanıtına birden fazla handler'ın veri eklemesine izin verir ve güçlü tipli view model'ler derleme zamanında ek güvenlik sağlar. Ancak tek bir ortak model, her servisin aynı assembly'ye bağlanmasına yol açar; Marketing handler'ı Sales'in fiyat verisini değiştirebilir ve şema değişiklikleri ekipler arasında yayılır. Yazarın önerdiği çözüm, her handler'ın yalnızca kendi özelliklerini içeren bir arayüz istemesi, composition host'un ise hepsini uygulayan tek bir somut sınıf sağlamasıdır.
Bağımlılık bu kez composition host'a taşınır; bir servis arayüzünü değiştirdiğinde somut model de güncellenmelidir ve iki değişiklik birlikte yayınlanmazsa çalışma zamanında tip yükleme hatası oluşabilir. İki arayüz aynı ada ve tipe sahip bir özellik tanımlarsa isim çakışması yine olabilir, bu yüzden isimlendirme kuralı gerekir. DispatchProxy ile somut sınıf tamamen kaldırılabilir, fakat bu yaklaşım OpenAPI araçları için tüm yanıtı temsil eden bir tip sunmaz ve Native AOT uygulamalarında çalışmaz.
Gerçek dünyada kullanımı
- Sales'in fiyat, Marketing'in ürün adı ve açıklama alanlarını yönettiği, tek bir ürün sayfasını birden fazla servisten birleştiren bir gateway.
- Bir POST isteğini birden fazla servise dağıtan BFF katmanı; her servis yalnızca kendi alanlarını bağlar.
- Paylaşılan ViewModel assembly'si olan bir monolitin mikroservislere ayrıldığı geçiş projesi.
Neden önemli
ServiceComposer ile birden fazla servisten yanıt birleştiriyorsanız, ortak bir view model sessizce ayrılmak istenen sürüm bağımlılığını geri getirir. Servis başına arayüzler derleyicinin sağladığı kontrolü korurken bu bağımlılığı ortadan kaldırır.
Benzer haberler
- C# 14 extension member'ları: derleyicinin uyarmadığı gölgeleme hatasıDEV Community: #csharp1 gün önce
- .NET 10 + Pinecone: vektör veritabanı entegrasyonuDEV Community: #dotnet1 gün önce
- C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıNick Cosentino (Dev Leader)2 gün önce