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

如何解决为什么LinqPad创建字段而不是属性？

| 我最近进行了一个为LinqPad创建工具的项目，该工具会将查询结果转储为CSV格式，以便在大型数据库上使用该工具以快速获得结果。我希望该工具提供的一件事是使其能够在Visual Studio和LinqPad中工作。因此，如果我在VS2010或LinqPad中使用Linqtosql，则可以将结果快速转储到csv文件中，然后将其打开到Excel中以查看结果。 该项目最大的麻烦来自LinqPad如何构建其DataContext和Visual Studio如何构建其DataContext。我可以找到有关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在其DataContext中使用字段而不是属性？复制Visual Studio LinqTosql模式不是更可行吗？ 更新资料 基于评论，我决定在LinqPad论坛中也问同样的问题。     

解决方法

这是一个很好的问题。 LINQPad使用字段映射列的主要原因是在构建支持数据库连接查询的类型化DataContext时提高性能。 我们并不是在谈论执行属性本身的速度（实际上，执行简单访问器的开销很小，而JIT甚至可以内联它们。）开销是通过Reflection.Emit构建类型化DataContext时的开销。一个字段就是这样：一个元数据项，而一个属性则需要发出一个字段定义，一个属性定义，两种访问器方法（每个方法都使用IL来获取/设置基础字段）。因为用户可能会将LINQPad指向具有多达1000个表和函数的数据库，所以这可能会增加构建程序集所花费的时间及其大小（增加HDD活动和工作集）。 您已经提出了一个有趣的问题，即反射对象模型中PropertyInfo和FieldInfo之间缺乏统一性。如果有一个接口可以统一字段和（未索引的）属性，那就太好了。