可序列化的最佳实践 [关闭]答案

【问题标题】：Serializable Best Practice [closed]可序列化的最佳实践 [关闭]
【发布时间】：2016-01-04 23:50:30
【问题描述】：

当我第一次开始编写 ASP.NET 应用程序时，我采用的一种做法是将 [Serializable] 属性放在我编写的所有模型/DTO 类上。原因是如果类被序列化为 Session 或 Cache 对象，该属性将确保对象正确序列化。

我很早就没有使用 [Serializable] 属性，因为我们的开发环境使用 InProc Sessions（单服务器），所以在将 Web 应用程序部署到生产 Web 场之前，Serializable 问题才浮出水面使用进程外会话状态。换句话说，序列化错误只会在生产中出现。

我想知道对所有模型/DTO 类使用 [Serializable] 属性是否仍然是最佳实践。使用 ASP.NET MVC 和 Web API 应用程序有一些副作用。比如处理backing fields。有一些选项可以删除支持字段前缀。不幸的是，当表单在 MVC 中回发时，这会破坏自动属性映射，因为属性不包含支持字段前缀。

【问题讨论】：

这完全取决于什么库在进行序列化。所以我想说这不仅不是最好的做法，而且在你明确需要它之前用属性装饰所有 DTO 是一种代码味道。

标签： c# asp.net asp.net-mvc serialization asp.net-web-api

【解决方案1】：

为了检测序列化失败，即使在开发环境中也要使用 out of proc session storage。借助会话状态服务，这很容易设置。

当你做出一些[Serializable] 限制你在该课程中可以做的事情时。例如，您可能不想保留大对象图。选择加入序列化似乎是一个更安全的选择。序列化是相当危险和脆弱的。

【讨论】：

对于所有域和 DTO 对象，它们都支持序列化，但是您有一个有效的观点，即默认情况下使用 Serializable 属性不是最佳实践。

【解决方案2】：

不幸的是，当表单在 MVC 中回发时，这会破坏自动属性映射，因为属性不包含支持字段前缀

您确定由于这个原因绑定不起作用吗？

反正我通常不使用 [serializable]，因为 MVC/web.api 不需要

【讨论】：

是的，我最终不得不在 MVC 中手动映射属性。
我在其他项目中有我的 DTO 和域模型对象，以便它们可以被重用。我在非 Web 项目中使用它们，例如控制台应用程序和 Windows 服务。
我刚刚尝试使用 Mvc 5.2.3.0 并且绑定似乎与 [Serializable] dto 一起使用