我最近开展了一个为LinqPad创建工具的项目，该工具可以将查询结果转储为CSV格式，以便在海量数据库上使用该工具以获得快速结果。我想从工具中得到的一件事是它能够在Visual Studio和LinqPad中工作。因此，如果我在VS2010或LinqPad中使用LinqtoSQL，我可以将结果快速转储到csv文件，然后将其打开到Excel中以查看结果。
该项目中最大的问题来自于LinqPad如何构建他们的DataContexts以及Visual Studio如何构建他们的DataContexts。关于LinqPad如何做到的最好的信息来自here。基本上我从我的项目中发现，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中使用Fields而不是Properties？复制Visual Studio LinqToSQL模式不是更可行吗？
更新
根据评论，我决定在LinqPad forum内提出相同的问题。
答案 0 :(得分：5)
这是一个很好的问题。 LINQPad使用字段映射列的主要原因是在构建支持数据库连接查询的类型化DataContext时的性能。
我们不是在谈论执行属性本身的速度（实际上执行简单访问器的开销非常小，而JIT甚至可以内联它们。）开销是通过Reflection.Emit构建类型化的DataContext。字段只是：一个元数据项，而一个属性需要发出一个字段定义，一个属性定义，两个访问器方法（每个方法都有IL来获取/设置底层字段）。因为用户可能会将LINQPad指向具有超过1000个表和函数的数据库，这可能会增加构建程序集所需的时间 - 以及它的大小（增加HDD活动和工作集）。
由于反射对象模型中PropertyInfo和FieldInfo之间缺乏统一，您提出了一个有趣的问题。如果有一个统一字段和（非索引）属性的接口，那就太好了。