Entity Framework с очень большим и сложным набором данных

Question

Я это очень ценю, если вы можете помочь мне с моими вопросами:

Является EF5 надежным и достаточно эффективным, чтобы иметь дело с очень большим и сложным набором данных в реальном мире?

Сравнивая EF5 с ADO.NET, требуется ли EF5 значительно больше ресурсов, таких как память?

Для тех, кто пробовал EF5 в проекте реального мира с очень большим и сложным набором данных, доволен ли вы показом?

Answer 1

Поскольку EF создает абстракцию по доступу к данным. Использование EF вводит количество дополнительных шагов для выполнения любого запроса. Но есть обходные пути для снижения стоимости. Поскольку MS продвигает этот ORM, я считаю, что они делают много для улучшения производительности. EF 6 beta уже вышел. Для этого есть хорошая статья о производительности EF5, доступной на MSDN.

http://msdn.microsoft.com/en-us/data/hh949853

Я не буду использовать EF, если много сложных манипуляций и итераций требуется на DBsets после заселения DBSets из запроса EF.

Надеюсь, это поможет.

Answer 2

EF более чем способен обрабатывать большие объемы данных. Как и в обычном ADO.NET, вам нужно понять, как правильно его использовать. Его так же легко написать код в ADO.NET, который работает плохо. Также важно помнить, что EF построен поверх ADO.NET.

DBSets будет намного медленнее с большими объемами данных, чем первый подход EF кода. Обычные Datareaders могут быть быстрее, если все сделано правильно.

Правильный ответ - это профиль. Кодируйте некоторые большие объекты и проведите разницу.

Answer 3

Я провел некоторое исследование этого вопроса на EF 4.1, и некоторые детали могут по-прежнему применяться, несмотря на то, что в EF5 были улучшены характеристики производительности.

ADO vs EF performance

Мои выводы: -Вы не будет соответствовать производительности ADO с каркасом, который должен генерировать фактическое заявление SQL динамически из C# и превратить это SQL заявление в строго типизированный объект, есть просто слишком много продолжается, даже с предварительно скомпилированными и «разогретыми» заявлениями (и тесты производительности завершают это). Это счастливый компромисс для многих, кому гораздо проще писать и поддерживать Linq на C#, чем хранить код procs и mapping.

-Вы можете использовать хранимые процедуры с равной производительностью для ADO, для меня это идеальная ситуация. Вы можете написать linq для sql в ситуациях, когда он работает, и как только вы захотите увеличить производительность, напишите sproc и импортируйте его в EF, чтобы получить наилучшую производительность.

-Это техническая причина, по которой EF не принимает требования вашего проекта и, возможно, знания вашей команды и уровень комфорта. Обязательно убедитесь, что он соответствует выбранному шаблону дизайна. EF Anti Patterns to avoid

Надеюсь, это поможет.