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

【问题标题】：Why does LinqPad create Fields instead of Properties?为什么 LinqPad 创建字段而不是属性？
【发布时间】：2011-08-05 17:08:54
【问题描述】：

我最近接手了一个为 LinqPad 创建一个工具的项目，该工具会将查询结果转储为 CSV 格式，以便在海量数据库上使用该工具以获得快速结果。我想要使用该工具的一件事是它能够在 Visual Studio 和 LinqPad 中工作。因此，如果我在 VS2010 或 LinqPad 中使用 LinqtoSQL，我可以快速将结果转储到 csv 文件，然后将其打开到 Excel 中查看结果。

项目中最大的问题在于 LinqPad 如何构建其 DataContexts 与 Visual Studio 如何构建其 DataContexts。我能从here 中找到有关 LinqPad 如何工作的最佳信息。基本上我从我的项目中发现，VS2010 为其 DataContexts 创建属性，但 LinqPad 创建 Fields。因此在使用反射时：

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 中使用字段而不是属性？复制 Visual Studio LinqToSQL 模式不是更可行吗？

更新

根据评论，我决定在LinqPad forum 中也提出同样的问题。

【问题讨论】：

不应该发给 LinqPad 的作者吗？ :D 无论如何，FieldInfo 和 PropertyInfo 都继承自 MemberInfo，因此您可以重写代码来处理这两种情况（稍作调整）。
@Jonas 对于 StackOverFlow 来说仍然是很好的信息。虽然它们都继承自 MemberInfo，但它们都有不同的 GetValue() 方法，我必须同时使用它们。

标签： linq-to-sql reflection properties field linqpad

【解决方案1】：

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

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

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

【讨论】：

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