将序列化模式设置为单向是否有任何缺点或性能损失?

时间:2014-01-27 11:13:15

标签: c# linq serialization linq-to-sql datacontext

我想为我的某个应用程序实体添加历史记录功能。我的应用程序使用linq to sql作为O / RM。 我选择用于保存以前版本的实体的解决方案是序列化旧版本并在某处保存序列化版本。

无论如何,我一直在寻找将linq序列化为sql实体的最佳方法。我发现的最好的解决方案之一就是在DataContext对象中将序列化模式设置为Unidirectional,然后使用.net serializer。看来该方法效果很好。

但是,我的问题是,这种方法对数据上下文或任何性能影响都有任何副作用吗?例如,在打开单向序列化模式后,延迟加载对象是否完好无损?

我经常搜索但却一无所获。

并且,你认为我应该采用另一种方式来序列化对象吗?任何更便宜的方法?

PS 1:我不喜欢使用DTO,因为我应该保持DataContext对象和DTO之间的兼容性。

PS 2:请注意,我正在处理的应用程序相对较大,目前负载很重。所以我应该注意O / RM行为或性能问题的变化,因为我无法查看整个应用程序+在线版本。

非常感谢:)

1 个答案:

答案 0 :(得分:1)

Re“然后使用.net serializer”,单向模式的目的是支持DataContractSerializer(具体而言)。效果基本上只是[DataContract] / [DataMember]标志的添加,但是:根据经验,尽管您有所保留,但我会强烈建议您去DTO路线:

  • ORMs,由于子集和属性的延迟加载(有时)使得很难准确预测将会发生什么
  • 同时,当数据加载发生时很难监控(序列化代码中的N + 1可能不会被注意到)
  • 你几乎无法控制模型的大小(有多少级别的后代等)将被序列化
  • 甚至没有让我开始使用父导航
  • 反序列化的对象没有数据上下文,这意味着它们的延迟加载不起作用 - 这可能导致意外行为
  • 如果您无法将数据模型与序列化模型分开进行版本化,则可能会遇到各种问题
  • 有一些......“特性”会影响LINQ-to-SQL和序列化(从内存来看,最“有趣”的是IList.AddIList<T>.Add的实现方式不同,意思是一个触发数据更改标志,一个不触发;讨厌)
  • 您所做的一切都取决于您的数据模型,这也意味着您永远不能更改您的数据模型(至少,不容易)
  • 很多涉及DTO的场景都是基于读取的,而不是基于写入的,因此您可能首先不需要ORM开销 - 例如,您可能能够替换一些热门代码路径片段更轻的工具(小巧玲珑等) - 如果一切都做不好 与数据模型联系在一起

强烈主张咬紧牙关并创建一个与您要序列化的DTO模型相匹配的模型; DTO模型非常简单,只需要几分钟就能完成,包括映射到数据模型/从数据模型映射的代码。这将使您可以完全控制序列化的内容,同时还可以自由地进行迭代,并且可以使用不同的序列化程序