linq-to-sql - 为什么 LinqPad 创建字段而不是属性？

Question

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

项目中最大的问题来自 LinqPad 如何构建他们的 DataContexts 与 Visual Studio 如何构建他们的 DataContexts。我能找到的关于 LinqPad 如何做到的最好信息来自 here .基本上我从我的项目中发现，VS2010 为其 DataContext 创建属性，但 LinqPad 创建字段。因此在使用反射时:

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 forum 中提出同样的问题以及。

Answer 1

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

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

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