Entity Framework vs LINQ to SQL

теперь, что .NET v3.5 SP1 был выпущен (вместе с VS2008 SP1), теперь у нас есть доступ к .NET entity framework.

мой вопрос таков. При попытке выбрать между использованием Entity Framework и LINQ to SQL в качестве ORM, в чем разница?

насколько я понимаю, Entity Framework (при использовании с LINQ to Entities) является "большим братом" для LINQ to SQL? Если это так , то какие преимущества это имеет? Что он может сделать, что LINQ to SQL не может делают по-своему?

17 ответов


LINQ to SQL поддерживает только 1 к 1 сопоставление таблиц базы данных, представлений, sprocs и функций, доступных в Microsoft SQL Server. Это отличный API для быстрого создания доступа к данным для относительно хорошо разработанных баз данных SQL Server. LINQ2SQL был впервые выпущен с C# 3.0 и .Net Framework 3.5.

LINQ для сущностей (ADO.Net Entity Framework) - это API ORM (Object Relational Mapper), который позволяет широко определять модели предметных доменов и их отношения к много разных ADO.Net поставщики данных. Таким образом, вы можете смешивать и сопоставлять несколько различных поставщиков баз данных, серверов приложений или протоколов для разработки агрегированного mash-up объектов, которые построены из различных таблиц, источников, служб и т. д. ADO.Net Framework был выпущен с .Net Framework 3.5 SP1.

Это хорошая вводная статья о MSDN: введение LINQ в реляционные данные


Я думаю, что быстрый и грязный ответ:

  • LINQ to SQL-это быстрый и простой способ сделать это. Это означает, что вы будете идти быстрее, и быстрее, если вы работаете на что-то меньше.
  • Entity Framework-это тотальный, без ограничений способ сделать это. Это означает, что вы будете занимать больше времени, развиваться медленнее и иметь больше гибкости, если вы работаете над чем-то большим.

действительно ли LINQ to SQL мертв? Джонатан Аллен для InfoQ.com

Мэтт Уоррен описывает [LINQ to SQL] как нечто, что "никогда не должно было существовать."По сути, это должен был быть просто дублер, чтобы помочь им разработать LINQ, пока настоящий ORM не будет готов.

...

масштаб Entity Framework заставил его пропустить конечный срок .NET 3.5/Visual Studio 2008. Он был завершен вовремя для несчастливо названного ".NET 3.5 Service Pack 1", который был больше похож на основной выпуск, чем на пакет обновления.

...

разработчикам не нравится [ADO.NET Entity Framework] из-за сложности.

...

начиная с .NET 4.0 LINQ to Entities будет рекомендуемым решением для доступа к данным для LINQ to relational scenarios.


есть ряд очевидных различий, изложенных в этой статье @lars, но короткий ответ:

  • l2s тесно связано-свойство объекта к определенному полю базы данных или более правильно сопоставление объекта с определенной схемой базы данных
  • L2S будет работать только с SQL Server (насколько я знаю)
  • EF позволяет сопоставлять один класс с несколькими таблицами
  • EF будет обрабатывать отношения M-M
  • EF будет иметь способность нацелиться на любую ADO.NET поставщик данных

первоначальная предпосылка была L2S для быстрого развития, и EF для более "предприимчивых" N-уровневых приложений, но это продажа L2S немного короче.


LINQ to SQL

  1. однородный источник данных: SQL Server
  2. рекомендуется для небольших проектов, только там, где структура данных хорошо разработана
  3. отображение может быть изменено без recompilling с помощью sqlmetal.exe
  4. .dbml (язык разметки базы данных)
  5. сопоставление один к одному между таблицами и классами
  6. поддерживает TPH наследование
  7. не поддерживает сложные типы
  8. хранение-во-первых подходи!--4-->
  9. база данных-центральный вид базы данных
  10. создано командой C#
  11. поддерживается, но не дальнейшие усовершенствования, предназначенные

Entity Framework

  1. Heterogeneus источник: поддержка многих поставщиков данных
  2. рекомендуется для всех новых проектов, кроме:
    • маленькие (LINQ to SQL)
    • когда источником данных является плоский файл (ADO.NET)
  3. отображение может быть изменено без перекомпиляции при настройке модели и отображения файлов метаданных артефакта процесс копирования в выходной каталог
  4. .edmx (модель данных сущности), которая содержит:
    • SSDL (язык определения схемы хранения)
    • язык (язык csdl)
    • MSL (язык спецификации отображения)
  5. один-к-одному, один-ко-многим, многие-к-одному сопоставления между таблицами и классами
  6. поддерживает наследованию:
    • TPH (таблица на иерархию)
    • TPT (таблица для каждого типа)
    • TPC (таблица на конкретный класс)
  7. поддерживает сложные типы
  8. код-во-первых, модель, во-первых, для хранения-первых подходах
  9. Application-центральный вид базы данных
  10. создано командой SQL Server
  11. будущее данных Microsoft Апис

Читайте также:


мой опыт работы с Entity Framework был менее чем звездным. Во-первых, вы должны наследовать от базовых классов EF, поэтому попрощайтесь с POCOs. Ваш дизайн должен быть вокруг EF. С LinqtoSQL я мог бы использовать существующие бизнес-объекты. Кроме того, нет ленивой загрузки, вы должны реализовать это самостоятельно. Есть некоторые работы, чтобы использовать POCOs и ленивую загрузку, но они существуют IMHO, потому что EF еще не готов. Я планирую вернуться к нему после 4.0


Я нашел очень хороший ответ здесь что объясняет, Когда использовать то, что простыми словами:

основное эмпирическое правило для какой структуры использовать, как планировать на редактирование данных в слое презентации.

  • Linq-To-Sql - используйте эту структуру, если вы планируете редактировать один к одному взаимосвязь данных в слое презентации. Значит, вы не планируйте комбинировать данные из нескольких таблица в любом представлении или Пейдж.

  • Entity Framework - используйте эту структуру, если вы планируете объединение данных из нескольких таблиц в представлении или страницы. Делать это яснее, вышеуказанные термины специфичны для данных, которые будут манипулируется в представлении или на странице, а не просто отображается. Это важно понять.

с Entity Framework вы можете "объединить" табличные данные вместе представить уровень представления в редактируемой форме, а затем когда эта форма будет отправлена, EF будет знать, как обновить все данные с разных столов.

вероятно, есть более точные причины выбрать EF над L2S, но это, вероятно, будет легче всего понять. L2S не есть возможность объединить данные для представления вида.


мое впечатление, что ваша база данных довольно enourmous или очень плохо спроектирована, если Linq2Sql не соответствует вашим потребностям. У меня есть около 10 веб-сайтов как больших, так и меньших, использующих Linq2Sql. Я смотрел и Entity framework много раз, но я не могу найти вескую причину для использования его над Linq2Sql. Тем не менее, я пытаюсь использовать свои базы данных в качестве модели, поэтому у меня уже есть сопоставление 1 к 1 между моделью и базой данных.

на моей текущей работе у нас есть база данных с 200+ таблиц. Старая база данных с большим количеством плохих решений, чтобы я мог видеть преимущество Entity Framework над Linq2Sql, но все же я предпочел бы перепроектировать базу данных, так как база данных является двигателем приложения, и если база данных плохо спроектирована и медленная, то мое приложение также будет медленным. Использование Entity framework в такой базе данных похоже на quickfix для маскировки плохой модели, но она никогда не сможет скрыть плохую производительность, которую вы получаете от такой базы данных.



ответы здесь охватывали многие различия между Linq2Sql и EF, но есть ключевой момент, которому не уделялось много внимания: Linq2Sql поддерживает только SQL Server, тогда как EF имеет поставщиков для следующих СУБД:

предоставлено Microsoft:

  • ADO.NET драйверы для SQL Server, OBDC и OLE DB

через третьих лиц поставщики:

  • в MySQL
  • Oracle
  • в DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • Жар
  • Npgsql

чтобы назвать несколько.

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

еще одна ситуация, когда эта абстракция полезна, - это когда вы являетесь частью команды разработчиков, которая работает с несколькими различными клиентами или различными бизнес-единицами в организации, и вы хотите повысить производительность разработчиков за счет сокращения числа СУБД они должны быть знакомы с тем, чтобы поддерживать целый ряд различных приложений поверх различных СУБД.


Я обнаружил, что не могу использовать несколько баз данных в одной модели базы данных при использовании EF. Но в linq2sql я мог бы просто префиксировать имена схем с именами баз данных.

Это была одна из причин, по которой я изначально начал работать с linq2sql. Я не знаю, разрешил ли EF эту функциональность, но я помню, что читал, что он был предназначен для того, чтобы не допускать этого.


Если ваша база данных проста и проста, LINQ to SQL будет делать. Если вам нужны логические/абстрактные сущности поверх таблиц, перейдите к Entity Framework.


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

интересно, что случилось с nHibernate или OpenAccess...


Я думаю, что если вам нужно быстро разработать что-то без странных вещей в середине, и вам нужно средство, чтобы иметь объекты, представляющие ваши таблицы:

Linq2Sql может быть хорошим союзником, используя его с LinQ развязывает отличное время разработки.


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

теперь EF эволюционировал, и Linq-to-SQL не хватает основной функции для масштабируемых сервисов, и это поддержка асинхронных операций. У нас есть 100+ запросов в секунду, иногда и несмотря на то, мы оптимизировали наши базы данных, большинство запросы по-прежнему занимают несколько миллисекунд. Из-за синхронных вызовов базы данных поток блокируется и недоступен для других запросов.

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


LINQ to SQL и Entity Framework выглядят аналогично на поверхности. Они оба обеспечивают Запрос LINQ к базе данных с использованием модели данных.

LINQ to SQL развился из проекта LINQ, который вышел из команды, работающей с развитие языка.В то время как Entity Framework был проектом группы программируемости данных и был сосредоточен на языке Entity SQL. Microsoft не имеет никакого намерения понижать LINQ до SQL.

LINQ to SQL по-прежнему является частью ADO.NET в то время как Entity framework имеет отдельный API. Entity framework-это более высокая версия LINQ to SQL.Entity framework использует модель данных сущности для наведения мостов между приложением и хранилищем данных. Это модель данных сущности или EDM, которая предоставляет определение вашей концептуальной схемы, а также информацию о схеме базы данных, необходимую для взаимодействия с базой данных и, наконец, схему сопоставления, которая связывается с двумя.

вот некоторые задачи, выполняемые Entity Framework(Entity модель данных.)

* автоматически генерирует классы из модели и обновляет эти классы динамически при каждом изменении модели.

• заботится обо всех подключениях к базе данных, чтобы разработчики не были обременены необходимостью писать много кода для взаимодействия с базой данных.

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

• обеспечивает механизм отслеживания изменений объектов модели по мере их изменения используются в приложениях и обрабатывает обновления базы данных.


Linq-to-SQL

это поставщик, он поддерживает только SQL Server. Это технология сопоставления таблиц базы данных SQL Server с объектами .NET. Является первой попыткой Microsoft в ORM-объектно-реляционном Сопоставителе.

Linq-to-Entities

та же идея, но с использованием Entity Framework в фоновом режиме, как ORM-снова от Microsoft, он поддерживает несколько основных преимуществ базы данных entity framework разработчик может работать на любой базе данных нет необходимости изучать синтаксис для выполнения любой операции на разных базах данных

согласно моему личному опыту Ef лучше (если вы понятия не имеете о SQL) производительность в LINQ немного быстрее по сравнению с языком LINQ EF reason, написанным на лямбда.