ฉันควรใช้ไฟล์กำหนดค่าหรือฐานข้อมูลสำหรับจัดเก็บกฎทางธุรกิจหรือไม่


41

ฉันเพิ่งได้อ่านThe Pragmatic Programmerซึ่งระบุว่า:

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

ล่าแอนดรู; โทมัสเดวิด (1999-10-20) โปรแกรมเมอร์ในทางปฏิบัติ: จาก Journeyman ถึง Master (จุดติดตั้ง 2651-2653) การศึกษาของเพียร์สัน (สหรัฐอเมริกา) จุด Edition.

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

light-> type = sphere / cube / cylinder

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

ฉันควรเก็บค่าเหล่านี้ไว้ใน:

  • ไฟล์ปรับแต่ง:
    'light-types' => array(sphere, cube, cylinder),
    'other-type' => value,
    'etc' => etc-value

  • ตารางเดียวในฐานข้อมูลที่มีหนึ่งบรรทัดสำหรับแต่ละรายการกำหนดค่า

  • ฐานข้อมูลพร้อมตารางสำหรับแต่ละรายการกำหนดค่า (เช่นตาราง: light_types; คอลัมน์: id, name)

  • วิธีอื่นไหม

ขอบคุณมากสำหรับความช่วยเหลือ / ความเชี่ยวชาญที่มีให้

คำตอบ:


45

คำถามเดียวกันเกิดขึ้นในโครงการส่วนใหญ่ที่ฉันทำงาน โดยปกติฉันทำสิ่งนี้:

  1. หากชุดของค่าที่เป็นไปได้ไม่น่าจะเปลี่ยนแปลงได้ตลอดเวลาเร็ว ๆ นี้ฉันใช้ค่าคงที่คลาส / อินเทอร์เฟซหรือ enums ในรหัสและเขตข้อมูลนับจำนวนในฐานข้อมูล ตัวอย่าง: สถานะของการเผยแพร่รายการบล็อก: 'ไม่เผยแพร่', 'อยู่ภายใต้การดูแล', 'เผยแพร่แล้ว' ฯลฯ
  2. ค่าอาจจะเปลี่ยน แต่การเปลี่ยนแปลงจะไม่ส่งผลกระทบต่อตรรกะของโปรแกรม - ไฟล์กำหนดค่า ตัวอย่าง: รายการ "คุณพบเว็บไซต์ของเราได้อย่างไร" ตัวเลือกสำหรับรายการแบบเลื่อนลงในแบบฟอร์มการซื้อออนไลน์
  3. ค่านิยมมีแนวโน้มที่จะเปลี่ยนแปลงบ่อยครั้งและ / หรือมีการแก้ไขโดยผู้ที่ไม่ใช่นักพัฒนา แต่การเปลี่ยนแปลงเหล่านี้จะไม่ส่งผลกระทบต่อลอจิก - ฐานข้อมูลหรือที่เก็บคีย์ - ค่าอย่างน้อยกับส่วนติดต่อผู้ใช้ที่เป็นมิตร
  4. การเปลี่ยนค่าจะส่งผลต่อลอจิก - ระบบอาจต้องการการออกแบบใหม่ (มักเป็นจริง) หรือจำเป็นต้องมีเอ็นจินกฎธุรกิจ กรณีที่ยากที่สุดที่ฉันเคยเห็นคือตัวสร้างการทดสอบทางจิตวิทยาเพื่อนร่วมงานของฉันทำงาน การทดสอบแต่ละประเภทอาจมีระบบการให้คะแนนของตัวเองซึ่งอาจแตกต่างจากการเพิ่มอย่างง่ายไปจนถึงหลายคุณลักษณะที่มีค่าบวกและลบหรือแม้แต่การประเมินคำตอบของมนุษย์ หลังจากการพูดคุยเกี่ยวกับโครงการนี้เราได้ใช้Luaเป็นเครื่องมือสร้างสคริปต์ซึ่งขัดแย้งกับความสามารถของผู้ที่ไม่ใช่นักพัฒนาในการสร้างแบบทดสอบใหม่ (แม้ว่า Lua เป็นภาษาที่ค่อนข้างง่ายคุณไม่ควรคาดหวังว่าจะเป็นโปรแกรมเมอร์ จะได้เรียนรู้มัน)

เกี่ยวกับใบเสนอราคาจาก TPP ฉันคิดว่ามันเป็นความจริงสำหรับรหัสที่เก่าแก่แต่ในชีวิตจริงคุณควรเริ่มต้นง่าย ๆ ( หลักการ KISS ) และเพิ่มคุณสมบัติในภายหลังหากพวกเขาต้องการจริงๆ ( YAGNI )


7

หากข้อมูลของคุณจะอยู่ในฐานข้อมูลฉันขอแนะนำให้มีตาราง 'light_types' ในฐานข้อมูลเดียวกัน สิ่งนี้ทำให้คุณมีความสามารถในการใช้ foreign key เพื่อบังคับใช้ข้อ จำกัด ที่ light-> type สามารถเป็นหนึ่งในค่าเหล่านั้นได้ดังนั้นแม้ว่ารหัสจะยุ่งเหยิงข้อมูลใน DB จะถูกต้องเสมอ

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

(ฉันเตือนว่าอย่าไปไกลเกินไปในการหลีกเลี่ยงการเขียนโค้ดแบบยาก ๆ ในระบบที่ไม่สำคัญจะมีข้อสันนิษฐานเกี่ยวกับกฎเกณฑ์และข้อกำหนดทางธุรกิจไม่ว่าผู้เขียนจะรู้หรือไม่ก็ตามแม้ว่าคุณจะพยายามหลีกเลี่ยงก็ตาม สมมติฐานและรหัสอ่อน ๆ ทุกอย่างโดยทั่วไปคุณเพิ่งจบด้วย "กฎของเครื่องมือ" ประเภทของระบบภายในระบบและ / หรือเมตาดาต้าและคุณมีสิ่งต่าง ๆ ในภาษาเมตา ใช้กฎนี้คุณไม่ได้บันทึกงานหรือเพิ่มความยืดหยุ่นใด ๆ คุณเพียงแค่ต้องสร้างและ / หรือเรียนรู้ภาษาอื่น

ตอนนี้ถ้าคุณต้องการค้นหาและใช้เอ็นจินกฎที่มีอยู่นั่นอาจช่วยให้คุณประหยัดเวลาในการทำงาน (พร้อมตอบคำถามว่าจะเก็บ enums ไว้ที่ไหน) แต่การสร้างภาระงานของคุณเองเพิ่มขึ้นเป็นสองเท่าของภาระงานและทำให้คุณได้รับระบบครึ่งทางที่สร้างขึ้นโดยคนที่ไม่รู้วิธีสร้างเครื่องมือกฎที่เหมาะสม)


0

โดยทั่วไปแล้วฐานข้อมูลควรใช้สำหรับข้อมูลและควรใช้ไฟล์กำหนดค่าสำหรับการกำหนดค่า (ตามชื่อแนะนำ :)) การเก็บการกำหนดค่าในฐานข้อมูลเป็นการแยกข้อกังวลที่ไม่ดีและควรจะทำก็ต่อเมื่อคุณมีกรณีการใช้งานที่ดีเพื่อให้เหตุผล

มีความสมดุลที่จะเกิดขึ้นเมื่อตัดสินใจว่าจะใช้การกำหนดค่าเท่าใด คุณควรปฏิบัติต่อไฟล์กำหนดค่าของคุณมากที่สุดเท่าที่เป็นส่วนหนึ่งของแอปพลิเคชันเท่ากับรหัส ทำให้สั้นที่สุด มันง่ายมากสำหรับแอปพลิเคชันที่ต้องทนทุกข์ทรมานจากการขยายตัวของการกำหนดค่าที่คุณท้ายด้วยไฟล์ xml ขนาดใหญ่ที่เต็มไปด้วยเวทมนตร์

ในกรณีที่คุณอธิบายมันจะสมเหตุสมผลที่จะมีองค์ประกอบการกำหนดค่าเพื่อกำหนดไฟล์ css ที่จะใช้ (คุณสามารถเปลี่ยนได้ถ้าความต้องการเปลี่ยนแปลง) มันจะ overkill ในการกำหนดค่าสไตล์ของแต่ละองค์ประกอบในไฟล์กำหนดค่า


1
คุณจะกำหนดว่าการกำหนดค่าคืออะไรและข้อมูลคืออะไร?
nafg

3
คำตอบของคุณไม่ได้อธิบายว่าทำไมการจัดเก็บการกำหนดค่าในฐานข้อมูลละเมิดการแยกข้อกังวล (ข้อกังวลของฐานข้อมูลคือการเก็บข้อมูล แต่ไม่สนใจว่าคุณเก็บข้อมูลไว้ที่ใด) หรือทำไมสิ่งนี้ถึงเป็นเรื่องเลวร้าย คำตอบคือตอนนี้ถูกอ้างถึงที่อื่นเป็นหลักฐานว่ามันเป็นสิ่งที่ไม่ดี
Robert Harvey

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

@AmirHossein ไฟล์สแตติกสนับสนุนการเปลี่ยนแปลงตามความต้องการตราบใดที่พวกเขาไม่ได้ล็อค นั่นไม่ใช่เหตุผล
Zimano
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.