11

我正在查看我正在处理的项目中的一些现有代码，我发现了一个实现为的类：

public class ThingOne
{
    private int A;

    private int B;

    [NonSerialized]
    private System.Timers.Timer timer1;
}

它不应该看起来更像这样吗？

[Serializable]
public class ThingOne
{
    private int A;

    private int B;

    [NonSerialized]
    private System.Timers.Timer timer1;
}

或者即使类本身不是可序列化的，添加 [NonSerialized] 是否还有一些额外的好处？

4

5 回答 5

14

或者即使类本身不是可序列化的，添加 [NonSerialized] 是否还有一些额外的好处？

该类不是密封的，因此另一个类可以从该对象继承。该类可以标记为 Serializable，然后 NotSerializable 属性将发挥作用。（尽管指出不是针对私人成员）。

请记住，您也可以通过反射检查属性。运行时可能不会使用它来检查应该序列化和不应该序列化的内容，它可以用作程序中处理某种自定义序列化的其他内容的标记（我并不是说这是一个好主意至少）。

于 2010-09-17T14:00:21.247 回答
8

当不使用 Serializable 时，NonSerialized 将不起作用。默认情况下，类及其成员是不可序列化的。

在类未序列化时声明 NonSerialized 的唯一优点是在该类由 Serialized 对象继承的情况下，然后继承的成员将是不可序列化的。

来自MSDN：

“NonSerialized”属性不会影响此成员，因为它的包含类未公开为“Serializable”。

默认情况下，类及其成员是不可序列化的。仅当不应序列化可序列化类的成员时才需要 NonSerializedAttribute 属性。

于 2010-09-17T13:58:17.820 回答
5

我可以想到两个原因：

  1. 该字段不被序列化可能是至关重要的。因此，如果将来将类设为可序列化，这不会引入错误、效率低下或安全问题，因为如果没有它标记类可序列化，该字段也会这样做。

  2. 他们可能正在对该属性进行某种自定义使用

在情况 2 中，从代码中的其他地方可以清楚地看出这就是正在发生的事情。1 号是很好的做法。

案例 1 是一个很好的实践，值得在 YAGNI（“你不需要它”- 不做“以防以后需要它”）与考虑“好的，但如果我以后需要它，它会如果有人错过了这个领域是一个例外，那将是一场灾难。

因此，虽然它在这里没有效果，但对于它开始产生效果的场景来说，这绝对是一个很好的做法。

编辑：另一种可能性是它与以前的版本相比确实是可序列化的，或者作者当时有两种想法并且从未完全“完成”（工作代码是否完全完成？）。仅仅因为某些东西在代码中，并不意味着它应该是那样的。尽管如此，如果某些东西不被序列化真的很重要，我仍然认为出于上述原因标记它是一种好习惯。

于 2010-09-17T14:04:05.077 回答
4

MSDN SerializeAttribute声明“将 SerializableAttribute 属性应用于一个类型，以指示该类型的实例可以被序列化。”这意味着没有它，类就不能被序列化。我相信我已经尝试过了，如果在 NonSerializable 类型上尝试，序列化将引发异常。

于 2010-09-17T14:02:21.330 回答
2

我同意 Greg 的观点，MSDN 以类似的方式声明，引用参考资料是个好主意。

“默认情况下，类及其成员是不可序列化的。仅当不应序列化可序列化类的成员时才需要 NonSerializedAttribute 属性。”

http://msdn.microsoft.com/en-us/library/dwys85sk(VS.80).aspx

于 2010-09-17T14:01:42.513 回答