2011-04-14 99 views
5

我最近接手了一個爲LinqPad創建工具的項目,該工具將查詢結果轉儲爲CSV格式,以便在海量數據庫上使用該工具以獲得快速結果。我想要的工具之一就是它能夠在Visual Studio和LinqPad中工作。因此,如果我在VS2010或LinqPad中使用LinqtoSQL,我可以將結果快速轉儲到csv文件,然後將其打開到Excel中以查看結果。爲什麼LinqPad創建字段而不是屬性?

該項目最大的障礙來自於LinqPad如何構建DataContexts與Visual Studio如何構建其DataContexts。我可以找到LinqPad的最佳信息來自here。基本上我從我的項目中發現,VS2010爲其DataContext創建了屬性,但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?複製Visual Studio LinqToSQL模式不是更可行嗎?

更新

基於評論我決定向LinqPad forum內同樣的問題也是如此。

+0

這不應該直接指向LinqPad的作者嗎? :D無論如何,FieldInfo和PropertyInfo都從MemberInfo繼承,所以你可以重寫你的代碼來處理這兩種情況(稍微調整一下)。 – Jonas 2011-04-14 16:48:28

+0

@Jonas它仍然是StackOverFlow的好信息。儘管它們都從MemberInfo繼承,但它們都有不同的GetValue()方法,我必須同時使用這兩種方法。 – jsmith 2011-04-14 16:58:54

回答

5

這是一個很好的問題。 LINQPad使用字段映射列的主要原因是在構建支持與數據庫連接的查詢的類型化DataContext時的性能。

我們不是在談論自己執行屬性的速度(實際上執行簡單訪問器的開銷非常小,JIT甚至可能會內聯它們)。開銷是通過Reflection.Emit構建類型化的DataContext時的開銷。一個字段就是:一個元數據項,而一個屬性需要發出一個字段定義,一個屬性定義,兩個訪問器方法(每個都有IL來獲取/設置底層字段)。由於用戶可能會將LINQPad指向具有超過1000個表格和函數的數據庫,因此這可以增加構建程序集所需的時間以及其大小(增加HDD活動和工作集)。

您在反射對象模型中PropertyInfo和FieldInfo之間缺乏統一性方面引發了一個有趣的問題。如果有一個統一字段和(非索引)屬性的接口,那將會很好。

+0

謝謝!是的,我不高興看到兩個班級之間缺乏統一。 – jsmith 2011-04-15 13:29:46

相關問題