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

Question

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

该项目最大的麻烦来自LinqPad如何构建其DataContext和Visual Studio如何构建其DataContext。 我可以找到有关LinqPad如何做的最佳信息来自此处 。 从项目中我发现，基本上是VS2010为它们的DataContext创建属性，而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在其DataContext中使用字段而不是属性？ 复制Visual Studio LinqToSQL模式不是更可行吗？

更新资料

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

Answer 1

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

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

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