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

2
รูปแบบการออกแบบ Protobuf
ฉันกำลังประเมินบัฟเฟอร์ของ Google Protocol สำหรับบริการบน Java (แต่คาดว่าจะมีรูปแบบของผู้ไม่เชื่อเรื่องภาษา) ฉันมีสองคำถาม: คำถามแรกคือคำถามทั่วไปที่กว้างขวาง: เราเห็นรูปแบบอะไรที่ผู้คนใช้? รูปแบบดังกล่าวเกี่ยวข้องกับองค์กรระดับ (เช่นข้อความต่อไฟล์ .proto, บรรจุภัณฑ์และการจัดจำหน่าย) และคำจำกัดความของข้อความ (เช่นเขตข้อมูลซ้ำแล้วซ้ำกับเขตข้อมูลที่ห่อหุ้มซ้ำ *) เป็นต้น มีข้อมูลประเภทนี้น้อยมากในหน้าความช่วยเหลือของ Google Protobuf และบล็อกสาธารณะในขณะที่มีข้อมูลจำนวนมากสำหรับโปรโตคอลที่กำหนดเช่น XML ฉันยังมีคำถามเฉพาะเหนือรูปแบบที่แตกต่างกันสองแบบ: แสดงข้อความในไฟล์ .proto, จัดเก็บเป็น jar แยกต่างหากและจัดส่งไปยังผู้บริโภคเป้าหมายของบริการ - ซึ่งเป็นวิธีการเริ่มต้นที่ฉันเดา ทำเช่นเดียวกัน แต่รวมถึงการห่อด้วยมือที่สร้างขึ้น (ไม่ใช่คลาสย่อย!) รอบ ๆ แต่ละข้อความที่ใช้สัญญาที่สนับสนุนอย่างน้อยสองวิธีนี้ (T คือคลาส wrapper, V คือคลาสของข้อความ (ใช้ชื่อสามัญ : public V toProtobufMessage() { V.Builder builder = …

1
ทำไม Protobuf 3 ทำให้ฟิลด์ทั้งหมดในข้อความเป็นตัวเลือก?
ไวยากรณ์ 3 ของ protobuf ทำให้ฟิลด์ทั้งหมดเป็นตัวเลือกที่ทิ้งคำหลักrequiredและoptionalจากไวยากรณ์ proto2 ก่อนหน้า อ่านความคิดเห็นจากนักพัฒนาดูเหมือนว่ามันทำเพื่อเพิ่มความเข้ากันได้ไบนารีไปข้างหน้า / ถอยหลัง แต่สำหรับฉันนั้นสามารถบังคับใช้ได้โดยเพียงแค่กำหนดชื่อแพคเกจพูดcom.example.messages.v1แล้วปล่อยให้ลูกค้าใช้ deserializers ที่พวกเขาเข้าใจ ในขณะเดียวกันก็ลบสัญญาบางฉบับที่ระบุว่าเป็นประเภทที่มีประโยชน์จากมุมมองด้านวิศวกรรมซอฟต์แวร์ เช่นถ้าฉันมี message Location { double latitude = 1; double longitude = 2; } ใน proto3 เป็นไปได้ที่จะสร้างการสำรองข้อมูลครึ่งหนึ่ง แต่ใช้ได้อย่างสมบูรณ์แบบLocationโดยไม่ได้ให้ข้อมูลหนึ่งในฟิลด์ที่จำเป็น นี่เป็นข้อเสียเปรียบครั้งใหญ่เมื่อสร้างรูปแบบการทำให้เป็นอนุกรมตามสคีมาสำหรับการแลกเปลี่ยนข้อมูลระหว่างลูกค้าหรือไม่ การย้ายรหัสตรวจสอบพิเศษเพิ่มเติมไปยังไคลเอนต์แต่ละรายไม่ได้แย่ไปกว่าการตรวจสอบว่าฟิลด์ที่จำเป็นทั้งหมดมีค่าที่ถูกต้องหรือไม่
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.