Veritabanı içeriğine bağlı olan etki alanı modeli kurallarını nerede doğrularım?

Alanlar içeren Formlar tanımlamak için Yöneticiler sağlayan bir sistem üzerinde çalışıyorum. Tanımlanan Formlar daha sonra sisteme veri girmek için kullanılır. Bazen Formlar bir kullanıcı tarafından GUI aracılığıyla doldurulur, bazen Form başka bir sistem tarafından bildirilen değerlere göre doldurulur.

Her Alan için Yönetici, Alan için izin verilen değerleri sınırlayan bir Doğrulama Kuralı tanımlayabilir. Doğrulama Kuralları, "Alana girilen değer Doğru veya Yanlış olmalıdır" ile "Alanda girilen değer veritabanındaki tablo B'nin A sütununda bulunmalıdır" dan herhangi bir şey olabilir. Yönetici istediği zaman Alanın Doğrulama Kuralını değiştirebilir.

Bu senaryoda, her bir Alanın doğru bir şekilde doldurulduğunu doğrulamak için size göre en uygun yer hangisidir? Şu anda iki ana yaklaşımım var:

Seçenek # 1: Etki Alanı Modelinde Doğrulama

Her Field nesnesi, Yönetici tarafından belirtilen Doğrulama Kuralını içerir. Field nesnelerinin ayrıca bir IValidator'a referansı olacaktır. Alanın değeri ayarlanmaya çalışıldığında Alan, verilen değeri ve Doğrulama Kuralını IValidator'a iletir. Verilen değer geçerli değilse, bir ValidationException oluşturulur ve GUI / arabiriminde diğer sisteme uygun şekilde işlenir.

Artıları:

• Doğrulama Kuralını ihlal eden alanlara yanlışlıkla atanan değerlere karşı güçlü koruma

Eksileri:

• Veri Erişim Katmanı'nın doğrulama işlemini atlayabilmesi ve geçerli Doğrulama Kuralını ihlal eden Alanlar oluşturabilmesi gerekir. Yönetici bir Alan için Doğrulama Kuralını değiştirmesine rağmen, Alan nesnelerini eski verilere dayanarak, örneğin yıllar önce doldurulmuş bir Form oluştururken oluşturmamız gerekir. Bu, Alanı her depoladığımızda geçerli Doğrulama Kuralını depolayarak çözülebilir.

• Bu tasarımda Alan modeli, IValidator aracılığıyla Veri Erişim Katmanı / Deposu'na dolaylı bir bağlantıya sahiptir. Hizmetlerin / Depoların Etki Alanı Modellerine enjeksiyonu genellikle kaşlarını çatmış gibi görünüyor .

Seçenek # 2: Bir Hizmette Doğrulama

Bir Alanın değerini ayarlamaya yönelik tüm girişimlerin, Doğrulama Kuralının tutulmasını sağlayan bir Hizmetten geçmesini sağlamaya çalışın. Doğrulama Kuralı ihlal edilirse, bir ValidationException özel durumu belirtin.

Tabii ki, Veri Erişim Katmanı olur değil daha önce DB kalıcı olan alan nesneleri oluştururken Hizmeti kullanmak.

Artıları:

• "Etki Alanı Modellerinize Hizmet / Depo enjekte etme" düşüncesini ihlal etmez.

• Alana devam ederken geçerli Doğrulama Kuralını sürdürmeye gerek yoktur. Hizmet yalnızca Alan için geçerli Doğrulama Kuralını arayabilir; geçmiş verilerine bakıldığında Alanın değeri değişmez.

Eksileri:

• Alan değerini ayarlamak için Hizmeti kullanması gereken tüm mantığın gerçekte böyle olduğunu garanti etmez. Bunu büyük bir dezavantaj olarak görüyorum; alması gereken tek şey "thisField.setValue (thatField.getValue ())" yazan birisidir ve thisField'ın Doğrulama Kuralı, kimse daha akıllıca olmadan ihlal edilebilir. Bu, Veri Erişim Katmanı Alanı devam ettirmek üzereyken Alan değerinin Doğrulama Kuralıyla eşleşmesini sağlayarak potansiyel olarak azaltılabilir.

Şu anda Seçenek # 2 yerine Seçenek # 1'i tercih ediyorum, çünkü bunu iş mantığı olarak görüyorum ve Seçenek # 2'nin sisteme kötü veri getirme riski daha yüksek olduğunu düşünüyorum. Hangi seçeneği tercih edersiniz veya bu senaryoya açıklanan iki seçenekten daha iyi uyan başka bir tasarım var mı?

Düzenle (Doğrulamaların karmaşıklığı)

Şimdilik ortaya çıkan doğrulama davaları nispeten basittir; Alan değeri örneğin sayısal, bir tarih, zaman içeren bir tarih veya bir veritabanı sütununda varolan bir değer olmalıdır. Ancak, karmaşıklığın zaman içinde giderek arttığından şüpheleniyorum. Örneğin, doğrulama çözümünün uluslararasılaşma göz önünde bulundurularak oluşturulması gerekir - Tarihler gibi şeyler yerel ayara özgü bir sözdiziminde girilebilir.

Alan Adı Modeline çok fazla sorumluluk vermemeye özen göstererek Şimdilik Seçenek # ile devam etmeye karar verdim. Benzer bir durumla karşı karşıya olanlar da ilgili soruları kontrol etmek isteyebilir Katmanlı mimaride doğrulama ve yetkilendirme ve Veri girişi doğrulama - Nerede? Ne kadar? .

Doğrulamalar ne kadar karmaşık? Doğrulamaların çoğu zaman, doğru bir şekilde değerlendirilmesi için alanlara dayanan alanların veya iş kurallarının bir kombinasyonunu gerektirir.

Doğrulamalar ne kadar karmaşıksa, # 2 o kadar zor ve daha az performanslı bir seçenektir.

Tabii ki veri katmanı kalıcılık zamanında doğrulama hizmetini çağırabilir. Bu, kurallardaki bir değişiklik nedeniyle verinin geçersiz durumda olduğu garip duruma yardımcı olabilir.

Yorum yapmaya değer diğer bir öğe, bir tür qa döngüsü olmadan doğrulama kurallarında bir değişiklik yapma yeteneğidir. Ama bu farklı bir konu için bir konu.

Yukarıdaki bilgiler göz önüne alındığında, seçenek 1, disiplini koruduğunuzu varsayarak, geçerliliği ve kalıcılığı ayırarak en esnek görünmektedir.

Belki bir katmanı kaçırıyorsunuzdur. Uygulamanızın ayrıntılarını bilmeden (gereksinimler, mimari, vb.) İstemci (kim olursa olsun) -> Uygulama Hizmeti -> Etki Alanı Modeli gibi bir şey yaparım

Uygulama hizmeti katmanının, depo ve iş mantığını içeren etki alanı modeli ile etkileşime girmesine izin verilir. Yani şöyle bir şey olabilir:

FieldUpdateService >> updateField(fieldId, newValue)
  List<FieldRule> rules = this.rulesRepository.findRulesFor(fieldId)
  Field field = this.fieldRepository.find(fieldId)
  try 
    field.updateValue(rules,newValue)
    fieldRepository.save(field)
  catch 
    // manage error

Bir Alan ve onun FieldRule'leri arasında bir ilişkiniz varsa ve Java'da Hazırda Bekleme gibi bir ORM kullanıyorsanız yalnızca şunları yapabilirsiniz:

FieldUpdateService >> updateField(fieldId, newValue)
  Field field = this.fieldRepository.find(fieldId)
  try 
    field.updateValue(newValue)
    fieldRepository.save(field)
  catch 
    // manage error

Field >> updateValue(newValue)
  for rule in rules
     if !rule.isValid(newValue)
        throw ValueNotAllowedException
  this.value = newvalue

Çünkü ORM sorgusu ve istediğiniz nesnelerin grafiğini başlatır.

Birisinin yapabileceği konusunda şüphenizle ilgili

thisField.setValue (thatField.getValue ()) "ve thisField öğesinin Doğrulama Kuralı, kimse daha akıllıca olmadan ihlal edilebilir

Birisi de yazabilir: FieldRule alwaysReturnTrueRule = new FieldRule {isValid (newValue) {return true; }} field.updateValue ("uncheckedValue", alwaysReturnTrueRule) Bu belirsiz bir örnektir, ancak söyleyebileceğim hiçbir şey sizi kodun kötü kullanımından koruyamaz. Belki de yüz yüze iyi dokümantasyon ve iletişim. Sanırım hiçbir şey sizi kodun kötü kullanımından koruyamaz.