为什么 LinqPad 创建字段而不是属性？

Question

我最近承担了一个项目，创建了一个工具，用于将查询结果转储为CSV格式，以便在大型数据库上使用该工具快速获得结果。我希望这个工具能够在Visual Studio和LinqPad中使用。因此，如果我在VS2010或LinqPad中使用LinqtoSQL，我可以快速将结果转储到csv文件中，然后打开它以查看结果。

该项目最大的问题来自于LinqPad如何构建他们的DataContexts与Visual Studio如何构建他们的DataContexts之间的差异。我能找到的有关LinqPad如何构建DataContexts的最好信息来自here。基本上，从我的项目中发现，VS2010为他们的DataContexts创建属性，而LinqPad则创建字段。因此，在使用反射时：

LinqPad:

dataContextType.GetProperties() //returns 0
dataContextType.GetFields() //returns the Fields from LinqPad created DataContext

VS 2010 LinqToSQL：

dataContextType.GetProperties() //returns the Properties from VS created DataContext
dataContextType.GetFields() //returns 0

为什么LinqPad在其DataContexts中使用Fields而不是Properties？复制Visual Studio LinqToSQL模式是否更可行？

更新

基于评论，我决定在LinqPad论坛中提出同样的问题。

- jsmith

---

这个问题不应该直接向 LinqPad 的作者提出吗？无论如何，FieldInfo 和 PropertyInfo 都继承自 MemberInfo，因此您可以重写代码以处理这两种情况（稍加调整即可）。 - Jonas

@Jonas 这对于 StackOverFlow 来说仍然是有用的信息。虽然它们都继承自 MemberInfo，但它们都有不同的 GetValue() 方法，我必须同时利用它们。 - jsmith

Answer 1

这是一个很好的问题。LINQPad使用字段映射列的主要原因是在构建支持与数据库连接的查询的类型化DataContext时提高性能。

我们不是在谈论执行属性本身的速度（实际上在执行简单访问器时几乎没有开销，JIT甚至可以将它们内联）。开销在于通过Reflection.Emit构建类型化DataContext时。字段只是一项元数据，而属性需要发出字段定义、属性定义以及两个用于访问器的方法（每个方法都有用于获取/设置基础字段的IL）。由于用户可能将LINQPad指向具有1000个以上表和函数的数据库，这可能会增加构建程序集所需的时间以及其大小（增加HDD活动和工作集）。

您提出了一个有趣的问题，即反射对象模型中PropertyInfo和FieldInfo之间缺乏统一。如果有一个接口统一了字段和（非索引）属性，那就太好了。

- Joe Albahari

---

谢谢！是的，我也不高兴看到这两个类之间缺乏统一。 - jsmith