แท้จริงแล้วความไม่รู้ความพากเพียรคืออะไร?

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

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

ฉันไม่เชื่อว่าความเข้าใจ (หรือคำจำกัดความ) ของคุณเกี่ยวกับ "ความไม่คงอยู่ถาวร" ของคุณนั้นผิด

ปัญหา ของจริง คือ นามธรรมที่รั่วไหล . พูดง่ายๆ ก็คือ เทคโนโลยีที่มีอยู่ทำให้การนำ PI ที่แท้จริงไปใช้มาก

ฉันเห็นด้วยกับ Mikeb - "ความไม่รู้ที่คงอยู่" เป็นการเลื่อนระดับ ไม่ใช่คุณสมบัติจริง/เท็จของ ORM ที่กำหนด

คำจำกัดความของ PI ที่แท้จริง 100% ของฉันคือคุณสามารถคงคลาส POCO ใด ๆ ที่เป็นไปได้ได้ ไม่ว่าจะซับซ้อนและเชื่อมโยงกับคลาสอื่นเพียงใดก็ตาม โดยไม่ต้องเปลี่ยนคลาส แต่อย่างใด

การเพิ่มฟิลด์ ID, การตกแต่งด้วยแอตทริบิวต์, สืบทอดมาจากคลาส ORM, ต้องออกแบบคลาสของคุณเพื่อให้แมปกับตารางพื้นฐานใน RDB ได้ดี - ทั้งหมดนี้ลด "คะแนน PI" ให้ต่ำกว่า 100%

ตามที่กล่าวมา ฉันเลือกใช้ Fluent NHibernate Automapping เนื่องจากดูเหมือนว่าจะมีคะแนน PI สูงสุดในบรรดาตัวเลือก ORM ใดๆ ที่ฉันเคยดู

คลาสที่ไม่รู้แบบถาวรคือคลาสที่ไม่เชื่อมโยงกับกรอบการคงอยู่

นั่นคือ คลาสไม่มีความรู้เลยว่ามีเฟรมเวิร์กการคงอยู่อยู่ โดยไม่ได้สืบทอดมาจากคลาสที่กำหนดโดยเฟรมเวิร์กนั้น และไม่ได้ใช้อินเทอร์เฟซที่จำเป็นสำหรับเฟรมเวิร์กการคงอยู่นั้นเพื่อที่จะทำงาน

ฉันเห็นด้วยกับคำจำกัดความของคุณ:

ดังนั้นจึงสมเหตุสมผลหรือไม่ที่จะกล่าวว่า "ความไม่รู้แบบคงอยู่" เป็นจริงเมื่อวัตถุอำนวยความสะดวกในการใช้กรอบงานการคงอยู่ แต่ไม่ได้ดำเนินการตรรกะการคงอยู่ใด ๆ ด้วยตนเอง

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

แม้ว่าอาจมีข้อจำกัดเล็กๆ น้อยๆ บางประการที่กรอบการทำงานเกี่ยวกับการคงอยู่-ความไม่รู้ใดๆ กำหนดไว้ แต่การคงอยู่-ความไม่รู้นั้นยังคงมีอยู่

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

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

คุณสามารถใช้คลาสสำหรับโดเมนหรือแอปพลิเคชันของคุณและคลาส POCO ในการคงอยู่ เมื่อคุณจะคงอยู่วัตถุโดเมนจะแมปมันลงในคลาสการคงอยู่ของคุณและใช้วัตถุการคงอยู่เพื่อจัดเก็บด้วย nhibernate หรือกรอบงานอื่น ๆ

คลาสโดเมนของคุณจะต้องเพิกเฉยต่อวิธีการคงข้อมูล ดังนั้นคุณจะต้องไม่รวมกฎใด ๆ ของเฟรมเวิร์กการคงอยู่เช่น (ตัวสร้างว่าง คุณสมบัติเสมือน ฯลฯ )

กฎกรอบการคงอยู่เหล่านี้สามารถอยู่ในคลาสการคงอยู่ของคุณ