วัตถุควรรู้รหัสของตัวเองหรือไม่?

obj.idดูเหมือนว่าค่อนข้างธรรมดาและดูเหมือนว่าจะตกอยู่ในช่วงของสิ่งที่วัตถุสามารถรู้เกี่ยวกับตัวเอง ฉันพบว่าตัวเองถามว่าทำไมวัตถุของฉันควรรู้รหัสของตัวเอง?

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

ฉันเคยพบปัญหาที่ฉันต้องการทำให้วัตถุเป็นอนุกรมกับ JSON สำหรับ RESTful API ซึ่ง ID ดูเหมือนจะไม่พอดีกับเพย์โหลด แต่มีเพียง URI และรวมไว้ในวัตถุทำให้ยากขึ้น

วัตถุควรรู้ว่าเป็น id ของตัวเองหรือไม่? ทำไมหรือทำไมไม่?

อัปเดต : ข้อกำหนด

1. id: แอตทริบิวต์ตัวระบุบนวัตถุ ในแง่ฐานข้อมูลคีย์ตัวแทนไม่ได้เป็นคีย์ธรรมชาติ
2. วัตถุ: เอนทิตีหรือวัตถุที่ระบุตัวตนไม่ซ้ำกันภายในระบบ

คำตอบสั้น ๆ : การรวมตัวระบุวัตถุภายในวัตถุนั้นเป็นสิ่งจำเป็นถ้ามันจะถูกเรียก

สำหรับสถานการณ์ที่คุณวางแผนที่จะใช้การรวบรวมวัตถุและมีแผนในการอ้างอิงวัตถุ / นิติบุคคลแต่ละรายการจากนั้นควรรวมตัวระบุ อย่างไรก็ตามอาจมีกรณีที่คีย์ธรรมชาติ / ตัวระบุเช่นDateTimeสามารถเติมเต็มความต้องการที่ต้องการ

นอกจากนี้คุณอาจมีDTOของคุณเป็นคอนเทนเนอร์ที่มีน้ำหนักเบาของวัตถุของคุณซึ่งอาจข้าม / รวมตัวระบุวัตถุในตัวเอง จริงๆทุกทางเลือกนี้เป็นจริงขึ้นอยู่กับกรณีการใช้งานธุรกิจและความต้องการของคุณ

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

ในความพยายามที่จะให้คำตอบของฉันเป็นนามธรรมเหมือนคำถามของคุณฉันคิดว่าคุณได้ตอบคำถามของคุณเอง

วัตถุควรรู้ ID ของตัวเองหากต้องการ

วัตถุไม่ควรรู้ ID ของมัน (หรือมันมีอยู่ด้วย) ถ้ามันไม่ต้องการ

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

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

ตัวอย่างเช่นหากคุณกำลังสร้าง API ด้วยสองวิธี:

• http://api.example.com/products/

  โหลดรายการรหัสผลิตภัณฑ์

• http://api.example.com/product/452/

  โหลดผลิตภัณฑ์ของ ID 452

จากนั้นคุณไม่จำเป็นต้องส่ง ID 452 อีกครั้งในการตอบสนอง JSON ของคำขอที่สอง ผู้ใช้ API รู้รหัสแล้ว

ฉันคิดว่ามันเป็นเรื่องส่วนตัวและขึ้นอยู่กับการออกแบบของคุณ

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

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

ยกตัวอย่างPersonวัตถุ ฉันได้รับชื่อซึ่งอาจหรืออาจจะไม่ซ้ำกันภายในครอบครัว ในขณะที่จำนวนประชากรเพิ่มขึ้นชื่อที่ใหญ่ขึ้นนั้นไม่ซ้ำกันอีกต่อไปดังนั้นเราจึงได้สร้างตัวระบุตัวแทนสำหรับระบบที่มีขนาดใหญ่ขึ้นเรื่อย ๆ ตัวอย่างของสิ่งเหล่านี้ ได้แก่ ใบขับขี่ของฉันและหมายเลขประกันสังคม ฉันไม่ได้เกิด ID ที่ได้รับมอบหมายต้องใช้รหัสเหล่านี้ทั้งหมด

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

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

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

ในซอฟต์แวร์หากคุณต้องการแสดงวัตถุเป็นรายการหรือคงอยู่คุณสามารถทำได้จากวัตถุที่เก็บ / รวบรวมหรือวัตถุอื่น ๆ ที่เกี่ยวข้อง เมื่อส่งต่อไปยัง Data Mapper (ถ้าแยกต่างหาก) คุณสามารถส่ง.update( id, obj )ได้

คำเตือน : ฉันยังไม่ได้พยายามที่จะสร้างระบบที่ไม่มีรหัสภายในองค์กรและอาจพิสูจน์ตัวเองผิด

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

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

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

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

คุณถูกต้องคุณไม่จำเป็นต้องเก็บ ID ไว้ในวัตถุตราบใดที่คุณจำเป็นต้องรู้มันในบริบทที่เก็บของคุณ

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

ในสถานการณ์นั้นคุณมีสองตัวเลือก:

• แนะนำอาร์กิวเมนต์ของฟังก์ชั่นใหม่ 'id' ในห่วงโซ่ทั้งหมดของฟังก์ชั่นระหว่างบริบทที่เก็บและฟังก์ชั่นที่จำเป็นต้องใช้รหัส

• รวมรหัสในวัตถุ

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

นั่นเป็นเหตุผลที่ฉันทำมันเมื่อฉันทำมัน