为什么 LinqPad 创建字段而不是属性？
我最近接手了一个项目，为 LinqPad 创建一个工具，它将查询结果转储为 CSV 格式，以便在海量数据库上使用该工具来快速获得结果。我希望该工具能够在 Visual Studio 和 LinqPad 中工作。因此，如果我在 VS2010 中使用 LinqtoSQL 或 LinqPad，我可以将结果快速转储到 csv 文件，然后在 Excel 中打开它以查看结果。
该项目中最大的问题来自 LinqPad 如何构建其 DataContext 与 Visual Studio 如何构建其 DataContext。我能找到的有关 LinqPad 如何实现的最佳信息来自此处。基本上我从我的项目中发现的是，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 论坛 以及。
I recently took on a project of creating a tool for LinqPad that would Dump query results into CSV format in order to use the tool on massive databases for quick results. One thing I wanted out of the tool is for it to be able to work in Visual Studio, and LinqPad. Thus, if I was using LinqtoSQL in VS2010, or LinqPad, I could dump results quickly to a csv file, and then open it up into Excel to view the results.
The biggest hiccup in the project came from how LinqPad builds their DataContexts vs. how Visual Studio builds their DataContexts. The best information I could find on how LinqPad does it comes from here. Basically what I found from my project, was that VS2010 creates properties for their DataContexts, but LinqPad creates Fields. Thus when using reflection:
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
So why does LinqPad use Fields instead of Properties in their DataContexts? Wouldn't it have been more feasible to copy the Visual Studio LinqToSQL pattern?
Update
Based on a comment I decided to ask the same question within the LinqPad forum as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个好问题。 LINQPad 使用字段来映射列的主要原因是为了在构建支持数据库连接查询的类型化 DataContext 时提高性能。
我们不是在谈论执行属性本身的速度（实际上执行简单访问器的开销非常小，JIT 甚至可能内联它们。）开销是通过 Reflection.Emit 构建类型化 DataContext 时的开销。字段很简单：元数据的一项，而属性需要发出字段定义、属性定义、访问器的两种方法（每个方法都带有 IL 来获取/设置底层字段）。由于用户可能将 LINQPad 指向包含超过 1000 个表和函数的数据库，因此这可能会增加构建程序集所需的时间及其大小（增加 HDD 活动和工作集）。
您提出了一个有趣的问题，即反射对象模型中的 PropertyInfo 和 FieldInfo 之间缺乏统一。如果有一个统一字段和（非索引）属性的接口，那就太好了。
This is a good question. The main reason for LINQPad using fields to map columns is for performance when building the typed DataContext that backs database-connected queries.
We're not talking about the speed of executing the properties themselves (there's actually very little overhead in executing simple accessors and the JIT may even inline them.) The overhead is when building the typed DataContext via Reflection.Emit. A field is simply that: one item of metadata, whereas a property requires emitting a field definition, a property definition, two methods for the accessors (each with IL to get/set the underlying field). Because users may point LINQPad to databases with upwards of 1000 tables and functions, this can add up in terms of the time taken to build the assembly - as well as its size (increasing HDD activity and working set).
You have raised an interesting issue in the lack of unification between PropertyInfo and FieldInfo in the reflection object model. It would be nice if there was an interface that unified fields and (non-indexed) properties.