为什么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之间缺乏统一性。如果有一个接口可以统一字段和(未索引的)属性,那就太好了。     

要回复问题请先登录注册