แสดงถึงกฎธุรกิจที่มีข้อยกเว้น

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

อีกวิธีหนึ่งที่จะมีวัตถุที่มีสถานะหรืออะไรทำนองนั้น

มีวิธีอื่นอีกไหม? คุณรู้สึกอย่างไรเกี่ยวกับเรื่องนี้?

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

ในทางกลับกันฉันเชื่อว่าการตรวจสอบกฎทั้งหมดแล้วโยนข้อยกเว้นพร้อมข้อสรุปเป็นแนวทางปฏิบัติที่ดี

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

การใช้ข้อยกเว้นเพื่อบังคับใช้กฎเกณฑ์ทางธุรกิจนั้นไม่ใช่การออกแบบที่ดี

ฉันไม่เห็นว่าการยกเว้นมีค่าใดในการสร้างตรรกะทางธุรกิจที่ดี มีวิธีการมากมายในการจัดการตรรกะทางธุรกิจที่ไม่เกี่ยวข้องกับการใช้ระบบที่มีไว้สำหรับจัดการปัญหาที่ไม่คาดคิดในการทำงานของระบบ

มันเป็นที่คาดว่าในตรรกะทางธุรกิจเงื่อนไขจะไม่ได้พบกัน; นั่นเป็นสาเหตุของการมีอยู่ในสถานที่แรกและคุณไม่ต้องการ piggyback ในกลไกเดียวกันที่จัดการความล้มเหลว I / O ที่ไม่คาดคิดออกจากข้อผิดพลาดของหน่วยความจำและการอ้างอิงที่เป็นโมฆะ สิ่งเหล่านี้คือความล้มเหลวของระบบ แต่การตรวจสอบสภาพธุรกิจที่ไม่ได้ดำเนินการนั้นเป็นการดำเนินการที่ประสบความสำเร็จของระบบ

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

การแสดงกฎเกณฑ์ทางธุรกิจเป็นสิ่งหนึ่งการใช้กฎนั้นเป็นอีกสิ่งหนึ่ง

คิดเกี่ยวกับประสบการณ์การใช้งาน; หากผู้ใช้ไม่ได้เป็นพนักงานขายทำไมให้พวกเขามีปุ่มที่ระบุว่า 'สร้างใบแจ้งหนี้' a ที่ทุกคน ?

ขึ้นอยู่กับสิ่งที่ทำ

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

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

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

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

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

ประโยชน์อย่างหนึ่งที่เกิดขึ้นจากการโยนข้อยกเว้นประเภทนี้คือช่วยให้คุณสามารถแยกออกและนำข้อยกเว้นสารตั้งต้นมาใช้ซ้ำในหลายพื้นที่ของโครงการของคุณ (นี่คือสาระสำคัญของการเขียนโปรแกรม Aspect Oriented) โดยการทำเช่นนี้คุณกำลังห่อหุ้มแง่มุมหนึ่งของกฎเกณฑ์ทางธุรกิจทั่วไปของคุณในองค์ประกอบที่มีอยู่และบำรุงรักษาได้ โดยทั่วไปส่วนประกอบเหล่านี้จะสอดคล้อง 1-1 กับข้อความแสดงข้อผิดพลาดที่ส่งออกไป (แม้ว่าบางครั้งคุณจะมีองค์ประกอบเดียวที่ส่งข้อยกเว้นต่างกันหลายข้อคุณไม่ควรยกเว้นข้อยกเว้นที่เหมือนกันจากหลายองค์ประกอบ)

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