我們將協議緩衝區引入一些後端RPC服務的新傳輸中。因爲在不同形式的類似對象之間手動傳遞數據是有阻力的，所以我可以將協議緩衝區實例傳遞給堆棧比RPC服務器接口高一點。使用協議緩衝區作爲通用數據對象？
這是我應該儘量避免的事情嗎？處理一個協議緩衝區對象像一個普通的數據持有者是否安全，它有很好的方便性，它可以快速有效地將其轉換爲二進制文件並將其轉換爲二進制文件？
另一個我認爲是生成數據對象的好方法的原因是必需/可選字段的概念和自動生成的構建器接口。
嗯，他們不是很可能方便使用這種方式，因爲它們是不可變的 - 你可以傳遞構建器，但這使得相當長的類型名稱。這也意味着您僅限於協議緩衝區（和您自己的消息）支持的數據類型。
這是安全要做到這一點，但它並不總是創造最好的設計。另一方面，有時這正是醫生訂購的內容:)
我建議你嘗試一下 - 這裏沒有「一刀切」。
一般來說，我設計了我的系統層，以便來自一個層的實現細節不會互相泄漏。我沒有Google協議緩衝區的直接經驗，但它聽起來像您想要在傳輸層和系統的更高層使用相同的表示法。
如果您決定要停止使用Protocol Buffers作爲傳輸表示法，那麼使用其他方法會有多容易？
這實際上是朝着這個方向邁出的一步。現在，一組接口規定了我們的數據層，後端RPC *和*一些擴展了RESTful Web服務層。 *疼痛*。步驟＃1是用協議緩衝區替換後端以將其從其餘的解耦。但這是一個很好的觀點。如果我只是把所有東西都切換到protobufs，我唯一解耦的是客戶端和RPC服務之間的鏈接，而所有其他層將依賴於Message對象... BAD。 – 2009-11-25 21:13:59
當談到使用像這樣的協議緩衝區時，我認爲它們是不可變的事實實際上有助於而不是傷害。它們就像String一樣是不可變的值對象。 – 2009-11-25 20:22:54
在某些情況下，當你可以用功能風格編寫代碼時，它肯定會有所幫助。它部分取決於問題，部分取決於開發人員:) – 2009-11-25 20:40:58
不確定性在某些情況下確實有所幫助，由於未知原因，存在一些帶有一打+左右參數的公共構造，全部分配給最終字段。建築師是偉大而乏味的，並且每次都要寫下樣板。獲取必要和可選權限的邏輯也很棘手，例如，如果必填字段被省略，build（）方法就會爆炸。 – 2009-11-25 21:11:05