2012-02-14 37 views
1

我想爲我們的應用程序構建一個必須能夠處理繼承的序列化系統。更復雜的是,應用程序是可擴展的,因此在編譯時可能不太可能知道類型。protobuf-net繼承和字段編號

我已經通過了previous stackoverflow question這個回答,並且幫助我實現了自己的目標,但是我碰到了一個絆腳石,可能比任何真正的問題更缺乏理解!

所以這是我當前的代碼...

public interface IBaseFrame 
{ 

} 

public class BasicDataFrame : IBaseFrame 
{ 

} 

public class AnotherFrame : BasicDataFrame 
{ 

} 

。 。 。 。

RuntimeTypeModel model = TypeModel.Create(); 
MetaType baseType = model.Add(typeof(IBaseFrame), true); 
MetaType basicFrameType = model.Add(typeof(BasicDataFrame),true); 

baseType.AddSubType(7, typeof(BasicDataFrame)); 
model.Add(typeof(AnotherFrame), true); 

basicFrameType.AddSubType(8, typeof(AnotherFrame)); 

下面這段代碼可以正常工作(據我可以告訴!),所有在世界上良好...我關心的是其中的值7和8在上面的代碼爲fieldNumber使用 AddSubType方法的參數。

由於插件列舉我登記他們的幀類型與SerialisationManager,我將它們添加到模型的fieldNumber遞增計數器(我開始在它任意大量的,所以我不必擔心未來擴展基類)。

我擔心,如果插件按不同的順序枚舉或添加新的插件(或刪除),那麼自動生成的字段編號將會因不同的子類型而不同,然後會導致共享問題用戶之間的日誌文件(可能有不同的插件和子類型),甚至當插件可能已被刪除時,甚至在同一系統上的文件。

有沒有用這種繼承的自動處理,並沒有在未來引入的兼容性問題或任何狡猾的方式,當插件更改或者我需要拿出其中這些fieldNumbers可以保證留含量的不同機制跨所有安裝?

任何可以給予的幫助或建議將不勝感激!

+1

剛纔意識到我應該提到我正在使用網站上的版本2的測試版 - r480。 – Anthony 2012-02-14 14:00:33

回答

2

這裏沒有魔法;這些數字基本上是合同的一部分,如果您想要反序列化先前存儲的數據,那麼重要的是它們可以可靠地複製。如果在編譯時無法知道數據,可能配置或某些類型到字段號的外部註冊表可能會有所幫助。你的擔心是準確的。

+1

我很懷疑!噢,即使應用程序可以通過插件機制進行擴展,它通常會是我們自己公司(或「可信任」第三方)內部的人員,他們正在創建插件,因此我們將不得不實施某種程序來發布數字。幸運的是,我們已經有一個屬性來裝飾每個FrameType並提供一些元數據,我們可以在其中添加一個fieldNumber - 我只是想驗證我們沒有什麼魔法可用! 使用不連續的「大」數字是否有任何潛在的缺陷? – Anthony 2012-02-14 15:54:41