จะตรวจสอบกฎโมเดลโดเมนที่ขึ้นกับเนื้อหาของฐานข้อมูลได้ที่ไหน

ฉันกำลังทำงานกับระบบที่อนุญาตให้ผู้ดูแลระบบกำหนดฟอร์มที่มีฟิลด์ แบบฟอร์มที่กำหนดจะถูกใช้เพื่อป้อนข้อมูลไปยังระบบ บางครั้งแบบฟอร์มจะถูกกรอกโดยมนุษย์ผ่าน GUI บางครั้งแบบฟอร์มจะถูกกรอกตามค่าที่รายงานโดยระบบอื่น

สำหรับแต่ละฟิลด์ผู้ดูแลระบบสามารถกำหนดกฎการตรวจสอบที่ จำกัด ค่าที่อนุญาตสำหรับฟิลด์ กฎการตรวจสอบสามารถเป็นอะไรก็ได้จาก "ค่าที่ป้อนในฟิลด์ต้องเป็นจริงหรือเท็จ" ถึง "ค่าที่ป้อนในฟิลด์ต้องมีอยู่ในคอลัมน์ A ของตาราง B ในฐานข้อมูล" ผู้ดูแลระบบสามารถเปลี่ยนแปลงกฎการตรวจสอบสำหรับฟิลด์ได้ตลอดเวลา

ในสถานการณ์นี้ความคิดเห็นของคุณเป็นสถานที่ที่เหมาะสมที่สุดสำหรับการตรวจสอบว่าแต่ละเขตข้อมูลถูกกรอกอย่างถูกต้องหรือไม่ ฉันมีสองวิธีหลักในใจ:

ตัวเลือก # 1: ตรวจสอบความถูกต้องในรูปแบบโดเมน

แต่ละวัตถุฟิลด์จะมีกฎการตรวจสอบที่ระบุโดยผู้ดูแลระบบ วัตถุฟิลด์จะมีการอ้างอิงถึง IValidator เมื่อมีความพยายามในการตั้งค่าของฟิลด์ฟิลด์จะผ่านค่าที่กำหนดและกฎการตรวจสอบไปยัง IValidator หากค่าที่ระบุไม่ถูกต้องจะมีการโยน ValidationException และจัดการอย่างเหมาะสมใน GUI / อินเตอร์เฟสไปยังระบบอื่น

ข้อดี:

• การป้องกันที่แข็งแกร่งสำหรับฟิลด์ที่ถูกกำหนดค่าโดยไม่ตั้งใจซึ่งละเมิดกฎการตรวจสอบ

จุดด้อย:

• Data Access Layer ต้องสามารถผ่านการตรวจสอบและสร้างเขตข้อมูลที่ละเมิดกฎการตรวจสอบปัจจุบัน แม้ผู้ดูแลระบบจะเปลี่ยนกฎการตรวจสอบสำหรับเขตข้อมูล แต่เรายังจำเป็นต้องสร้างวัตถุเขตข้อมูลตามข้อมูลเก่าเช่นเมื่อแสดงแบบฟอร์มที่กรอกข้อมูลเมื่อหลายปีก่อน สิ่งนี้อาจแก้ไขได้โดยการเก็บกฎการตรวจสอบปัจจุบันเมื่อใดก็ตามที่เราเก็บฟิลด์

• ในการออกแบบนี้โมเดลฟิลด์มีลิงก์ทางอ้อมไปยัง Data Access Layer / Repository ผ่าน IValidator ฉีด Services / คลังเพื่อรุ่นโดเมนดูเหมือนว่าจะโดยทั่วไปขมวดคิ้ว

ตัวเลือก # 2: ตรวจสอบในบริการ

พยายามให้แน่ใจว่าทุกความพยายามในการตั้งค่าของเขตข้อมูลผ่านการบริการที่มั่นใจว่ากฎการตรวจสอบถือ หากกฎการตรวจสอบถูกละเมิดให้โยน ValidationException

แน่นอน Data Access Layer จะไม่ใช้บริการเมื่อสร้างวัตถุ Field ที่ยังคงอยู่ในฐานข้อมูลก่อนหน้านี้

ข้อดี:

• ไม่ละเมิด "ไม่ต้องฉีดบริการ / ที่เก็บข้อมูลลงในแบบจำลองโดเมนของคุณ" - คิด

• ไม่จำเป็นต้องยืนยันกฎการตรวจสอบในปัจจุบันเมื่อยังคงใช้งานฟิลด์ บริการสามารถค้นหากฎการตรวจสอบปัจจุบันสำหรับฟิลด์ เมื่อดูข้อมูลประวัติค่าของฟิลด์จะไม่เปลี่ยนแปลง

จุดด้อย:

• ไม่รับประกันว่าตรรกะทั้งหมดที่ควรใช้บริการเพื่อตั้งค่าฟิลด์จะทำเช่นนั้น ฉันเห็นสิ่งนี้เป็นข้อเสียเปรียบที่สำคัญ สิ่งที่ดูเหมือนว่าจะมีก็คือใครบางคนที่เขียนว่า "thisField.setValue (thatField.getValue ())" และกฎการตรวจสอบความถูกต้องของสนามนี้อาจถูกละเมิดโดยไม่มีใครฉลาด สิ่งนี้อาจลดลงได้ด้วยการตรวจสอบให้แน่ใจว่าค่าของเขตข้อมูลตรงกับกฎการตรวจสอบเมื่อชั้นการเข้าถึงข้อมูลกำลังจะคงอยู่ในเขตข้อมูล

ปัจจุบันฉันชอบตัวเลือก # 1 มากกว่าตัวเลือก # 2 ส่วนใหญ่เป็นเพราะฉันเห็นว่านี่เป็นตรรกะทางธุรกิจและรู้สึกว่าตัวเลือก # 2 มีความเสี่ยงมากขึ้นในการนำข้อมูลที่ไม่ดีเข้าสู่ระบบ คุณต้องการตัวเลือกใดหรือมีการออกแบบอื่นที่เหมาะกับสถานการณ์นี้ดีกว่าสองตัวเลือกที่อธิบายไว้?

แก้ไข (ความซับซ้อนของการตรวจสอบ)

กรณีการตรวจสอบที่เกิดขึ้นในตอนนี้ค่อนข้างง่าย ค่าฟิลด์จะต้องเป็นตัวเลขวันที่วันที่พร้อมเวลาหรือเป็นค่าที่มีอยู่ในคอลัมน์ฐานข้อมูล อย่างไรก็ตามฉันสงสัยว่าความซับซ้อนจะค่อยๆเพิ่มขึ้นเมื่อเวลาผ่านไป ตัวอย่างเช่นโซลูชันการตรวจสอบความถูกต้องจะต้องสร้างขึ้นโดยคำนึงถึงความเป็นสากล - สิ่งต่าง ๆ เช่นวันที่อาจใส่ในรูปแบบเฉพาะของโลแคล

ฉันตัดสินใจที่จะดำเนินการต่อด้วยตัวเลือก # 1 ในขณะนี้พยายามที่จะไม่ดูแลความรับผิดชอบมากเกินไปให้กับรูปแบบโดเมน ผู้ที่เผชิญกับสถานการณ์ที่คล้ายกันอาจต้องการตรวจสอบคำถามที่เกี่ยวข้องการตรวจสอบและการอนุญาตในสถาปัตยกรรมชั้นและการตรวจสอบการป้อนข้อมูล - ที่ไหน เท่าไหร่ .

การตรวจสอบมีความซับซ้อนเพียงใด บ่อยครั้งการตรวจสอบต้องมีการรวมกันของเขตข้อมูลและหรือกฎเกณฑ์ทางธุรกิจที่ต้องพึ่งพาเขตข้อมูลที่จะได้รับการประเมินอย่างถูกต้อง

การตรวจสอบที่ซับซ้อนยิ่งขึ้นตัวเลือกที่ยากขึ้นและน้อยลงคือ # 2

แน่นอนว่าระดับข้อมูลสามารถเรียกใช้บริการตรวจสอบความถูกต้องได้ในเวลาที่มีอยู่ สิ่งนี้สามารถช่วยสถานการณ์คี่ที่ข้อมูลอยู่ในสถานะไม่ถูกต้องเนื่องจากการเปลี่ยนแปลงกฎ

รายการอื่น ๆ ที่ควรค่าแก่การแสดงความคิดเห็นคือความสามารถในการเปลี่ยนแปลงกฎการตรวจสอบโดยไม่ต้องวงจร qa ของบางประเภท แต่นั่นเป็นหัวข้อสำหรับเธรดอื่น

จากข้อมูลข้างต้นตัวเลือกที่ 1 ดูเหมือนยืดหยุ่นที่สุดสมมติว่าคุณรักษาระเบียบวินัยการแยกการตรวจสอบและการคงอยู่

บางทีคุณอาจจะพลาดเลเยอร์ โดยไม่ทราบรายละเอียดของแอปพลิเคชันของคุณ (สิ่งที่จำเป็นต้องมีสถาปัตยกรรมและอื่น ๆ ) ฉันจะทำอะไรที่เหมือนกับไคลเอนต์ (ใครก็ตามที่เป็น) -> Application Service -> โมเดลของโดเมน

เลเยอร์บริการแอปพลิเคชันได้รับอนุญาตให้โต้ตอบกับที่เก็บและรูปแบบโดเมนที่มีตรรกะทางธุรกิจ ดังนั้นคุณสามารถมีสิ่งที่ชอบ:

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

หากคุณมีความสัมพันธ์วางเดิมพัน Field และ FieldRules ของเขาและใช้ ORM เช่น Hibernate ใน Java คุณจะทำ:

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

เพราะแบบสอบถาม ORM และยกตัวอย่างกราฟของวัตถุที่คุณขอ

เกี่ยวกับข้อสงสัยของคุณเกี่ยวกับความจริงที่ว่าใครบางคนสามารถทำได้

thisField.setValue (thatField.getValue ()) "และกฎการตรวจสอบของ ThisField อาจถูกละเมิดโดยไม่มีใครฉลาด

บางคนสามารถเขียนได้: FieldRule alwaysReturnTrueRule = new FieldRule {isValid (newValue) {return true; }} field.updateValue ("uncheckedValue", alwaysReturnTrueRule) มันเป็นตัวอย่างที่คลุมเครือ แต่สิ่งที่ฉันต้องการจะพูดคือไม่มีสิ่งใดที่ปกป้องคุณจากการใช้รหัสที่ไม่ดี อาจเป็นเอกสารที่ดีและสื่อสารกันแบบเห็นหน้า ฉันคิดว่าไม่มีสิ่งใดปกป้องคุณจากการใช้รหัสที่ไม่ดี