Tại sao Protobuf 3 làm cho tất cả các trường trên tin nhắn là tùy chọn?

Cú pháp 3 của protobuf làm cho tất cả các trường tùy chọn bỏ các từ khóa requiredvà optionaltừ cú pháp proto2 trước đó. Đọc một số ý kiến ​​từ các nhà phát triển , có vẻ như nó đã được thực hiện để tăng cường khả năng tương thích nhị phân tiến / lùi.

Nhưng đối với tôi, điều đó có thể được thực thi bằng cách chỉ phiên bản tên gói, nói com.example.messages.v1và sau đó cho phép khách hàng thực hiện trình giải mã mà họ hiểu. Đồng thời, nó loại bỏ một số hợp đồng được nêu là một loại hữu ích theo quan điểm công nghệ phần mềm. Ví dụ nếu tôi có

message Location {
   double latitude = 1;
   double longitude = 2;
}

Trong proto3 có thể tạo một nửa được hỗ trợ nhưng hoàn toàn hợp lệ Locationbằng cách không cung cấp một trong các trường bắt buộc.

Không phải đó là một nhược điểm lớn khi tạo định dạng tuần tự hóa dựa trên lược đồ để trao đổi dữ liệu giữa các máy khách? Không tệ hơn khi di chuyển mã xác thực bổ sung cho từng khách hàng kiểm tra xem tất cả các trường bắt buộc có giá trị hợp lệ không?

proto3 thực hiện một số thay đổi nhằm mục đích (theo tôi hiểu) để làm cho nó trở nên hữu dụng hơn nhiều trong các kịch bản đa nền tảng. Theo dõi rõ ràng "được chỉ định" so với "không được chỉ định nhưng báo cáo giá trị mặc định" có thể rất khó thực hiện trên một số nền tảng đích và cũng có thể gây nhầm lẫn khi sử dụng. Như vậy, proto3 áp dụng cách tiếp cận đơn giản hơn nhiều:

• những tiềm ẩn giá trị mặc định là giá trị tự nhiên không (số / enums), sai (boolean) hoặc chuỗi rỗng (chuỗi)
• chỉ cho phép mặc định ngầm; không cho phép các giá trị mặc định khác
• nếu một trường có giá trị mặc định đó, nó không được tuần tự hóa; không quan trọng việc nó có được gán rõ ràng cho zero / false / chuỗi rỗng so với không bao giờ được gán không
• bởi vì điều này, không có khái niệm "bắt buộc", vì "được gán rõ ràng một giá trị 0" và "không bao giờ được gán một giá trị" trông giống hệt nhau

Trong proto3, có thể tạo một Vị trí được hỗ trợ một nửa nhưng hoàn toàn hợp lệ bằng cách không cung cấp một trong các trường bắt buộc.

Giá trị khác là: không. Thực tế là bạn đã không gán nó một cách rõ ràng là không. Điều này có mong muốn hay không là tùy thuộc vào bạn, nhưng nó có ý nghĩa với tôi và là cách rất nhiều "khởi tạo một đối tượng / struct mới" hoạt động trên một loạt các nền tảng.

Không tệ hơn khi di chuyển mã xác thực bổ sung cho từng khách hàng kiểm tra xem tất cả các trường bắt buộc có giá trị hợp lệ không?

Không có gì để xác nhận! Bố cục chính xác là như thế nào nếu giá trị 0 được gán rõ ràng. Nếu đó là hợp pháp, nó là hợp pháp. Nếu đó là bất hợp pháp (vì số 0 không có ý nghĩa với bạn), thì đó là bất hợp pháp; nhưng nó sẽ là bất hợp pháp cho dù đó là rõ ràng hay ngầm. Số lượng xác nhận liên quan không thay đổi.

Không phải đó là một nhược điểm lớn khi tạo định dạng tuần tự hóa dựa trên lược đồ để trao đổi dữ liệu giữa các máy khách?

Không thường xuyên, không ... đặc biệt là vì phiên bản lược đồ là rõ ràng. Nếu bạn muốn sử dụng proto2: sử dụng proto2. Không có gì thay đổi tự động.