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

【问题标题】：serializing LinqToSql generated entities keeping relations and lazy loading序列化 LinqToSql 生成的实体保持关系和延迟加载
【发布时间】：2013-10-08 11:17:00
【问题描述】：

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

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

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

如前所述，这是一个相当大型项目，生成的 *.designer.cs 文件接近 1.5MB
完全禁用延迟加载很可能是一个大问题 性能下降由于许多深厚的阶级关系。
更改 ORM 工具是我们正在考虑的事情，但在切换平台的同时这样做可能是一件坏事。

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

【问题讨论】：

我的意见：不要使用生成的实体进行序列化/rpc。构建一个您可以控制且符合要求的单独传输模型。您正在强制单个模型服务于两个不同的用例，从而在许多不同的地方造成麻烦。重用实体类节省的工作量是负数。

标签： c# linq-to-sql serialization azure protobuf-net

【解决方案1】：

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

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

选项：

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

【讨论】：