有什麼辦法可以減少breeze.js的有效載荷大小，還是我應該不擔心呢？

對於客戶端使用Breeze.js，對於服務器使用BreezeController，它生成的有效負載大小對我來說似乎效率低下。例如通過像這樣3個屬性的簡單分頁投影時：有什麼辦法可以減少breeze.js的有效載荷大小，還是我應該不擔心呢？

.select("Property1, Property2, Property3")

，每個記錄包含以下內容作爲類型：

"$type":"_IB_eTB9_dNYb7IWzNREO3W5Uer5DOQ8[[System.String, mscorlib],[System.String, mscorlib],[System.String, mscorlib]]

明明多個屬性包括我在我的投影長這將是，在許多情況下，類型「定義」比實際數據長得多，並且對於每一行都重複。

我擔心什麼也沒有辦法減少這種情況？

2013-03-24 mutex

儘管壓縮並不是什麼大問題，但他們已經通過自定義序列化解決了這個問題。 http://www.getbreezenow.com/documentation/controlling-serialization – slopapa 2014-11-25 20:27:57

這是一個有趣的問題。當您請求投影（使用select語句進行查詢）而不是實體時，這實際上更像是一個問題，因爲至少對於.NET服務器來說，匿名類型的json序列化有點醜陋。查看沒有選擇的查詢的結果，您會看到有效負載更加合理。

也就是說，我們應該可以修改默認的json.net格式化程序來簡化匿名類型信息的序列化，特別是因爲我們在客戶端意識到它不匹配時基本上忽略它在客戶端上任何「已知」類型。如果您感興趣，請將其添加到Breeze User Voice。我們確實關注這些功能請求。

2013-03-25 03:25:19

謝謝Jay，我會將它添加到用戶語音中，因爲這聽起來不錯:) – mutex 2013-03-25 04:36:41

要回答我的問題，我會說我不應該擔心這個（很可能「過線的元數據」適用於更廣泛的關注太）

假設我們打開gzip壓縮，我的測試表明，所有無關的元數據與最終壓縮有效載荷的大小差別不大，我想這並不奇怪。

2013-03-25 02:43:53 mutex

回答