Почему LinqPad создает поля вместо свойств?

Question

Недавно я приступил к проекту создания инструмента для LinqPad, который бы выводил результаты запросов в формат CSV, чтобы использовать этот инструмент для больших баз данных для быстрых результатов. Единственное, чего я хотел от этого инструмента, это чтобы он работал в Visual Studio и LinqPad. Таким образом, если бы я использовал LinqtoSQL в VS2010 или LinqPad, я мог бы быстро вывести результаты в файл csv, а затем открыть его в Excel для просмотра результатов.

Самый большой сбой в проекте связан с тем, как LinqPad создает свои DataContexts, а не с тем, как Visual Studio создает их DataContexts. Лучшая информация о том, как LinqPad делает это, - здесь . В основном то, что я обнаружил в своем проекте, было то, что VS2010 создает свойства для их DataContexts, но 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 использует Fields вместо Properties в своих DataContexts? Разве не было бы более целесообразным скопировать шаблон Visual Studio LinqToSQL?

Обновление

На основании комментария я решил задать тот же вопрос и на форуме LinqPad .

Answer 1

Это хороший вопрос. Основная причина того, что LINQPad использует поля для сопоставления столбцов, заключается в производительности при создании типизированного DataContext, который поддерживает запросы к базе данных.

Мы не говорим о скорости выполнения самих свойств (на самом деле очень мало накладных расходов при выполнении простых методов доступа, и JIT может даже их встроить.) Это накладные расходы при создании типизированного DataContext через Reflection.Emit. Поле просто так: один элемент метаданных, в то время как свойство требует передачи определения поля, определения свойства, двух методов для методов доступа (каждый с IL для получения / установки базового поля). Поскольку пользователи могут указывать LINQPad на базы данных с более чем 1000 таблицами и функциями, это может увеличивать время, необходимое для сборки сборки, а также ее размер (увеличение активности жесткого диска и рабочего набора).

Вы подняли интересную проблему в связи с отсутствием объединения PropertyInfo и FieldInfo в объектной модели отражения. Было бы неплохо, если бы существовал интерфейс, объединяющий поля и (неиндексированные) свойства.