Чем отличается .net Entity Framework от LinqToSql?
Я слышал, что там говорилось, что 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 to 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.
Ответы 6
Мой ответ: сделайте простое сравнение времени, затраченного на выполнение простой последовательности Get / Edit / Update. Я думаю, вы обнаружите, что LINQ to SQL работает вдвое быстрее. Я сделал небольшое сравнение, когда исследовал различия. Результаты где: Entity Framework 8700 миллисекунд LINQ to SQL 3100 миллисекунд Наборы данных 2000 миллисекунд
Так что для меня это был простой вопрос. Используйте DataSets или используйте Linq-Sql - Entity Framework даже не учитывала это!
DataSets? Ух ... Есть много других фреймворков (например, Subsonic, NHibernate и т. д.). Не говоря уже о кастомной разработке, которую я все еще часто предпочитаю. Я никогда не встречал проекта, в котором использовались бы DataSets, которые я считал даже удаленно чистыми.
Помимо теста производительности, вы также должны посмотреть, сколько времени и усилий вам нужно, чтобы заставить любую структуру делать то, что вы хотите. Как указал сенфо, DataSets могут быть быстрыми, но на самом деле с ними не так уж и хорошо работать.
Поправьте меня, если я ошибаюсь, но структура сущности должна вступать в игру только тогда, когда вам нужно преобразовать внутренние объекты, например, когда вы объединяете таблицы из разных источников данных, разделяете таблицы и т. д. Он добавляет слой сущности так что вы можете спрятать всю сантехнику и просто заняться своими очищенными объектами. Если вы просто используете его 1 к 1 для своих таблиц, как в LINQ to SQL, то я уверен, что этот уровень сложности, который вы не используете, замедлит его. Похоже, LINQ to SQL - это правильный инструмент для правильной работы в вашем случае, пока у вас не возникнут более сложные потребности в источниках данных.
Прежде чем погрузиться в Linq To SQL, ознакомьтесь с эта статья его программным менеджером. Он задает простой вопрос: «Неужели LINQ to SQL мертв?» Ответ не такой однозначный. Это определенно не «нет». Для меня это больше похоже на «возможно, может быть».
Я бы посоветовал, прежде чем погрузиться в EF (теперь называемый Linq To Entities), вы серьезно относитесь к NHibernate, но это мое личное предубеждение.
Я не использовал NHibernate, но моему бывшему коллеге пришлось переключиться с Linq-to-SQL на NHibernate у своего нового работодателя, и он это ненавидит. По его мнению, NHibernate гораздо менее мощный.
Одно дело сказать, что NHibernate намного менее мощный. Другое дело - привести примеры того, почему. По моему опыту, большинство людей, которым не нравится NHibernate, позже меняют свое мнение, узнав о нем больше.
Linq to SQL и Entity Framework - концептуально разные звери, и вы должны делать свой выбор, основываясь на том, насколько они соответствуют вашим потребностям, а не на микротестах. Даже если Entity Framework была медленнее, она находится в центре внимания команды ADO.NET в Microsoft и будет многократно улучшена. Linq-to-SQL фактически заморожен.
Концептуально они отличаются тем, что Linq-to-SQL - это просто способ выполнения запросов к базе данных с использованием Linq. Звучит достаточно очевидно, но суть в следующем: вы получаете доступ к данным, структурированным в соответствии с моделью базы данных. Хотя FK преобразованы надлежащим образом, у вас все еще есть лишние объекты, где данные были нормализованы в разные таблицы. Каждый запрос, который вы пишете, должен иметь дело с подобными вещами.
Entity Framework позволяет вам декларативно создать слой, который представляет ваши данные так, как они должны быть представлены в памяти, объединяя данные из нескольких таблиц в один объект, где approriate; представление отношений «многие ко многим» в виде свойств коллекции и т. д. И запросы, которые вы напишете, будут относиться к этой модели и будут намного чище и понятнее по назначению (не более 15 объединений таблиц!).
У О'Рейли есть исчерпывающая книга, выходящая Entity Framework 15 января 2009 г. (предварительная версия доступна на Roughcuts), если вы не уверены в использовании Entity Framework - документация MSDN для нее на данный момент в значительной степени отстой, что делает ее предложение еще сложнее. . Я действительно считаю, что его стоит использовать в долгосрочной перспективе для всех проектов, кроме самых тривиальных (и лично, если бы я писал что-то тривиальное, я бы просто использовал ADO.NET2 напрямую и забыл о Linq).
Однако будьте осторожны, LinqToEntities может делать некоторые действительно интересные вещи, если вы используете запросы, например, с group by. Мне никогда не удавалось заставить LinqToEntities преобразовать группу с помощью в фактическую группу SQL с помощью, вместо этого он генерирует несколько массивных блоков кода, которые могут быть действительно неэффективными.
Например, перейдите по следующей ссылке: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68
Если вы пытаетесь написать «нетривиальные» запросы, ObjectQuery.ToTraceString () - ваш лучший друг, чтобы убедиться, что EF не делает что-то действительно глупое за вашей спиной.
Почему бы просто не выполнить обычный SQL-запрос с помощью SqlDataReader и привязать их к универсальному списку. Кажется, что SQL намного более гибкий и мощный, чем любой ORM. В любом случае на практике !! SQL мертв? И это должен быть самый быстрый подход, и обратная сторона - строки sql, но вы работаете ближе к металлу и чувствуете, что у вас гораздо больше контроля, чем при использовании любого ORM. Похоже, что в ORM: s всегда есть какая-то ошибка, что делает более сложные запросы головной болью и требует намного больше времени для написания, чем если бы вы выполняли их на простом SQL. Или это только я новичок в ORM: s?
«обратная сторона - строки sql» ... вот почему вы должны использовать хранимую процедуру вместо генерации этих строк!
SQL не мертв, и при правильном написании он может очень быстро выполнять очень сложные задачи. Но SQL - это язык доступа к базам данных низкого уровня. Это почти что-то вроде инструкции по сборке процессора. У него есть вариации, зависящие от поставщика, для повышения производительности, для достижения которых вам необходимо глубокое знание внутренних компонентов, и в нем нет концепции более высоких концепций, таких как наследование. Но современные программисты пишут свои программы на языках высокого уровня, таких как C#. Почему вам нужно перейти к использованию низкоуровневого набора инструкций? Доступ к нему как к объектам, как и ко всему остальному.
Но не поймите меня неправильно, я люблю SQL. Это интересный язык для решения проблем, и вы можете делать с данными то, что просто невозможно сделать на любом другом языке.
Некоторое время назад этот вопрос был задан. Я пришел к выводу, что некоторые из существующих решений ORM - LINQ2SQL, Entity и NHibernate. Но, работая со сложными операциями с базами данных, я думаю, что со временем вам понадобится написать какой-нибудь sql. А при работе с устаревшими приложениями, где существующая кодовая база в значительной степени состоит из хранимых процедур, вам также необходимо написать некоторый sql. И знание sql по-прежнему важно знать, вам нужно знать, что происходит под капотом. Но я не согласен, что это слишком низкий уровень - вроде как сборка.
Он по-прежнему использует те же сущности, что, например, в объектно-ориентированных языках. имя - это столбец или в C# свойство. Так что для этого он работает на том же уровне детализации, но по-другому. SQL основан на наборах, тогда как C# - это язык итеративного программирования. Он другой, и у него разные сильные и слабые стороны.
Я наконец добрался до теста и был удивлен противоположным образом. Я понятия не имею, действителен ли мой тест, но сначала я удаляю 1000 записей, добавляю 1000 записей, редактирую 1000 записей, а затем привязываю их к DataView. LinqToSQL: 5 секунд LinqToEntities: 2 секунды