หลักฐานปัจจุบันสนับสนุนการยอมรับบริบทผ่านแบบจำลองข้อมูลของแคนนอนหรือไม่


9

แนวคิด "บัญญัติ" นั้นแพร่หลายในซอฟต์แวร์ รูปแบบเช่นCanonical Model , Canonical Schema , Canonical Data Modelเป็นต้นดูเหมือนจะเกิดขึ้นซ้ำแล้วซ้ำอีกในการพัฒนา

เช่นเดียวกับนักพัฒนาหลายคนฉันมักจะติดตามอย่างไม่ถี่ถ้วนภูมิปัญญาดั้งเดิมที่คุณต้องการแบบจำลองที่เป็นที่ยอมรับมิฉะนั้นคุณจะต้องเผชิญกับการระเบิดของนักทำแผนที่และนักแปล หรืออย่างน้อยฉันก็เคยทำเช่นนั้นจนกระทั่งสองสามปีที่ผ่านมาเมื่อฉันอ่านEF Vote of No Confidence เป็นครั้งแรก:

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

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

ดังนั้นฉันจึงสงสัยว่ามีการวิจัยอย่างจริงจังในเรื่องของผลกระทบระยะยาวในทางปฏิบัติของการมีแบบจำลองมาตรฐานและแบบจำลองเชิงบริบทในระบบซอฟต์แวร์หรือสถาปัตยกรรมหรือไม่?

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

แล้วความแตกต่างในระดับต่าง ๆ คือการใช้แบบจำลองเดียวกันในแอพพลิเคชั่นเดียวกับการใช้ข้ามระบบของแอพพลิเคชั่นหรือทั้งองค์กร

(โปรดข้อเท็จจริงเท่านั้นยินดีต้อนรับเรื่องราวสงคราม แต่ไม่มีการเก็งกำไร)


ฉันไม่รู้ว่าสิ่งที่พวกเขากำลังพูดถึงในบทความ "โหวตไม่มั่นใจ" ส่วนที่เหลือของบทความทำให้รู้สึก แต่ส่วนเกี่ยวกับ Canonicalism เป็นนามธรรมจนไม่ได้มีความหมายอะไร คงจะดีถ้าพวกเขายกตัวอย่างสิ่งที่พวกเขาพูดถึง
Robert Harvey

@ Robert: ฉันไม่รู้ว่ามีความจริงกับมัน แต่มันค่อนข้างชัดเจนสำหรับฉันมันหมายถึงอะไร ... แน่นอนคุณคุ้นเคยกับรูปแบบ CM / CDM? ในการจุติที่ง่ายที่สุดคือการแบ่งปันโมเดล (หรือ Linq กับ SQL หรืออะไรก็ตาม) แบบ monolithic เดียวในแอปพลิเคชั่นทั้งหมดแทนที่จะใช้วิธีการดักฟังท่อ (การรับรู้) มากขึ้นในการเขียนข้อความค้นหาเฉพาะสำหรับส่วนเฉพาะของแอปพลิเคชัน ในระดับที่สูงขึ้นก็ใช้ schema สากลสำหรับทั้งองค์กรที่ทุกแอปพลิเคชัน / ระบบต้องแปล
Aaronaught

1
ดูเหมือนว่าศูนย์การอภิปรายของ EF จะมีการออกแบบในตารางแรกกับคลาสแรกเนื่องจากการออกแบบตารางแรก (ซึ่งคลาสนั้นถูกสร้างขึ้นจากตาราง) แสดงถึงโมเดลเสาหิน (แม้ว่าจะมีคำสั่งและมุมมองที่เฉพาะเจาะจงเสมอ) (ที่ซึ่งตารางถูกสร้างขึ้นจากคลาส) แนะนำแบบจำลอง tap-tapey ที่มีความยืดหยุ่นมากขึ้น ฉันเป็นเด็กโรงเรียนเก่าชอบเลือกวิธีแรกในตาราง แต่ฉันสามารถดูว่าวิธีการในชั้นแรกจะน่าสนใจสำหรับบางคน
Robert Harvey

@ Robert มันไม่ใช่ความตั้งใจของฉันที่จะนำเสนอ "การอภิปรายของ EF" ฉันเพิ่งเอาใบเสนอราคาเดียวออกจากหน้านั้นเพราะมันเป็นที่ที่ฉันได้ยินการโต้เถียงครั้งแรก (และฉันไม่แน่ใจว่าฉันได้ยินมันหรือไม่ แสดงออกอย่างชัดเจนทุกที่อื่น) แยกกันฉันไม่แน่ใจว่าฉันเห็นด้วยว่าการออกแบบตารางแรกแสดงถึงแบบจำลองเสาหินจริง ๆ ฐานข้อมูลเองแต่มีเพียง DBMS เท่านั้นที่ทราบอย่างแท้จริง - ส่วนต่าง ๆ ของแอปพลิเคชันมักจะรับรู้เฉพาะตารางและแบบสอบถามที่เฉพาะเจาะจงเท่านั้น
Aaronaught

คำตอบ:


5

ในการตอบสนองต่อEF โหวตไม่ไว้วางใจบทความทิม Mallalieu เขียน:

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

ตัวอย่างเช่นพิจารณาแอปพลิเคชันที่จะเขียนกับฐานข้อมูลที่มี 600 ตาราง ฉันเชื่อว่าแอพนี้ควรมีรูปแบบเดียวกับ 600 Entity Types อยู่หรือไม่ ไม่…นอกจากนี้ฉันเชื่อว่าเอนทิตีของโดเมนใด ๆ (ลูกค้าพูด) มีรูปร่างเดียวในแอปนั้นและรูปร่างนี้ต้องเป็นรูปแบบบัญญัติสำหรับองค์กรทั้งหมดหรือไม่… Heck no.

บทความ Wikipedia สำหรับ Canonical Model อ้างอิงถึงสิ่งต่างๆเช่นEnterprise Service Bus , Service-Oriented ArchitectureและCORBAสิ่งที่ดูเหมือนว่าพวกเขาไม่ได้พูดถึงอีกต่อไป พวกเขาทั้งหมดถูกวางเป็นวิธีแก้ปัญหาการแพร่กระจายข้อมูลและความท้าทายในการสื่อสารขององค์กรOne Ring to Rule Them All TM พวกเขาประสบความสำเร็จ? หรือว่าพวกเขายุบตัวภายใต้น้ำหนักของตัวเอง?


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

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

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


ปัญหาที่ บริษัท ใหญ่เผชิญนั้นคล้ายกัน Microsoft มีแนวโน้มที่จะคิดในแง่เสาหิน แต่นั่นเป็นเพราะ บริษัท ของพวกเขาคือเสาหินขนาดใหญ่ ทันทีที่คุณต้องการสื่อสารระหว่าง บริษัท ต่าง ๆ ด้วยวัฒนธรรมที่แตกต่างกันอย่างมากมายและวิธีการทำธุรกิจ (หรือระหว่างแผนกต่าง ๆ ใน บริษัท เดียวกัน) One Ring to Rule Them All TMเริ่มสลายตัวทันที


เป็นที่น่าสนใจที่จะรู้ว่านักออกแบบของ Microsoft ไม่แนะนำรุ่น mega-shared น่าเสียดายที่ Linq กับ SQL และ EF และ ORM อื่น ๆ มีแนวโน้มที่จะใช้ ไม่ว่าจะมีผู้คนจำนวนมากออกไปที่นั่นเพื่อส่งเสริมแนวคิดของ Canonical Model และฉันก็ยังอยากจะรู้ว่ามันเป็นอย่างไรในทางปฏิบัติกับทางเลือก
Aaronaught

@Aaraught: ดูการแก้ไขของฉัน
Robert Harvey

เป็นการแก้ไขที่ดีและ FYI ฉันได้อัปเดตแล้ว อย่างไรก็ตามฉันได้ตระหนักถึงปัญหาความไม่ลงรอยกันเฉพาะหลายอย่างที่เกิดขึ้นเมื่อพยายามทำให้รูปแบบเป็นที่ยอมรับ ฉันสนใจที่จะเรียนรู้ประสบการณ์หรือข้อมูลระยะยาวเกี่ยวกับทีมที่ใช้เวลาในการแก้ไขปัญหาความไม่ลงรอยกันเพื่อที่จะมีผู้ทำแผนที่หนึ่งคนต่อผู้ใช้ปลายทาง -to-end mappers แทนและวิธีการที่ให้ผลโซลูชั่นที่ซับซ้อนต้นทุนต่ำสุด / ต่ำสุดอย่างแท้จริง
Aaronaught

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