Aracılığıyla paylaş

Etki alanı modeli katmanında tasarım doğrulamaları

  • Makale

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

PDF'i indirin

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

DDD'de doğrulama kuralları sabit olarak düşünülebilir. Bir toplamanın temel sorumluluğu, bu toplama içindeki tüm varlıklar için durum değişikliklerinde sabitleri zorunlu kılmaktır.

Etki alanı varlıkları her zaman geçerli varlıklar olmalıdır. Bir nesne için her zaman doğru olması gereken belirli sayıda sabit değer vardır. Örneğin, bir sipariş öğesi nesnesinin her zaman pozitif tamsayı olması gereken bir miktara, artı bir makale adına ve fiyatına sahip olması gerekir. Bu nedenle, sabit zorlama, etki alanı varlıklarının (özellikle toplama kökünün) sorumluluğundadır ve bir varlık nesnesinin geçerli olmadan var olmaması gerekir. Sabit kurallar yalnızca sözleşme olarak ifade edilir ve ihlal edildiğinde özel durumlar veya bildirimler oluşturulur.

Bunun ardındaki neden, nesnelerin hiçbir zaman içinde olmamaları gereken bir durumda olması nedeniyle birçok hatanın oluşmasıdır.

Şimdi UserProfile alan bir SendUserCreationEmailService'e sahip olduğumuzu önerelim... Bu hizmette Name değerinin null olmadığını nasıl rasyonalize edebiliriz? Tekrar kontrol eder miyiz? Veya daha olası ... yalnızca kontrol etmek ve "en iyisini umut etmek" için zahmet etmezsiniz; birinin size göndermeden önce doğrulamaya zahmet ettiğini umarsınız. Tabii ki, yazmamız gereken ilk testlerden biri TDD'yi kullanmak, null ada sahip bir müşteri gönderirsem hata vermesi gerektiğidir. Ancak bu tür testleri tekrar tekrar yazmaya başladığımızda... "Ya adın null olmasına izin vermezsek? bu testlerin tümüne sahip olmazdık!".

Etki alanı modeli katmanında doğrulamaları uygulama

Doğrulamalar genellikle etki alanı varlık oluşturucularında veya varlığı güncelleştirebilen yöntemlerde uygulanır. Doğrulamaları uygulamanın, verileri doğrulama ve doğrulama başarısız olursa özel durumlar oluşturma gibi birden çok yolu vardır. Ayrıca doğrulamalar için Belirtim desenini kullanma ve her doğrulama sırasında bir özel durum döndürmek yerine bir hata koleksiyonu döndürmek için Bildirim deseni gibi daha gelişmiş desenler vardır.

Koşulları doğrulama ve özel durumlar oluşturma

Aşağıdaki kod örneği, özel durum oluşturarak bir etki alanı varlığında doğrulamaya yönelik en basit yaklaşımı gösterir. Bu bölümün sonundaki başvurular tablosunda, daha önce ele aldığımız desenlere göre daha gelişmiş uygulamaların bağlantılarını görebilirsiniz.

public void SetAddress(Address address)
{
    _shippingAddress = address?? throw new ArgumentNullException(nameof(address));
}

Daha iyi bir örnek, iç durumun değişmediğinden veya bir yöntemin tüm mutasyonlarının oluştuğundan emin olmak gerektiğini gösterir. Örneğin, aşağıdaki uygulama nesneyi geçersiz durumda bırakır:

public void SetAddress(string line1, string line2,
    string city, string state, int zip)
{
    _shippingAddress.line1 = line1 ?? throw new ...
    _shippingAddress.line2 = line2;
    _shippingAddress.city = city ?? throw new ...
    _shippingAddress.state = (IsValid(state) ? state : throw new …);
}

Eyaletin değeri geçersizse, ilk adres satırı ve şehir zaten değiştirilmiş olur. Bu, adresi geçersiz yapabilir.

Varlığın oluşturucusunda benzer bir yaklaşım kullanılabilir ve varlığın oluşturulduktan sonra geçerli olduğundan emin olmak için bir özel durum oluşturulur.

Veri ek açıklamalarını temel alarak modelde doğrulama özniteliklerini kullanma

Gerekli veya MaxLength öznitelikleri gibi veri ek açıklamaları, Tablo eşleme bölümünde ayrıntılı olarak açıklandığı gibi EF Core veritabanı alanı özelliklerini yapılandırmak için kullanılabilir, ancak artık .NET Framework'te EF 4.x'ten bu yana yaptıkları gibi EF Core'da varlık doğrulaması için çalışmaz (yöntemi de çalışmazIValidatableObject.Validate).

Veri ek açıklamaları ve IValidatableObject arabirim, denetleyicinin her zamanki gibi eylemleri çağrılmadan önce model bağlama sırasında model doğrulaması için kullanılabilir, ancak bu modelin bir ViewModel veya DTO olması amaçlanır ve bu bir MVC veya API ile ilgili bir etki alanı modeli sorunu değildir.

Kavramsal farkı açıkça belirttikten sonra, eylemleriniz bir varlık sınıfı nesne parametresi alırsa doğrulama için veri ek açıklamalarını ve IValidatableObject varlık sınıfında yine de kullanabilirsiniz. Bu önerilmez. Bu durumda doğrulama, eylemi çağırmadan hemen önce model bağlamasında gerçekleşir ve sonucu denetlemek için denetleyicinin ModelState.IsValid özelliğini de de kontrol edebilirsiniz, ancak daha sonra, EF 4.x'ten bu yana olduğu gibi DbContext'te varlık nesnesini kalıcı hale getirmeden önce değil denetleyicide gerçekleşir.

DbContext'in SaveChanges yöntemini geçersiz kılarak veri ek açıklamalarını ve IValidatableObject.Validate yöntemini kullanarak varlık sınıfında özel doğrulama gerçekleştirmeye devam edebilirsiniz.

GitHub'da bu açıklamadaki varlıkları doğrulamak IValidatableObject için örnek bir uygulama görebilirsiniz. Bu örnek öznitelik tabanlı doğrulamalar yapmaz, ancak aynı geçersiz kılmada yansıma kullanarak kolayca uygulanabilir.

Ancak, DDD açısından bakıldığında, etki alanı modeli en iyi şekilde varlığınızın davranış yöntemlerinde özel durumların kullanımıyla veya doğrulama kurallarını zorunlu tutmak için Belirtim ve Bildirim desenleri uygulanarak yalın tutulur.

Kullanıcı arabirimi katmanında model doğrulamasına izin vermek için girişi kabul edecek ViewModel sınıflarındaki (etki alanı varlıkları yerine) uygulama katmanında veri ek açıklamalarının kullanılması mantıklı olabilir. Ancak, bu işlem etki alanı modeli içinde doğrulamanın dışlanması sırasında yapılmamalıdır.

Belirtim desenini ve Bildirim desenini uygulayarak varlıkları doğrulama

Son olarak, etki alanı modelinde doğrulamaları uygulamak için daha ayrıntılı bir yaklaşım, Daha sonra listelenen ek kaynakların bazılarında açıklandığı gibi Belirtim desenini Bildirim düzeniyle birlikte uygulamaktır.

Bu desenlerden yalnızca birini de kullanabileceğinizi belirtmek gerekir; örneğin, denetim deyimleriyle el ile doğrulama, ancak doğrulama hatalarının listesini yığınlayıp döndürmek için Bildirim desenini kullanma.

Etki alanında ertelenen doğrulamayı kullanma

Etki alanında ertelenen doğrulamalarla ilgilenmek için çeşitli yaklaşımlar vardır. Vaughn Vernon, Etki Alanı Odaklı Tasarım Uygulama kitabında bunları doğrulama bölümünde ele almaktadır.

İki aşamalı doğrulama

Ayrıca iki aşamalı doğrulamayı da göz önünde bulundurun. Veri Aktarım Nesneleri (DTO' lar) komutunuzda alan düzeyi doğrulamayı ve varlıklarınızdaki etki alanı düzeyinde doğrulamayı kullanın. Doğrulama hatalarıyla başa çıkmanızı kolaylaştırmak için özel durumlar yerine bir sonuç nesnesi döndürerek bunu yapabilirsiniz.

Örneğin, veri ek açıklamalarıyla alan doğrulamayı kullanarak doğrulama tanımını yinelemezsiniz. Ancak yürütme, DTO'lar (örneğin komutlar ve ViewModel'ler) söz konusu olduğunda hem sunucu tarafı hem de istemci tarafı olabilir.

Ek kaynaklar

Geriİleri