Чем отличается .net Entity Framework от LinqToSql?

Question

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

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

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

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

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

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

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

Кажется, мои тесты поддерживают другой пост: Linq To Sql против производительности Entity Framework

Обновление 2:

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

Перед тем как погрузиться в Linq To SQL, прочитайте эту статью ее менеджера программы. Он задает простой вопрос "Является ли LINQ to SQL Dead?" Ответ не так прост. Это определенно не "нет". Звучит для меня больше как «возможно, может быть».

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

Answer 5

Мой ответ: просто сравните время, затраченное на выполнение простой последовательности Get / Edit / Update. Я думаю, вы найдете, что LINQ to SQL в два раза быстрее. Я сделал проект быстрого сравнения, когда исследовал различия.
Результаты где: Entity Framework 8,700 миллисекунд LINQ to SQL 3100 миллисекунд Наборы данных 2000 миллисекунд

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

текст ссылки

Answer 6

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