Entity Framework 4 и производительность Poco и Linq2Sql

Question

Я думаю об использовании POCO вместо автоматической генерации сущностей, потому что я не хочу никакой зависимости от фреймворка

Мне было интересно, не скажется ли это на производительности, я не уверенесли необходимость динамически проксировать мои сущности во время выполнения повлияет на производительность,

также мне интересно, будет ли это быстрее, если я просто позволю EF4 сгенерировать модель для меня.

Я забочусь о производительностимного в моем текущем проекте, и я много раз читал о том, что L2S немного быстрее, чем EF2, но я не уверен насчет EF4, поэтому теперь мне интересно, возникнут ли у меня проблемы с производительностью при использовании EF4 вместо Linq2SQL.

Я действительно хочу использовать POCO;вот почему я предпочитаю EF4, но опять же я не хочу иметь проблем с производительностью.

EF4 и Ling2SQL - единственные варианты для меня, потому что я не могу использовать нативный ADO.net или любой другой ORM, поэтому могуПожалуйста, поделитесь своим опытом работы с EF4 и Linq2SQL с точки зрения производительности?

Заранее спасибо.

Answer 1

Если вы действительно беспокоитесь о производительности, взгляните на Dapper.NET.Этот раздел их главной страницы содержит довольно приличное сравнение различных платформ OR, включая LINQ to SQL и Entity Framework.

В общем, POCO - ваш самый быстрый вариант.Dapper поможет вам в этом.

К вашему сведению: Dapper используется StackOverflow, а StackOverflow является удивительно peformant для объема генерируемого трафика.

Answer 2

Недавно команда ADO.NET выпустила EF Power Tools для поддержки первой разработки кода, которая автоматически генерирует POCO из вашей модели / базы данных (только mssql) и может полностью отделить POCO от других мета классов дать информацию о структуре таблиц базы данных.

В блоге команды ADO.NET с использованием EF Proxies упоминается следующим образом

When creating instances of POCO entity types, the Entity Framework often creates instances of a dynamically generated derived type that acts as a proxy for the entity. This proxy overrides some virtual properties of the entity to insert hooks for performing actions automatically when the property is accessed.

Sometimes disabling proxy creation is useful to prevent the Entity Framework from creating proxy instances. For example, serializing non-proxy instances is considerably easier than serializing proxy instances. Proxy creation can be turned off by clearing the ProxyCreationEnabled flag.

Конечно, создание прокси было бы неэффективно, но, как упоминалось выше, оно просто переопределяет некоторые виртуальные свойства для загрузки относительных свойств, так что я думаю, что создание прокси-объектов вместо POCO не является проблемой.

Answer 3

Stacker, пока точно не уверен насчет выступлений, но я бы не стал об этом беспокоиться.

если вы хотите сохранить свои сущности в чистоте (как я), даже если они сгенерированы EF, вы можете использовать мощь частичных классов C # и иметь другой файл (в том же проекте, ваш уровень данных), где вы снова определите сущность как частичную, и где вы указываете, что такая сущность реализует ваш базовый интерфейс.

Таким образом, в другой сборке, называемой CORE или Common или лучше Core.Interfaces ... у вас есть все интерфейсы, определенные на верхних уровнях стека приложений (Business Logic, UI, сервисы и т. Д.), Вы всегда и только запрограммировать эти интерфейсы вместо объектов пространства имен DAL ...

это дает вам большую мощность, потому что как только вы обновляете модель из базы данных и т. Д., Если новые сгенерированные сущности нарушают определенные и общие интерфейсы, вы сразу же получаете ошибку времени компиляции. Обратите внимание, что вам не нужно ничего менять в автоматически сгенерированных файлах для сущностей EF, поскольку вы используете частичные определения классов.

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

Answer 4

Я не заметил огромной разницы между POCO и моделью / базой данных в первую очередь с точки зрения производительности.Я заметил, что EF медленнее, чем Linq2Sql, Massive, PetaPoco, Ado.Net и, возможно, nHibernate.