คำถามติดแท็ก validation

สถานที่ที่ดีที่สุดในการตรวจสอบความถูกต้องของพารามิเตอร์อินพุตของฟังก์ชัน: ในผู้โทรเข้าหรือในฟังก์ชั่นของตัวเอง? เนื่องจากฉันต้องการปรับปรุงรูปแบบการเข้ารหัสของฉันฉันพยายามค้นหาแนวทางปฏิบัติที่ดีที่สุดหรือกฎบางอย่างสำหรับปัญหานี้ เมื่อไรและอย่างไรดีกว่า ในโครงการก่อนหน้าของเราเราใช้ในการตรวจสอบและปฏิบัติต่อทุกพารามิเตอร์อินพุตภายในฟังก์ชั่น (ตัวอย่างเช่นถ้ามันไม่เป็นโมฆะ) ตอนนี้ฉันได้อ่านที่นี่ในคำตอบบางอย่างและในหนังสือเล่มโปรแกรมเมอร์ Pragmatic ว่าการตรวจสอบพารามิเตอร์อินพุตเป็นความรับผิดชอบของผู้โทร ดังนั้นหมายความว่าฉันควรตรวจสอบพารามิเตอร์อินพุตก่อนที่จะเรียกใช้ฟังก์ชัน มีการเรียกใช้ฟังก์ชันทุกที่ และนั่นทำให้เกิดคำถามหนึ่งข้อ: มันไม่ได้สร้างเงื่อนไขการตรวจสอบซ้ำทุกที่ที่มีการเรียกใช้ฟังก์ชันหรือไม่ ฉันไม่ได้สนใจเพียงแค่ในเงื่อนไขที่เป็นโมฆะ แต่ในการตรวจสอบตัวแปรอินพุตใด ๆ (ค่าลบเพื่อsqrtฟังก์ชั่นหารด้วยศูนย์การรวมรัฐและรหัสไปรษณีย์ผิดหรืออย่างอื่น) มีกฎบางอย่างในการตัดสินใจว่าจะตรวจสอบสภาพอินพุตอย่างไร ฉันกำลังคิดถึงข้อโต้แย้งบางอย่าง: เมื่อการรักษาของตัวแปรที่ไม่ถูกต้องอาจแตกต่างกันเป็นสิ่งที่ดีในการตรวจสอบในด้านของผู้โทร (เช่นsqrt()ฟังก์ชั่น - ในบางกรณีฉันอาจต้องการที่จะทำงานกับจำนวนที่ซับซ้อนดังนั้นฉันปฏิบัติต่อเงื่อนไขในการโทร) เมื่อเงื่อนไขการตรวจสอบเหมือนกันในผู้โทรทุกคนควรตรวจสอบภายในฟังก์ชั่นเพื่อหลีกเลี่ยงการซ้ำซ้อน การตรวจสอบความถูกต้องของพารามิเตอร์อินพุตในตัวเรียกเกิดขึ้นเพียงครั้งเดียวก่อนที่จะเรียกใช้ฟังก์ชันจำนวนมากด้วยพารามิเตอร์นี้ ดังนั้นการตรวจสอบความถูกต้องของพารามิเตอร์ในแต่ละฟังก์ชั่นจึงไม่มีประสิทธิภาพ วิธีการแก้ปัญหาที่เหมาะสมขึ้นอยู่กับกรณีเฉพาะ ฉันหวังว่าคำถามนี้จะไม่ซ้ำกันฉันค้นหาปัญหานี้และฉันพบคำถามที่คล้ายกัน แต่พวกเขาไม่ได้พูดถึงกรณีนี้อย่างแน่นอน

16 coding-standards  validation  dry 

เมื่อฉันมีข้อมูลจำนวนมากที่ต้องได้รับการตรวจสอบความถูกต้องฉันควรสร้างคลาสใหม่เพื่อวัตถุประสงค์ในการตรวจสอบความถูกต้องเพียงอย่างเดียวหรือฉันควรจะใช้การตรวจสอบความถูกต้องด้วยวิธีการหรือไม่ ตัวอย่างเฉพาะของฉันพิจารณาแม่แบบทัวร์นาเมนต์และคลาสของเหตุการณ์ / หมวดหมู่: TournamentและEventซึ่งเป็นตัวอย่างของการแข่งขันกีฬาและแต่ละทัวร์นาเมนต์มีหนึ่งหรือหลายประเภท มีทุกสิ่งที่จะตรวจสอบในชั้นเรียนเหล่านี้: ผู้เล่นควรว่างเปล่า, ไม่ซ้ำกัน, จำนวนการแข่งขันที่ผู้เล่นแต่ละคนควรเล่น, จำนวนผู้เล่นแต่ละคนมีการแข่งขัน, การแข่งขันที่กำหนดไว้ล่วงหน้าและอื่น ๆ กฎที่ซับซ้อน นอกจากนี้ยังมีบางส่วนที่ฉันต้องการตรวจสอบโดยรวมเช่นวิธีที่ชั้นเรียนทำงานร่วมกัน ตัวอย่างเช่นการตรวจสอบความถูกต้องแบบรวมPlayerสามารถทำได้ แต่ถ้าเหตุการณ์มีผู้เล่นคนเดียวกันสองครั้งนั่นเป็นข้อผิดพลาดในการตรวจสอบความถูกต้อง แล้วเรื่องนี้ล่ะ: ฉันลืมเกี่ยวกับการตรวจสอบล่วงหน้าอย่างแน่นอนเมื่อใช้ setters ของคลาสโมเดลของฉันและวิธีการที่คล้ายกันเพื่อเพิ่มข้อมูลและแทนที่จะให้คลาสการตรวจสอบจัดการแทน ดังนั้นเราจะมีบางสิ่งที่คล้ายEventValidatorกับการEventเป็นสมาชิกและvalidate()วิธีการที่ตรวจสอบความถูกต้องของวัตถุทั้งหมดรวมถึงวิธีเอกพจน์เพื่อตรวจสอบกฎของสมาชิกทั้งหมด จากนั้นก่อนที่จะสร้างอินสแตนซ์ของวัตถุที่ตรวจสอบได้ฉันจะดำเนินการตรวจสอบเพื่อป้องกันค่าที่ผิดกฎหมาย การออกแบบของฉันถูกต้องหรือไม่ ฉันควรทำอะไรที่แตกต่างออกไปไหม นอกจากนี้ฉันควรใช้บูลีนวิธีการตรวจสอบกลับ? หรือเพียงแค่โยนข้อยกเว้นถ้าการตรวจสอบล้มเหลว? ดูเหมือนว่าสำหรับฉันตัวเลือกที่ดีที่สุดคือวิธีการส่งคืนบูลีนและส่งข้อยกเว้นเมื่อวัตถุนั้นเป็นอินสแตนซ์ตัวอย่างเช่น: public Event() { EventValidator eventValidator = new EventValidator(this); if (!eventValidator.validate()) { // show error messages with methods defined in the validator throw new …

16 java  design  data  validation 

ฉันมักใช้ข้อ จำกัด ในระดับฐานข้อมูลเพิ่มเติมจากรุ่น (ActiveRecord) ของฉัน แต่ฉันสงสัยว่าสิ่งนี้จำเป็นจริงๆหรือ? พื้นหลังเล็กน้อย ฉันเพิ่งต้องทดสอบหน่วยวิธีการสร้างประทับเวลาอัตโนมัติขั้นพื้นฐานสำหรับรุ่น โดยปกติแล้วการทดสอบจะสร้างตัวอย่างของแบบจำลองและบันทึกโดยไม่มีการตรวจสอบความถูกต้อง แต่มีเขตข้อมูลที่จำเป็นอื่น ๆ ที่ไม่สามารถลบล้างได้ในคำจำกัดความของตารางหมายความว่าฉันไม่สามารถบันทึกอินสแตนซ์แม้ว่าฉันจะข้ามการตรวจสอบ ActiveRecord ดังนั้นฉันคิดว่าฉันควรลบข้อ จำกัด ดังกล่าวออกจากฐานข้อมูลตัวเองแล้วปล่อยให้ ORM จัดการกับมันหรือไม่? ข้อได้เปรียบที่เป็นไปได้ถ้าฉันข้ามข้อ จำกัด ใน db, imo - สามารถแก้ไขกฎการตรวจสอบในรูปแบบโดยไม่ต้องย้ายฐานข้อมูล สามารถข้ามการตรวจสอบในการทดสอบ ข้อเสียที่เป็นไปได้? หากเป็นไปได้ว่าการตรวจสอบความถูกต้องของ ORM ล้มเหลวหรือถูกข้ามไปฐานข้อมูลจะไม่ตรวจสอบข้อ จำกัด คุณคิดอย่างไร? แก้ไขในกรณีนี้ฉันใช้Yii Frameworkซึ่งสร้างแบบจำลองจากฐานข้อมูลดังนั้นกฎฐานข้อมูลจึงถูกสร้างขึ้นด้วย

13 database  orm  validation  dry 

ฉันรู้ว่าคุณกำลังคิด (หรืออาจจะตะโกน), "ไม่ใช่คำถามที่ถามอีกว่าการตรวจสอบเป็นของสถาปัตยกรรมชั้นหรือไม่?" ใช่แล้ว แต่หวังว่านี่จะเป็นเรื่องที่ต่างออกไปเล็กน้อย ฉันเชื่อมั่นว่าการตรวจสอบมีหลายรูปแบบตามบริบทและแตกต่างกันไปในแต่ละระดับของสถาปัตยกรรม นั่นเป็นพื้นฐานสำหรับการโพสต์ช่วยระบุประเภทของการตรวจสอบที่ควรดำเนินการในแต่ละชั้น นอกจากนี้คำถามที่มักเกิดขึ้นก็คือการตรวจสอบสิทธิ์ สถานการณ์ตัวอย่างมาจากแอปพลิเคชันสำหรับธุรกิจจัดเลี้ยง ในระหว่างวันผู้ขับขี่อาจเปลี่ยนเป็นเงินสดส่วนเกินที่พวกเขาสะสมไว้ในสำนักงานขณะนำรถบรรทุกจากที่หนึ่งไปยังอีกที่หนึ่ง แอปพลิเคชั่นอนุญาตให้ผู้ใช้บันทึก 'เงินสดลดลง' โดยการรวบรวม ID ของไดรเวอร์และจำนวนเงิน นี่คือรหัสโครงกระดูกบางส่วนเพื่อแสดงเลเยอร์ที่เกี่ยวข้อง: public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application …

13 domain-driven-design  validation  layers 

ฉันเรียนรู้เรื่องการทำความสะอาดและด้วยเหตุนี้ฉันจึงคิดใหม่อย่างมากเกี่ยวกับวิธีการออกแบบและเขียนซอฟต์แวร์ สิ่งที่ฉันยังคงต่อสู้ด้วยมีไว้สำหรับกฎเกณฑ์ทางธุรกิจเช่น "ในการอัปเดตการบันทึกบางรายการก่อนอื่นโหลดรายการทั้งหมดที่ฉันได้รับอนุญาตให้ดู / แก้ไข ฯลฯ ยืนยันว่ารายการนี้อยู่ในรายการ และหมวดหมู่รายการไม่ได้ถูกล็อกจากการใช้งาน (และกฎอื่น ๆ ฯลฯ ) ".. เนื่องจากเป็นกฎธุรกิจ (ซับซ้อน แต่ไม่ผิดปรกติ) ดังนั้นจึงควรจัดการในโดเมนแอปพลิเคชันแทนที่จะผลักดันตรรกะทางธุรกิจลงใน ชั้น db / การคงอยู่ อย่างไรก็ตามดูเหมือนว่าสำหรับฉันที่จะตรวจสอบเงื่อนไขเหล่านี้ได้อย่างมีประสิทธิภาพมันมักจะได้รับการจัดการที่ดีที่สุดกับแบบสอบถาม DB ที่สร้างขึ้นมาอย่างดีแทนที่จะโหลดข้อมูลทั้งหมดลงในโดเมนแอปพลิเคชัน ... หากไม่มีการปรับให้เหมาะสมก่อนเวลาอันควรแนวทางที่แนะนำหรือบทความบ็อบลุงจัดการกับคำถามนี้คืออะไร หรือเขาจะพูดว่า "ตรวจสอบในโดเมนจนกว่ามันจะกลายเป็นปัญหา" ?? ฉันกำลังดิ้นรนเพื่อค้นหาตัวอย่าง / ตัวอย่างที่ดีสำหรับสิ่งอื่นใดนอกเหนือจากกรณีพื้นฐานที่สุดของการใช้งาน ปรับปรุง: สวัสดีทุกคนขอบคุณสำหรับการตอบกลับ ฉันควรจะชัดเจนกว่าฉันเขียนซอฟต์แวร์ (ส่วนใหญ่เป็นแอปพลิเคชันเว็บ) เป็นเวลานานและมีประสบการณ์แล้วและเห็นด้วยกับทุกหัวข้อที่คุณอธิบายร่วมกัน (ตรวจสอบโดยแบ็กเอนด์ไม่เชื่อถือข้อมูลลูกค้าโดยทั่วไป ไล่ล่าประสิทธิภาพดิบเมื่อจำเป็นเท่านั้น แต่รับทราบจุดแข็งของเครื่องมือ db เมื่อมีให้ใช้ ฯลฯ ) และได้ผ่านวงจรการเรียนรู้ของนักพัฒนาของ "โยนทั้งหมดเข้าด้วยกัน" เพื่อ "สร้างตัวควบคุมไขมันยักษ์ด้วยแอปพลิเคชัน N-tiers" และตอนนี้ชอบและตรวจสอบสไตล์ความรับผิดชอบที่สะอาด …

13 clean-code  domain-model  validation  business-rules 

เป็นวิธีปฏิบัติที่ดีที่จะใช้การจัดการข้อยกเว้นที่ไร้ประโยชน์หรือไม่ในกรณีที่ส่วนอื่นของรหัสไม่ได้เข้ารหัสอย่างถูกต้อง? ตัวอย่างพื้นฐาน คนที่เรียบง่ายดังนั้นฉันจึงไม่สูญเสียทุกคน :) สมมติว่าฉันกำลังเขียนแอพที่จะแสดงข้อมูลของบุคคล (ชื่อที่อยู่ ฯลฯ ) ข้อมูลที่ถูกแยกออกจากฐานข้อมูล สมมติว่าฉันเป็นผู้เขียนส่วน UI และคนอื่นกำลังเขียนรหัสแบบสอบถาม DB ทีนี้ลองจินตนาการว่าข้อมูลจำเพาะของแอพของคุณบอกว่าถ้าข้อมูลของบุคคลนั้นไม่สมบูรณ์ (สมมติว่าชื่อหายไปในฐานข้อมูล) ผู้ที่เข้ารหัสแบบสอบถามควรจัดการสิ่งนี้โดยส่งกลับ "NA" สำหรับฟิลด์ที่หายไป เกิดอะไรขึ้นถ้าแบบสอบถามมีการเข้ารหัสไม่ดีและไม่จัดการกรณีนี้ จะเป็นอย่างไรถ้าคนที่เขียนข้อความค้นหาจัดการกับผลลัพธ์ที่ไม่สมบูรณ์และเมื่อคุณพยายามที่จะแสดงข้อมูลทุกอย่างก็ขัดข้องเพราะรหัสของคุณไม่ได้เตรียมที่จะแสดงสิ่งที่ว่างเปล่า? ตัวอย่างนี้เป็นพื้นฐานมาก ฉันเชื่อว่าพวกคุณส่วนใหญ่จะพูดว่า "ไม่ใช่ปัญหาของคุณคุณไม่ต้องรับผิดชอบต่อความผิดพลาดนี้" แต่ก็ยังคงเป็นส่วนหนึ่งของรหัสของคุณที่ขัดข้อง ตัวอย่างอื่น สมมติว่าตอนนี้ฉันเป็นคนเขียนแบบสอบถาม ข้อกำหนดไม่ได้พูดเหมือนกับข้างต้น แต่คนที่เขียนแบบสอบถาม "แทรก" ควรตรวจสอบให้แน่ใจว่าเขตข้อมูลทั้งหมดจะเสร็จสมบูรณ์เมื่อเพิ่มบุคคลในฐานข้อมูลเพื่อหลีกเลี่ยงการแทรกข้อมูลที่ไม่สมบูรณ์ ฉันควรจะปกป้องแบบสอบถาม "เลือก" ของฉันเพื่อให้แน่ใจว่าฉันให้ข้อมูลที่สมบูรณ์เกี่ยวกับ UI หรือไม่ คำถาม ถ้าข้อมูลจำเพาะไม่ได้พูดอย่างชัดเจนว่า "คนนี้เป็นคนที่รับผิดชอบในการจัดการสถานการณ์นี้"? ถ้าบุคคลที่สามใช้แบบสอบถามอื่น (คล้ายกับแบบสอบถามแรก แต่ใช้ฐานข้อมูลอื่น) และใช้รหัส UI ของคุณเพื่อแสดง แต่ไม่จัดการกรณีนี้ในรหัสของเขา ฉันควรทำสิ่งที่จำเป็นเพื่อป้องกันความผิดพลาดที่อาจเกิดขึ้นแม้ว่าฉันจะไม่ใช่คนที่ควรจัดการกับคดีที่ไม่ดี? ฉันไม่ได้มองหาคำตอบเช่น "(s) เขาเป็นคนรับผิดชอบต่อความผิดพลาด" เนื่องจากฉันไม่ได้แก้ไขข้อขัดแย้งที่นี่ฉันอยากรู้ว่าฉันควรป้องกันโค้ดของฉันจากสถานการณ์ที่ไม่ใช่ความรับผิดชอบของฉันหรือไม่ …

12 language-agnostic  validation  exception-handling 

ฉันชอบจุดที่เพิ่มความสามารถของ MVC ช่วยให้มุมมองแบบจำลองใช้ IValidatableObject และเพิ่มการตรวจสอบความถูกต้องที่กำหนดเอง ฉันพยายามควบคุมให้ตัวควบคุมของฉันคงอยู่เพราะการใช้รหัสนี้เป็นเพียงตรรกะการตรวจสอบเท่านั้น: if (!ModelState.IsValid) return View(loginViewModel); ตัวอย่างเช่นโมเดลมุมมองล็อกอินใช้ IValidatableObject รับวัตถุ ILoginValidator ผ่านการสร้างคอนสตรัค: public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } ดูเหมือนว่า Ninject การฉีดอินสแตนซ์ในมุมมองแบบจำลองไม่ใช่วิธีปฏิบัติทั่วไปจริง ๆ อาจเป็นรูปแบบการต่อต้านหรือไม่ นี่เป็นวิธีที่ดีหรือไม่? มีดีกว่าไหม

12 architecture  asp.net-mvc  dependency-injection  validation  single-responsibility 

ฉันคิดถึงเรื่องนี้มาระยะหนึ่งแล้วและอยากรู้อยากเห็นจากนักพัฒนาคนอื่น ๆ ฉันมักจะมีรูปแบบการเขียนโปรแกรมที่ป้องกันมาก บล็อกหรือวิธีทั่วไปของฉันมีลักษณะดังนี้: T foo(par1, par2, par3, ...) { // Check that all parameters are correct, return undefined (null) // or throw exception if this is not the case. // Compute and (possibly) return result. } นอกจากนี้ในระหว่างการคำนวณฉันจะตรวจสอบพอยน์เตอร์ทั้งหมดก่อนที่จะทำการลงทะเบียนอีกครั้ง ความคิดของฉันคือถ้ามีข้อผิดพลาดและตัวชี้ NULL บางอย่างควรปรากฏที่ใดที่หนึ่งโปรแกรมของฉันควรจัดการสิ่งนี้อย่างดีและเพียงปฏิเสธที่จะคำนวณต่อไป แน่นอนมันสามารถแจ้งปัญหาที่เกิดขึ้นกับข้อผิดพลาดในบันทึกหรือกลไกอื่น ๆ เพื่อให้เป็นไปในทางที่เป็นนามธรรมยิ่งกว่าแนวทางของฉันคือ if all input is OK --> …

12 validation  user-interaction 

เมื่อฉันพยายามสร้างส่วนต่อประสานสำหรับโปรแกรมเฉพาะฉันมักจะพยายามหลีกเลี่ยงการโยนข้อยกเว้นที่ขึ้นอยู่กับอินพุตที่ไม่ผ่านการตรวจสอบ ดังนั้นสิ่งที่มักจะเกิดขึ้นคือฉันคิดว่าโค้ดบางส่วนเช่นนี้ (นี่เป็นเพียงตัวอย่างเพื่อประโยชน์ของตัวอย่างไม่ต้องสนใจฟังก์ชั่นที่ใช้งานตัวอย่างใน Java): public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) …

11 design  design-patterns  programming-practices  performance  validation 

เราใช้งานPexมากับโค้ดบางตัวและมันก็แสดงให้เห็นถึงสิ่งที่ดี (สิ่งเลวร้าย แต่แสดงให้พวกเขาเห็นก่อนที่มันจะเริ่มผลิต!) อย่างไรก็ตามหนึ่งในสิ่งที่ดีเกี่ยวกับ Pex คือมันไม่จำเป็นต้องหยุดพยายามค้นหาปัญหา สิ่งหนึ่งที่เราพบคือเมื่อผ่านสตริงเราไม่ได้ตรวจสอบสตริงว่าง ดังนั้นเราจึงเปลี่ยน: if (inputString == null) ถึง if (string.IsNullOrEmpty(inputString)) // *** ที่แก้ไขปัญหาเบื้องต้น แต่เมื่อเราวิ่ง Pex อีกครั้งก็ตัดสินใจว่า inputString = "\0"; ก่อให้เกิดปัญหา และจากนั้น inputString = "\u0001"; สิ่งที่เราได้ตัดสินใจคือสามารถใช้ค่าเริ่มต้นได้หากเราพบ// ***และเรายินดีที่จะเห็นข้อยกเว้นที่เกิดจากข้อมูลแปลก ๆ อื่น ๆ (และจัดการกับมัน) เพียงพอหรือไม่

11 validation  strings  defensive-programming 

ฉันสงสัยว่าถ้าใครใช้ Windows Workflow Foundation สำหรับเอ็นจิ้น BusinessRules / Validation สำเร็จหรือถ้าคุณรู้รหัสตัวอย่างหรือบทความเกี่ยวกับเรื่องนี้ ถ้าคุณเคยใช้มันมาก่อนคุณคิดอย่างไร? เป็นอย่างไรบ้างเมื่อเปรียบเทียบกับระบบ BusinessRule / Validation อื่น ๆ ? ฉันคิดว่ากฎเช่น if (A, B, and C) AllowAccess(); หรือ if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

ฉันมีแอพพลิเคชั่น ASP.NET MVC ที่ใช้บริการสอบถามเพื่อรับข้อมูลและบริการคำสั่งเพื่อส่งคำสั่ง คำถามของฉันเกี่ยวกับส่วนคำสั่ง หากมีการร้องขอเข้ามาบริการคำสั่งจะใช้โปรแกรมเลือกจ่ายงานคำสั่งที่จะกำหนดเส้นทางคำสั่งไปยังตัวจัดการคำสั่งที่กำหนดไว้ ตัวจัดการคำสั่งนี้ตรวจสอบความถูกต้องของ comand ก่อนและหากทุกอย่างเป็นที่ยอมรับก็จะดำเนินการคำสั่ง ตัวอย่างที่เป็นรูปธรรม: AddCommentToArticleCommandHandler ได้รับ AddCommentToArticleCommand ซึ่งมี ArticleId, CommentText และ EmailAddress ครั้งแรก; การตรวจสอบจะต้องเกิดขึ้นเช่น: - ตรวจสอบว่ามีบทความอยู่หรือไม่ - ตรวจสอบว่าบทความไม่ได้ปิดอยู่หรือไม่ - ตรวจสอบว่ามีการกรอกข้อความแสดงความคิดเห็นและระหว่าง 20 ถึง 500 อักขระหรือไม่ - ตรวจสอบว่ากรอกอีเมลแล้วหรือไม่ ฉันสงสัยว่าจะใช้การตรวจสอบนี้ที่ไหน 1 / ในตัวจัดการคำสั่งเอง แต่จะไม่สามารถนำกลับมาใช้ใหม่ได้ในตัวจัดการคำสั่งอื่น 2 / ในนิติบุคคลโดเมน แต่เป็นนิติบุคคลที่โดเมนไม่ทราบเกี่ยวกับที่เก็บหรือบริการจึงไม่สามารถทำการตรวจสอบที่จำเป็น (ไม่สามารถตรวจสอบว่ามีบทความ) แต่ในทางกลับกันหากเอนทิตีไม่มีตรรกะมากกว่าจะกลายเป็นที่เก็บข้อมูลอย่างง่ายซึ่งไม่เป็นไปตามหลักการ DDD 3 / ตัวจัดการคำสั่งใช้ตัวตรวจสอบความถูกต้องเพื่อให้การตรวจสอบสามารถนำกลับมาใช้ในตัวจัดการคำสั่งอื่น ๆ 4 / …

11 c#  architecture  domain-driven-design  validation  cqrs 

ฉันกำลังทำงานกับระบบที่อนุญาตให้ผู้ดูแลระบบกำหนดฟอร์มที่มีฟิลด์ แบบฟอร์มที่กำหนดจะถูกใช้เพื่อป้อนข้อมูลไปยังระบบ บางครั้งแบบฟอร์มจะถูกกรอกโดยมนุษย์ผ่าน GUI บางครั้งแบบฟอร์มจะถูกกรอกตามค่าที่รายงานโดยระบบอื่น สำหรับแต่ละฟิลด์ผู้ดูแลระบบสามารถกำหนดกฎการตรวจสอบที่ จำกัด ค่าที่อนุญาตสำหรับฟิลด์ กฎการตรวจสอบสามารถเป็นอะไรก็ได้จาก "ค่าที่ป้อนในฟิลด์ต้องเป็นจริงหรือเท็จ" ถึง "ค่าที่ป้อนในฟิลด์ต้องมีอยู่ในคอลัมน์ A ของตาราง B ในฐานข้อมูล" ผู้ดูแลระบบสามารถเปลี่ยนแปลงกฎการตรวจสอบสำหรับฟิลด์ได้ตลอดเวลา ในสถานการณ์นี้ความคิดเห็นของคุณเป็นสถานที่ที่เหมาะสมที่สุดสำหรับการตรวจสอบว่าแต่ละเขตข้อมูลถูกกรอกอย่างถูกต้องหรือไม่ ฉันมีสองวิธีหลักในใจ: ตัวเลือก # 1: ตรวจสอบความถูกต้องในรูปแบบโดเมน แต่ละวัตถุฟิลด์จะมีกฎการตรวจสอบที่ระบุโดยผู้ดูแลระบบ วัตถุฟิลด์จะมีการอ้างอิงถึง IValidator เมื่อมีความพยายามในการตั้งค่าของฟิลด์ฟิลด์จะผ่านค่าที่กำหนดและกฎการตรวจสอบไปยัง IValidator หากค่าที่ระบุไม่ถูกต้องจะมีการโยน ValidationException และจัดการอย่างเหมาะสมใน GUI / อินเตอร์เฟสไปยังระบบอื่น ข้อดี: การป้องกันที่แข็งแกร่งสำหรับฟิลด์ที่ถูกกำหนดค่าโดยไม่ตั้งใจซึ่งละเมิดกฎการตรวจสอบ จุดด้อย: Data Access Layer ต้องสามารถผ่านการตรวจสอบและสร้างเขตข้อมูลที่ละเมิดกฎการตรวจสอบปัจจุบัน แม้ผู้ดูแลระบบจะเปลี่ยนกฎการตรวจสอบสำหรับเขตข้อมูล แต่เรายังจำเป็นต้องสร้างวัตถุเขตข้อมูลตามข้อมูลเก่าเช่นเมื่อแสดงแบบฟอร์มที่กรอกข้อมูลเมื่อหลายปีก่อน สิ่งนี้อาจแก้ไขได้โดยการเก็บกฎการตรวจสอบปัจจุบันเมื่อใดก็ตามที่เราเก็บฟิลด์ ในการออกแบบนี้โมเดลฟิลด์มีลิงก์ทางอ้อมไปยัง Data Access Layer / Repository …

10 design-patterns  architecture  domain-driven-design  validation 

เกี่ยวกับการพิมพ์เป็ด : การพิมพ์เป็ดนั้นได้รับความช่วยเหลือจากการไม่ได้ทดสอบประเภทของข้อโต้แย้งในวิธีการและร่างกายโดยอาศัยเอกสารประกอบรหัสที่ชัดเจนและการทดสอบเพื่อให้แน่ใจว่าการใช้งานถูกต้อง เกี่ยวกับการตรวจสอบข้อโต้แย้ง (EAFP: ง่ายกว่าที่จะขอการอภัยมากกว่าการอนุญาต) ตัวอย่างที่ดัดแปลงจากที่นี่ : ... มันเป็นสิ่งที่ต้องทำยิ่งกว่า: def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else ซึ่งหมายความว่าทุกคนที่ใช้รหัสของคุณไม่จำเป็นต้องใช้พจนานุกรมจริงหรือคลาสย่อย - พวกเขาสามารถใช้วัตถุใด ๆ ที่ใช้อินเทอร์เฟซการแมป น่าเสียดายในทางปฏิบัติมันไม่ง่ายอย่างนั้น ถ้าสมาชิกในตัวอย่างด้านบนอาจเป็นจำนวนเต็ม จำนวนเต็มไม่เปลี่ยนรูปดังนั้นจึงเหมาะสมอย่างยิ่งที่จะใช้เป็นคีย์พจนานุกรม อย่างไรก็ตามพวกมันยังใช้เพื่อจัดทำดัชนีวัตถุประเภทลำดับ หากสมาชิกเกิดขึ้นเป็นจำนวนเต็มตัวอย่างที่สองสามารถผ่านรายการและสตริงเช่นเดียวกับพจนานุกรม เกี่ยวกับการเขียนโปรแกรมที่แน่วแน่ : การยืนยันเป็นวิธีที่เป็นระบบในการตรวจสอบว่าสถานะภายในของโปรแกรมเป็นไปตามที่โปรแกรมเมอร์คาดไว้โดยมีเป้าหมายในการจับข้อบกพร่อง โดยเฉพาะอย่างยิ่งพวกเขาดีสำหรับการจับสมมติฐานที่ผิดพลาดที่เกิดขึ้นในขณะที่เขียนรหัสหรือใช้อินเทอร์เฟซโดยโปรแกรมเมอร์อื่น นอกจากนี้พวกเขาสามารถทำหน้าที่เป็นเอกสารในบรรทัดบางส่วนโดยทำให้สมมติฐานของโปรแกรมเมอร์ชัดเจน ("ชัดเจนดีกว่าโดยนัย") แนวคิดที่กล่าวถึงบางครั้งมีข้อขัดแย้งดังนั้นฉันจึงพิจารณาปัจจัยต่อไปนี้เมื่อเลือกว่าฉันไม่ได้ทำการตรวจสอบความถูกต้องของข้อมูลเลยให้ทำการตรวจสอบความถูกต้องอย่างแรงหรือใช้การยืนยัน: การตรวจสอบที่แข็งแกร่ง โดยการตรวจสอบที่แข็งแกร่งฉันหมายถึงการเพิ่มข้อยกเว้นที่กำหนดเอง ( ApiErrorตัวอย่าง) หากฟังก์ชัน / เมธอดของฉันเป็นส่วนหนึ่งของ API สาธารณะจะเป็นการดีกว่าถ้าตรวจสอบอาร์กิวเมนต์เพื่อแสดงข้อความแสดงข้อผิดพลาดที่ดีเกี่ยวกับประเภทที่ไม่คาดคิด โดยการตรวจสอบประเภทที่ฉันไม่ได้หมายถึงการใช้เพียงอย่างเดียวisinstanceแต่ยังถ้าวัตถุผ่านการสนับสนุนอินเทอร์เฟซที่จำเป็น …

10 python  validation  assertions  duck-typing 

คุณใช้ทั้งเทคนิคการตรวจสอบลูกค้าและฝั่งเซิร์ฟเวอร์เมื่อตรวจสอบข้อมูลจากผู้ใช้เช่นผ่านแบบฟอร์มการติดต่อหรือไม่ ถ้าเป็นเช่นนั้นจริงหรือไม่ คุณเป็นวิศวกรหรือเปล่า

10 web-development  validation