序列化LinqToSql生成的实体保持关系和延迟加载

Question

我们有一个使用LINQ to SQL的相当大的ASP.NET MVC项目，我们正在迁移到Windows Azure。

现在，我们需要序列化对象以存储在Azure分布式缓存中，并在.dbml文件中将“序列化模式”设置为“单向”，从而相应地使用DataContract和DataMember属性自动装饰生成的类和属性，似乎是推荐的方法。但是，当序列化并保存为null时，这会使LINQ to SQL尚未加载的任何关系丢失。

考虑到以下几点，首选的处理方式是什么：

• 如上所述，它是一个相当大型项目，生成的* .designer.cs文件接近1.5MB
• 完全禁用延迟加载很可能会很大 由于许多深层次的关系，性能达到。
• 正在考虑改变ORM工具，但在切换平台的同时这样做可能会是一件坏事。

如果这归结为以某种方式手动指定要在整个项目中序列化的对象和关系;使用像 protobuf-net 之类的东西获得一些额外的性能提升可能不会是一个巨大的进步。

Answer 1

  

但是，这会使LINQ to SQL尚未加载的任何关系在序列化时丢失并保存为null。

是的，这是正常的，并且在序列化时是预期的 - 您实际上是在拍摄当时可用内容的快照，因为延迟加载取决于它是通过数据上下文加载的。任何工具都无法抓取整个模型来寻找要加载的东西，因为这可能会无限期地继续下去，从根本上带来大量不需要的数据。

选项：

• 在序列化之前显式获取（通过“loadwith”或通过命中相应的属性预先获取）您感兴趣的数据
• 或者，将数据加载到完全独立的 DTO模型中进行序列化 - 在很多方面，这是第一个的重新声明，因为它将必要涉及迭代（投射）您想要的数据，但这意味着您正在创建DTO以适合您实际想要发送的确切形状