我已经为 Compact Framework 实现了一个流行层（包括BinaryFormatter-类似序列化器）。我希望能够在适当的情况下序列化编译器生成的类，这些类是由 lambda 和迭代器等产生的，这样如果（例如） lambda 及其封闭变量（即显示类实例）添加到可序列化对象上的事件，并且所有封闭变量都是可序列化的，则生成的对象图仍然是完全可序列化的。
如果这些类的实例只能由完全相同的构建它们被序列化的二进制文件的数量——流行层主要是为了在应用程序意外终止时提供持久性（电源故障和设备重新启动是不同的可能性），并且序列化的数据流预计不会向前或向后兼容，或者甚至在同一源代码的两个编译之间兼容——当我们下次与它交谈时，所有结果都将被发送到服务器，并且我们不会在断开连接时进行更新。
在这种有限的上下文中，我的格式化程序将这些编译器生成的类视为可序列化是否合理？我看到的唯一替代方案是在可序列化性受到关注的地方手动实现编译器支持的模式，其后果从过于冗长到几乎不可读。
我明白你的意思，但根据我的经验，专注于序列化是一个更好的主意data，并通过回滚/前滚到已知状态来处理持久性，可能使用本地 CQRS 队列之类的东西，或者存储“如何到达那里”的其他方式。
关于具体问题，在问题的严格范围内（仅在同一版本等上工作）我guess这应该没问题，但这在很大程度上取决于是否有任何事情is在这些变量中捕获没有合理的序列化- 即类似于 UI 元素的东西（很容易被不可见的意外捕获）this）无法重建（操作系统句柄等）。如果它是孤立的数据（我的意思是：图表只是来自您自己的代码中的数据 - 没有非托管依赖项），那么我猜它是should be OK.
另一个问题是 CF 缺乏完整框架中可用的更强的反射，这可能会比常规框架中的情况更尴尬（GetUninitializedObject http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices.getuninitializedobject.aspx例如）。可能可行，但需要更多工作。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
