Как превалирует инфраструктура Entity Framework .NET с LinqToSql?

Question

Я слышал, что он сказал, что платформа Entity Framework слишком сложна или что ее трудно изучить по сравнению с LinqToSql.

Мне интересно, каким образом? Я использовал LinqToSql и люблю его. Итак, я пытаюсь использовать EF и для того, что я делаю, они кажутся почти такими же. Пространства имен и имена методов различны, но до сих пор я не вижу ничего, что делает EF более сложным, чем LinqToSql.

Я уверен, что если я начну делать больше компромиссных вещей, он становится более сложным. Но опять же я, вероятно, вообще не могу сделать то же самое с LinqToSql, поэтому я вижу это как плюс для EF на всякий случай, если я хочу сделать что-то более сложное.

Использует ли EF больше ресурсов, чем LinqToSql, так что я не должен использовать его, если все, что мне нужно, это функциональность LinqToSql?

Обновление: Я сделал несколько тестов, и мои тесты, похоже, указывают на Linq на Entities, которые лучше, чем Linq to SQL.

Сначала я удаляю 1000 записей из одной таблицы, добавляю 1000 записей, редактирую 1000 записей, а затем привязываю их к DataView. LinqToSQL: 5 секунд LinqToEntities: 2 секунды

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

Мои тесты, кажется, поддерживают другую должность: Linq To Sql vs Entity Framework Performance

Update 2:

Спасибо за ответы. Мне кажется, что Linq to Entities на самом деле не слишком велико по сравнению с Linq to SQL. Изучив больше, я думаю, что идти с Linq to Entities - это путь. Похоже, что он имеет лучшую производительность.

Я считаю, что заявления «overkill», которые я слышал, сделаны из-за того, что Linq to Entities может выполнять гораздо больше, чем Linq To SQL, и для этого требуется больше конфигурации (около 1 строки в файле web.config). Также есть небольшие вещи, которые Linq to Entities делает иначе, чем Linq to SQL, которые могут заставить кого-то почувствовать, что Linq to Entities сложнее. Но как только вы узнаете, как делать вещи, кажется, что Linq для Entities не сложнее Linq для SQL.

Answer 1

Мой ответ: Простой сопоставление времени, затраченного на выполнение простой последовательности «Получить/Редактировать/Обновить». Я думаю, вы обнаружите, что LINQ to SQL в два раза быстрее. Когда я изучал различия, я сделал быстрый проект для сравнения.
Результаты, где: Entity Framework 8,700 миллисекунды LINQ к SQL 3,100 миллисекунды наборов данных 2,000 миллисекунды

Так что для меня это был простой вопрос. Использовать DataSets или использовать Linq-Sql - Entity Framework даже не учитывает его!

link text

Answer 2

Поправьте меня, если я ошибаюсь, но структура организации должна прийти только в игру, когда вам нужно преобразовать фоны объектов, например, когда вы комбинируя таблицы из разных источников данных, расщепление таблицы и т. д. Он добавляет слой сущности, чтобы вы могли скрыть всю сантехнику и просто иметь дело с очищенными сущностями. Если вы просто используете его 1 для 1 против ваших таблиц, как в LINQ to SQL, тогда я уверен, что уровень сложности, который вы не используете, замедлит его. Похоже, что LINQ to SQL является правильным инструментом для правильной работы в вашем случае, пока у вас не будет более сложных потребностей в источнике данных.

Answer 3

Перед тем, как погрузиться в Linq To SQL, ознакомьтесь со своим менеджером программ this article. Он задает простой вопрос: «LINQ to SQL Dead?» Ответ не так прост. Это определенно не «нет». Мне кажется, скорее всего, возможно.

Я бы предложил перед тем, как погрузиться в EF (теперь называемый Linq To Entities), вы серьезно рассматриваете NHibernate, но это мое личное предубеждение.

Answer 4

Linq to SQL и Entity Framework - концептуально разные звери, и вы должны сделать свой выбор в зависимости от того, как они соответствуют вашим потребностям, а не на микрообъектах. Даже если Entity Framework был медленнее, он находится в центре внимания команды ADO.NET в Microsoft и будет многократно улучшаться. Linq-to-SQL эффективно заморожен.

Концептуально они отличаются тем, что Linq-to-SQL - это всего лишь способ выполнения запросов к базе данных с использованием Linq. Звучит достаточно очевидно, но дело в том, что вы получаете доступ к данным, структурированным в соответствии с моделью базы данных. Хотя FKs правильно преобразовываются, у вас все еще есть избыточные объекты, где данные были нормализованы в разные таблицы. Каждый запрос, который вы пишете, должен справляться с такими вещами.

Entity Framework позволяет декларативно конструировать слой, который представляет ваши данные так, как он должен быть представлен в памяти, принося данные из нескольких таблиц в один объект, где approriate; представляя отношения «многие-ко-многим» как свойства коллекции и т. д. И запросы, которые вы пишете, будут для этой модели и будут намного более чистыми и более очевидными по назначению (не более 15 табличных объединений!).

У O'Reilly есть исчерпывающая книга, выходящая из Entity Framework 15-го Januray 2009 (предварительный просмотр доступен сейчас на Roughcuts), если вы не уверены в использовании Entity Framework - документация MSDN для нее в значительной степени сосут в тот момент, который делает предлагая это еще сложнее. Я полагаю, что это стоит использовать в долгосрочной перспективе для всех, кроме самых тривиальных проектов (и лично, если бы я писал что-то тривиальное, я бы просто использовал ADO.NET2 напрямую и забыл о Linq).

Answer 5

Будьте осторожны, LinqToEntities может делать некоторые действительно интересные вещи, если вы используете запросы с - например, группой. Я никогда не получал LinqToEntities, чтобы преобразовать группу в фактическую группу SQL, вместо этого генерирует некоторые массивные блоки кода, которые могут быть действительно неэффективными.

Например, обратите внимание на следующую ссылку: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

Если вы пытаетесь писать «нетривиальные» запросов, ObjectQuery.ToTraceString() является вашим лучшим другом, чтобы убедиться, что EF не делать что-то действительно глупо за твоей спиной.

Answer 6

Почему бы просто выполнить обычный SQL-запрос с SqlDataReader и не связать их с общим списком. Похоже, что SQL намного более гибкий и мощный, чем любой ORM. На практике все равно !! Является ли SQL мертвым? И это должен быть самый быстрый подход, а нижняя сторона - это строки sql, но вы работаете ближе к металлу и чувствуете, что у вас есть намного больше контроля, чем с использованием ORM. Чувствует, что у ORM: у s всегда есть некоторая ошибка и делает более сложные запросы болью в заднице и занимает намного больше времени, чем если бы вы делали их в простом SQL. Или это только я, кто является новым для ORM: s?