2013-10-08 66 views
1

我們使用LINQ to SQL,我們在遷移到Windows Azure的過程中一個相當大的ASP.NET MVC項目實體。序列化LinqToSql產生保持關係和延遲加載

現在,我們需要將對象序列,用於存儲在天青分佈式緩存,並設置「序列化模式」到「單向」在.dbml文件,並因此自動地裝飾生成的類和屬性DataContractDataMember相應的屬性,似乎是推薦的方式。但是,這會導致LINQ to SQL尚未加載的任何關係在序列化並保存爲null時丟失。

什麼是程序的首選方式,同時考慮到一兩件事情:

  • 如前所述,這是一個相當大的項目與生成的*了.Designer.cs文件是接近1.5 MB
  • 禁用延遲加載完全將最有可能是一個很大的 性能命中由於許多深階級關係。
  • 更改ORM工具是我們正在考慮的東西,但在同一時間,交換平臺這樣做,很可能是一件壞事。

如果這可以歸結爲以某種方式手動指定要在整個項目中序列化哪些對象和關係;使用類似protobuf網一些額外的性能提升可能不會是一個巨大的進步。

+0

我的意見:不要使用生成的實體進行序列化/ RPC。建立一個由您控制的獨立運輸模型,並且符合要求。你迫使一個模型服務兩種不同的用例,在許多不同的地方造成麻煩。通過重用實體類節省的工作量是負面的。 – usr

回答

2

但是,這使得在序列化和保存爲空時LINQ to SQL尚未加載的任何關係都將丟失。

是的,這是正常的和預期的序列化時 - 你基本上是採取什麼當時可用快照,因爲延遲加載依賴於它正在通過數據上下文加載。對於任何工具來說,抓取整個模型尋找需要加載的東西都是不可取的,因爲這可能會無限期地持續下去,基本上會帶來大量不需要的數據。

選項:

  • 明確地獲取(或者先發制人經由「loadwith」,或通過敲擊合適的屬性)你有興趣的數據串行化
  • 或,將數據加載到一個之前完全獨立的 DTO模式進行序列化 - 在很多方面,這是第一次的重新聲明,因爲它會必然涉及循環訪問(投影),你需要的數據,但它意味着你正在創建的DTO,以適應確切形狀你其實想送