使用序列化 C# 比较两个对象
Compare two objects using serialization C#
为什么通过序列化两个对象然后比较字符串来比较两个对象不是一个好习惯，如下例所示？
public class Obj
{
public int Prop1 { get; set; }
public string Prop2 { get; set; }
}
public class Comparator<T> : IEqualityComparer<T>
{
public bool Equals(T x, T y)
{
return JsonConvert.SerializeObject(x) == JsonConvert.SerializeObject(y);
}
public int GetHashCode(T obj)
{
return JsonConvert.SerializeObject(obj).GetHashCode();
}
}
Obj o1 = new Obj { Prop1 = 1, Prop2 = "1" };
Obj o2 = new Obj { Prop1 = 1, Prop2 = "2" };
bool result = new Comparator<Obj>().Equals(o1, o2);
我已经测试过它并且它有效，它是通用的，因此它可以代表各种各样的对象，但我想问的是这种比较对象的方法有哪些缺点？
我看到它在 this question 中被建议并且它收到了一些赞成票，但我无法弄清楚为什么这不是最好的方法，如果有人只想比较两个对象的属性？
编辑： 我严格来说是在谈论 Json 序列化，而不是 XML。
我问这个是因为我想为一个单元测试项目创建一个简单而通用的 Comparator，所以比较的性能不会让我很困扰，因为我知道这可能是其中之一最大的缺点。此外，在 Newtonsoft.Json 的情况下，可以使用 TypeNameHandling 属性 设置为 All 来处理无类型问题。
通过将您的对象序列化为 JSON，您基本上是将所有对象更改为另一种数据类型，因此适用于您的 JSON 库的所有内容都会对您的结果产生影响。
因此，如果其中一个对象中有像 [ScriptIgnore] 这样的标记，您的代码将简单地忽略它，因为它已从您的数据中省略。
此外，对于不同的对象，字符串结果可能相同。像这个例子。
static void Main(string[] args)
{
Xb x1 = new X1()
{
y1 = 1,
y2 = 2
};
Xb x2 = new X2()
{
y1 = 1,
y2= 2
};
bool result = new Comparator<Xb>().Equals(x1, x2);
}
}
class Xb
{
public int y1 { get; set; }
}
class X1 : Xb
{
public short y2 { get; set; }
}
class X2 : Xb
{
public long y2 { get; set; }
}
因此，如您所见，x1 与 x2 的类型不同，甚至这两个 y2 的数据类型也不同，但 json 结果将相同。
除此之外，因为 x1 和 x2 都来自 Xb 类型，我可以毫无问题地调用你的比较器。
首要问题是效率低下
举个例子，假设这个 Equals 函数
public bool Equals(T x, T y)
{
return x.Prop1 == y.Prop1
&& x.Prop2 == y.Prop2
&& x.Prop3 == y.Prop3
&& x.Prop4 == y.Prop4
&& x.Prop5 == y.Prop5
&& x.Prop6 == y.Prop6;
}
如果 prop1 不相同，则无需检查其他 5 个比较，如果您使用 JSON 执行此操作，则必须将整个对象转换为 JSON 字符串，然后进行比较每次都是字符串，这是在序列化之上，它本身就是一项昂贵的任务。
那么下一个问题是序列化是为通信而设计的，例如从内存到文件，通过网络等。如果您利用序列化进行比较，您可能会降低正常使用它的能力，即您不能忽略传输不需要的字段，因为忽略它们可能会破坏您的比较器.
下一个 JSON 具体来说是 Type-less 这意味着比任何形状或形式都不相等的值可能会被误认为是相等的，而在另一方面，相等的值可能不会比较为相等由于格式化，如果它们序列化为相同的值，这又是不安全和不稳定的
此技术的唯一优点是程序员只需付出很少的努力即可实现
首先，我注意到你说 "serialize them and then compare the strings." 一般来说，普通的字符串比较 不会 用于比较 XML 或 JSON 字符串，你必须比那更复杂一点。作为字符串比较的反例，请考虑以下 XML 个字符串：
<abc></abc>
<abc/>
它们显然 不 字符串相等，但它们绝对 "mean" 相同。虽然这个例子看起来有些人为，但事实证明，在很多情况下字符串比较不起作用。例如，空格和缩进在字符串比较中很重要，但在 XML.
中可能不重要
JSON 的情况并没有好多少。您可以为此做类似的反例。
{ abc : "def" }
{
abc : "def"
}
同样，显然它们的意思是一样的，但它们不是字符串相等的。
本质上，如果您正在进行字符串比较，您相信序列化程序总是以完全相同的方式序列化特定对象（没有添加任何空格等），这最终会非常脆弱，尤其是考虑到据我所知，大多数图书馆不提供任何此类保证。如果您在某个时候更新了序列化库并且它们进行序列化的方式存在细微差别，那么这尤其成问题；在这种情况下，如果您尝试将使用先前版本的库序列化的已保存对象与使用当前版本序列化的保存对象进行比较，那么它将不起作用。
此外，正如对代码本身的快速说明，“==”运算符不是比较对象的正确方法。一般来说，“==”测试 reference 相等性，not object 相等性。
关于哈希算法的另一个快速题外话：它们作为相等性测试手段的可靠性取决于它们的抗碰撞性。换句话说，给定两个不同的、不相等的对象，它们散列为相同值的概率是多少？相反，如果两个对象的散列值相同，那么它们实际上相等的几率是多少？许多人理所当然地认为他们的哈希算法是 100% 抗冲突的（即，当且仅当它们相等时，两个对象才会哈希到相同的值），但这不一定是真的。 （一个特别著名的例子是 MD5 加密哈希函数，其相对较差的抗碰撞性使其不适合进一步使用）。对于正确实现的散列函数，在大多数情况下，散列为相同值的两个对象实际上相等的概率足够高，适合作为相等性测试的手段，但不能保证。
这些是一些缺点：
a) 对象树越深性能越差。
b) new Obj { Prop1 = 1 } Equals
new Obj { Prop1 = "1" } Equals
new Obj { Prop1 = 1.0 }
c) new Obj { Prop1 = 1.0, Prop2 = 2.0 } Not Equals
new Obj { Prop2 = 2.0, Prop1 = 1.0 }
我想更正开头的GetHashCode
public class Comparator<T> : IEqualityComparer<T>
{
public bool Equals(T x, T y)
{
return JsonConvert.SerializeObject(x) == JsonConvert.SerializeObject(y);
}
public int GetHashCode(T obj)
{
return JsonConvert.SerializeObject(obj).GetHashCode();
}
}
好了，接下来我们讨论一下这个方法的问题
首先，它不适用于具有循环链接的类型。
如果你有一个像 A -> B -> A 这样简单的 属性 链接，它会失败。
不幸的是，这在相互链接在一起的列表或地图中很常见。
最糟糕的是，几乎没有有效的通用循环检测机制。
其次，与序列化相比，效率低下。
JSON 在成功编译其结果之前需要反射和大量类型判断。
因此，您的比较器将成为任何算法中的严重瓶颈。
通常情况下，即使在几千条记录的情况下，JSON也算够慢了。
第三，JSON每属性都要过一遍。
如果你的对象链接到任何大对象，那将是一场灾难。
如果您的对象链接到一个大文件怎么办？
因此，C# 只需将实现留给用户。
在创建比较器之前必须彻底了解他的class。
比较需要良好的循环检测、提前终止和效率考虑。
根本不存在通用解决方案。
您可以使用 System.Reflections 命名空间来获取实例的所有属性，就像在 this answer 中一样。使用 Reflection，您不仅可以比较 public 属性或字段（例如使用 Json 序列化），还可以比较一些 private、protected等，以提高计算速度。当然，很明显，如果两个对象不同，您不必比较实例的所有属性或字段（不包括只有最后一个 属性 或对象字段不同的示例）。
在以下情况下，使用序列化然后比较字符串表示的对象比较无效：
当需要比较的类型中存在DateTime类型的属性时
public class Obj
{
public DateTime Date { get; set; }
}
Obj o1 = new Obj { Date = DateTime.Now };
Obj o2 = new Obj { Date = DateTime.Now };
bool result = new Comparator<Obj>().Equals(o1, o2);
它会导致 false 即使对象创建的时间非常接近，除非它们不共享完全相同的 属性。
对于具有双精度或小数值的对象，需要与 Epsilon 进行比较以验证它们最终是否彼此非常接近
public class Obj
{
public double Double { get; set; }
}
Obj o1 = new Obj { Double = 22222222222222.22222222222 };
Obj o2 = new Obj { Double = 22222222222222.22222222221 };
bool result = new Comparator<Obj>().Equals(o1, o2);
这也会return false即使double值真的很接近，在涉及计算的程序中，这将成为一个真正的问题，因为精度的损失在多次除法和乘法操作之后，序列化不提供处理这些情况的灵活性。
同时考虑到上述情况，如果不想比较一个属性，就会面临给实际的class引入一个serialize属性的问题，即使没有必要并且它将导致代码污染或问题，它将不得不实际使用该类型的序列化。
注意：这些是这种方法的一些实际问题，但我期待找到其他问题。
对于单元测试，您不需要编写自己的比较器。 :)
只需使用现代框架。例如尝试 FluentAssertions library
o1.ShouldBeEquivalentTo(o2);
序列化用于存储对象或通过当前执行上下文之外的管道（网络）发送对象。不是为了在执行上下文中做某事。
一些序列化的值可能不被认为是相等的，实际上它们是：例如小数“1.0”和整数“1”。
当然你可以像用铲子吃饭一样，但你不这样做，因为你可能会折断你的牙齿！
您可能会继续为问题添加赏金，直到有人告诉您这样做很好。所以你明白了，不要犹豫，利用 NewtonSoft.Json 库来保持代码简单。如果您的代码曾经被审查过或者如果其他人接管了代码的维护，您只需要一些好的论据来捍卫您的决定。
他们可能提出的一些反对意见，以及他们的反驳意见：
This is very inefficient code!
当然是这样，尤其是如果您在字典或哈希集中使用该对象，GetHashCode() 会使您的代码极其缓慢。
最好的反驳是注意效率在单元测试中很少被关注。最典型的单元测试开始的时间比实际执行的时间长，是 1 毫秒还是 1 秒无关紧要。一个你很可能很早就发现的问题。
You are unit-testing a library you did not write!
这当然是一个合理的担忧，您实际上是在测试 NewtonSoft.Json 生成一致的对象字符串表示的能力。有理由对此感到震惊，特别是浮点值（float 和 double）从来都不是问题。还有 图书馆作者不确定如何正确地做到这一点。
最好的反驳是该库被广泛使用并且维护良好，作者多年来发布了许多更新。当您确保具有完全相同的运行时环境的完全相同的程序生成两个字符串（即不存储它）并且您确保单元测试是在禁用优化的情况下构建时，可以推导出浮点一致性问题。
You are not unit-testing the code that needs to be tested!
是的，只有当 class 本身不提供比较对象的方法时，您才会编写此代码。换句话说，它本身不会覆盖 Equals/GetHashCode 并且不会公开比较器。因此，在您的单元测试中测试相等性会执行待测试代码实际上不支持的功能。单元测试永远不应该做的事情，当测试失败时你不能写错误报告。
Counter 参数是因为您需要 来测试相等性来测试class 的另一个特性，比如构造函数或属性 setter。代码中的一个简单注释就足以证明这一点。
为什么通过序列化两个对象然后比较字符串来比较两个对象不是一个好习惯，如下例所示？
public class Obj
{
public int Prop1 { get; set; }
public string Prop2 { get; set; }
}
public class Comparator<T> : IEqualityComparer<T>
{
public bool Equals(T x, T y)
{
return JsonConvert.SerializeObject(x) == JsonConvert.SerializeObject(y);
}
public int GetHashCode(T obj)
{
return JsonConvert.SerializeObject(obj).GetHashCode();
}
}
Obj o1 = new Obj { Prop1 = 1, Prop2 = "1" };
Obj o2 = new Obj { Prop1 = 1, Prop2 = "2" };
bool result = new Comparator<Obj>().Equals(o1, o2);
我已经测试过它并且它有效，它是通用的，因此它可以代表各种各样的对象，但我想问的是这种比较对象的方法有哪些缺点？
我看到它在 this question 中被建议并且它收到了一些赞成票，但我无法弄清楚为什么这不是最好的方法，如果有人只想比较两个对象的属性？
编辑： 我严格来说是在谈论 Json 序列化，而不是 XML。
我问这个是因为我想为一个单元测试项目创建一个简单而通用的 Comparator，所以比较的性能不会让我很困扰，因为我知道这可能是其中之一最大的缺点。此外，在 Newtonsoft.Json 的情况下，可以使用 TypeNameHandling 属性 设置为 All 来处理无类型问题。
通过将您的对象序列化为 JSON，您基本上是将所有对象更改为另一种数据类型，因此适用于您的 JSON 库的所有内容都会对您的结果产生影响。
因此，如果其中一个对象中有像 [ScriptIgnore] 这样的标记，您的代码将简单地忽略它，因为它已从您的数据中省略。
此外，对于不同的对象，字符串结果可能相同。像这个例子。
static void Main(string[] args)
{
Xb x1 = new X1()
{
y1 = 1,
y2 = 2
};
Xb x2 = new X2()
{
y1 = 1,
y2= 2
};
bool result = new Comparator<Xb>().Equals(x1, x2);
}
}
class Xb
{
public int y1 { get; set; }
}
class X1 : Xb
{
public short y2 { get; set; }
}
class X2 : Xb
{
public long y2 { get; set; }
}
因此，如您所见，x1 与 x2 的类型不同，甚至这两个 y2 的数据类型也不同，但 json 结果将相同。
除此之外，因为 x1 和 x2 都来自 Xb 类型，我可以毫无问题地调用你的比较器。
首要问题是效率低下
举个例子，假设这个 Equals 函数
public bool Equals(T x, T y)
{
return x.Prop1 == y.Prop1
&& x.Prop2 == y.Prop2
&& x.Prop3 == y.Prop3
&& x.Prop4 == y.Prop4
&& x.Prop5 == y.Prop5
&& x.Prop6 == y.Prop6;
}
如果 prop1 不相同，则无需检查其他 5 个比较，如果您使用 JSON 执行此操作，则必须将整个对象转换为 JSON 字符串，然后进行比较每次都是字符串，这是在序列化之上，它本身就是一项昂贵的任务。
那么下一个问题是序列化是为通信而设计的，例如从内存到文件，通过网络等。如果您利用序列化进行比较，您可能会降低正常使用它的能力，即您不能忽略传输不需要的字段，因为忽略它们可能会破坏您的比较器.
下一个 JSON 具体来说是 Type-less 这意味着比任何形状或形式都不相等的值可能会被误认为是相等的，而在另一方面，相等的值可能不会比较为相等由于格式化，如果它们序列化为相同的值，这又是不安全和不稳定的
此技术的唯一优点是程序员只需付出很少的努力即可实现
首先，我注意到你说 "serialize them and then compare the strings." 一般来说，普通的字符串比较 不会 用于比较 XML 或 JSON 字符串，你必须比那更复杂一点。作为字符串比较的反例，请考虑以下 XML 个字符串：
<abc></abc>
<abc/>
它们显然 不 字符串相等，但它们绝对 "mean" 相同。虽然这个例子看起来有些人为，但事实证明，在很多情况下字符串比较不起作用。例如，空格和缩进在字符串比较中很重要，但在 XML.
中可能不重要JSON 的情况并没有好多少。您可以为此做类似的反例。
{ abc : "def" }
{
abc : "def"
}
同样，显然它们的意思是一样的，但它们不是字符串相等的。
本质上，如果您正在进行字符串比较，您相信序列化程序总是以完全相同的方式序列化特定对象（没有添加任何空格等），这最终会非常脆弱，尤其是考虑到据我所知，大多数图书馆不提供任何此类保证。如果您在某个时候更新了序列化库并且它们进行序列化的方式存在细微差别，那么这尤其成问题；在这种情况下，如果您尝试将使用先前版本的库序列化的已保存对象与使用当前版本序列化的保存对象进行比较，那么它将不起作用。
此外，正如对代码本身的快速说明，“==”运算符不是比较对象的正确方法。一般来说，“==”测试 reference 相等性，not object 相等性。
关于哈希算法的另一个快速题外话：它们作为相等性测试手段的可靠性取决于它们的抗碰撞性。换句话说，给定两个不同的、不相等的对象，它们散列为相同值的概率是多少？相反，如果两个对象的散列值相同，那么它们实际上相等的几率是多少？许多人理所当然地认为他们的哈希算法是 100% 抗冲突的（即，当且仅当它们相等时，两个对象才会哈希到相同的值），但这不一定是真的。 （一个特别著名的例子是 MD5 加密哈希函数，其相对较差的抗碰撞性使其不适合进一步使用）。对于正确实现的散列函数，在大多数情况下，散列为相同值的两个对象实际上相等的概率足够高，适合作为相等性测试的手段，但不能保证。
这些是一些缺点：
a) 对象树越深性能越差。
b) new Obj { Prop1 = 1 } Equals
new Obj { Prop1 = "1" } Equals
new Obj { Prop1 = 1.0 }
c) new Obj { Prop1 = 1.0, Prop2 = 2.0 } Not Equals
new Obj { Prop2 = 2.0, Prop1 = 1.0 }
我想更正开头的GetHashCode
public class Comparator<T> : IEqualityComparer<T>
{
public bool Equals(T x, T y)
{
return JsonConvert.SerializeObject(x) == JsonConvert.SerializeObject(y);
}
public int GetHashCode(T obj)
{
return JsonConvert.SerializeObject(obj).GetHashCode();
}
}
好了，接下来我们讨论一下这个方法的问题
首先，它不适用于具有循环链接的类型。
如果你有一个像 A -> B -> A 这样简单的 属性 链接，它会失败。
不幸的是，这在相互链接在一起的列表或地图中很常见。
最糟糕的是，几乎没有有效的通用循环检测机制。
其次，与序列化相比，效率低下。
JSON 在成功编译其结果之前需要反射和大量类型判断。
因此，您的比较器将成为任何算法中的严重瓶颈。
通常情况下，即使在几千条记录的情况下，JSON也算够慢了。
第三，JSON每属性都要过一遍。
如果你的对象链接到任何大对象，那将是一场灾难。
如果您的对象链接到一个大文件怎么办？
因此，C# 只需将实现留给用户。
在创建比较器之前必须彻底了解他的class。
比较需要良好的循环检测、提前终止和效率考虑。
根本不存在通用解决方案。
您可以使用 System.Reflections 命名空间来获取实例的所有属性，就像在 this answer 中一样。使用 Reflection，您不仅可以比较 public 属性或字段（例如使用 Json 序列化），还可以比较一些 private、protected等，以提高计算速度。当然，很明显，如果两个对象不同，您不必比较实例的所有属性或字段（不包括只有最后一个 属性 或对象字段不同的示例）。
在以下情况下，使用序列化然后比较字符串表示的对象比较无效：
当需要比较的类型中存在DateTime类型的属性时
public class Obj
{
public DateTime Date { get; set; }
}
Obj o1 = new Obj { Date = DateTime.Now };
Obj o2 = new Obj { Date = DateTime.Now };
bool result = new Comparator<Obj>().Equals(o1, o2);
它会导致 false 即使对象创建的时间非常接近，除非它们不共享完全相同的 属性。
对于具有双精度或小数值的对象，需要与 Epsilon 进行比较以验证它们最终是否彼此非常接近
public class Obj
{
public double Double { get; set; }
}
Obj o1 = new Obj { Double = 22222222222222.22222222222 };
Obj o2 = new Obj { Double = 22222222222222.22222222221 };
bool result = new Comparator<Obj>().Equals(o1, o2);
这也会return false即使double值真的很接近，在涉及计算的程序中，这将成为一个真正的问题，因为精度的损失在多次除法和乘法操作之后，序列化不提供处理这些情况的灵活性。
同时考虑到上述情况，如果不想比较一个属性，就会面临给实际的class引入一个serialize属性的问题，即使没有必要并且它将导致代码污染或问题，它将不得不实际使用该类型的序列化。
注意：这些是这种方法的一些实际问题，但我期待找到其他问题。
对于单元测试，您不需要编写自己的比较器。 :)
只需使用现代框架。例如尝试 FluentAssertions library
o1.ShouldBeEquivalentTo(o2);
序列化用于存储对象或通过当前执行上下文之外的管道（网络）发送对象。不是为了在执行上下文中做某事。
一些序列化的值可能不被认为是相等的，实际上它们是：例如小数“1.0”和整数“1”。
当然你可以像用铲子吃饭一样，但你不这样做，因为你可能会折断你的牙齿！
您可能会继续为问题添加赏金，直到有人告诉您这样做很好。所以你明白了，不要犹豫，利用 NewtonSoft.Json 库来保持代码简单。如果您的代码曾经被审查过或者如果其他人接管了代码的维护，您只需要一些好的论据来捍卫您的决定。
他们可能提出的一些反对意见，以及他们的反驳意见：
This is very inefficient code!
当然是这样，尤其是如果您在字典或哈希集中使用该对象，GetHashCode() 会使您的代码极其缓慢。
最好的反驳是注意效率在单元测试中很少被关注。最典型的单元测试开始的时间比实际执行的时间长，是 1 毫秒还是 1 秒无关紧要。一个你很可能很早就发现的问题。
You are unit-testing a library you did not write!
这当然是一个合理的担忧，您实际上是在测试 NewtonSoft.Json 生成一致的对象字符串表示的能力。有理由对此感到震惊，特别是浮点值（float 和 double）从来都不是问题。还有
最好的反驳是该库被广泛使用并且维护良好，作者多年来发布了许多更新。当您确保具有完全相同的运行时环境的完全相同的程序生成两个字符串（即不存储它）并且您确保单元测试是在禁用优化的情况下构建时，可以推导出浮点一致性问题。
You are not unit-testing the code that needs to be tested!
是的，只有当 class 本身不提供比较对象的方法时，您才会编写此代码。换句话说，它本身不会覆盖 Equals/GetHashCode 并且不会公开比较器。因此，在您的单元测试中测试相等性会执行待测试代码实际上不支持的功能。单元测试永远不应该做的事情，当测试失败时你不能写错误报告。
Counter 参数是因为您需要 来测试相等性来测试class 的另一个特性，比如构造函数或属性 setter。代码中的一个简单注释就足以证明这一点。