รูปแบบการออกแบบสำหรับการตรวจสอบข้อมูล


23

รูปแบบการออกแบบที่ดีที่สุดสำหรับปัญหานี้คืออะไร:

ฉันมีวัตถุ A. วัตถุ A สามารถลงทะเบียนหรือลบออกจากฐานข้อมูลขึ้นอยู่กับคำขอของผู้ใช้

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

จนถึงตอนนี้ฉันคิดว่ารูปแบบการออกแบบห่วงโซ่ความรับผิดชอบเหมาะสมที่สุด แต่ฉันมีปัญหาในการใช้งาน


6
ทำไมคุณถึงคิดว่ารูปแบบการออกแบบห่วงโซ่ความรับผิดชอบเหมาะสมที่สุด
Adam Zuckerman

คำตอบ:


17

โดยปกติฉันจะใช้คลาส validator แยกเพื่อตรวจสอบแต่ละกรณีการใช้งาน เช่นก่อนที่จะเพิ่มผลิตภัณฑ์ลงในฐานข้อมูลฉันจะใช้ AddProductValidator เพื่อตรวจสอบกฎธุรกิจก่อนที่จะลบผลิตภัณฑ์ฉันจะใช้ DeleteProductValidator เพื่อตรวจสอบความถูกต้อง ฯลฯ กฎธุรกิจทั่วไปสามารถแยกไปยังคลาสข้อมูลจำเพาะ (รูปแบบข้อมูลจำเพาะ) และใช้ร่วมกัน

ในการจัดโครงสร้างคลาสตัวตรวจสอบความถูกต้องฉันทำตามวิธีการที่นี่: http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/

หากคุณใช้. NET ฉันคิดว่าคุณอาจต้องการพิจารณาการตรวจสอบ Fluent Validation ( https://github.com/JeremySkinner/FluentValidation ) ฉันคิดว่ามันค่อนข้างเจ๋งและค่อนข้างใกล้เคียงกับบทความที่ฉันพูดถึงข้างต้น


1
URL ใหม่ของการตรวจสอบ Fluent: github.com/JeremySkinner/FluentValidation
Brij

4

ตามที่อธิบายไว้ผมก็อาจจะดำเนินการประเภทตัวเลือก วิธีการที่ฉันจะกลับมา "ไม่มี" หรือค่าการตรวจสอบ (อาจจะขี้เกียจ) แต่ที่เป็นรายละเอียดการดำเนินงานและนำไปสู่การเป็นอย่างดีกับความคิดของการใช้เป็นมัณฑนากร

รูปแบบมัณฑนากร

แน่นอนถ้าอินเตอร์เฟซจะกลายเป็นน่าเกลียดฉันจะใช้อาคาร


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