Entity Framework проти LINQ в SQL

828

Тепер, коли випущено .NET v3.5 SP1 (разом з VS2008 SP1), ми тепер маємо доступ до структури NET.

Моє запитання таке. Коли ви намагаєтеся вирішити між використанням Entity Framework та LINQ для SQL як ORM, у чому різниця?

Як я це розумію, Entity Framework (коли використовується з LINQ для Entities) є «старшим братом» для LINQ до SQL? Якщо це так - які переваги він має? Що можна зробити, щоб LINQ до SQL не міг зробити самостійно?

.net entity-framework linq-to-sql

— Кріс Робертс
джерело

138

Я вважаю, що відповіді нижче слід переглянути, тому що з моменту виходу EF вже не минуло, тож нові розробники, які потраплять сюди, можуть отримати неправильне враження. EF став великим та легким інструментом з моменту його раннього випуску. Ви просто встановите підключення до БД, і це начебто 90% всього, що вам потрібно. Дуже швидкий розвиток, з досвідченої точки зору! Звідти - LINQ - ваш найкращий друг. Це дуже настроюється, MVC просто любить це, а людям, які кажуть, що це погано - навчіться користуватися ним першим (і влаштуйтеся на LINQ також)!

— graumanoz

10

Просто так зрозуміло - це не так, як у вас зараз вибір - MSFT ефективно знищив LINQ2SQL на користь EF. Однак той факт, що MSFT з відкритими джерелами, допоміг їй менше смоктати і, безумовно, покращується. Але для тих, хто потрапляє на EF - не забудьте зрозуміти, що в EF є ще багато химерностей. Я відправив про одне - stackoverflow.com/questions/305092 / ...

— nikib3ro

4

@ kape123, (a) LINQ для SQL не є "мертвим"; він все ще може бути використаний; (b) LINQ to SQL - стандартний метод доступу до даних у розробці Windows Phone 8.

— Райан Лунді

9

@ user3308043, [потрібне цитування].

— Райан Лунді

3

@Kyralessa - Станом на 2010 рік (з випуском .NET4.0, останнього цитування, яке я міг знайти), MS визнала, що , хоча деякі інвестиції можуть бути здійснені в LINQ2SQL, "основна частина наших загальних інвестицій припаде на цілі Рамка ".

— kmote

483

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

LINQ to Entities (ADO.Net Entity Framework) - API ORM (Object Relational Mapper), який дозволяє широко визначити моделі об'єктних доменів та їх зв’язки з багатьма різними постачальниками даних ADO.Net. Таким чином, ви можете змішати і співставити декілька різних постачальників баз даних, серверів прикладних програм або протоколів, щоб спроектувати агреговану мешанку об'єктів, побудованих з різних таблиць, джерел, служб тощо. ADO.Net Framework було випущено за допомогою .Net Framework 3.5 SP1.

Це хороша вступна стаття про MSDN: Введення LINQ до реляційних даних

— Кріс
джерело

виглядає так, що ви використовуєте LINQ для SQL для запиту в EF

— PositiveGuy

11

@CoffeeAddict, хоча вони дуже схожі за стилем, використовуючи лямбди LINQ, кожен API має абсолютно різні основи. Наприклад, спосіб LINQ2SQL генерує запити SQL дозволяє використовувати функції SQL, тоді як L2E цього не має, або, принаймні, не станом на 2008 рік.

— Кріс,

2

Об'єктно-орієнтований підхід робить його дуже простим та зручним у використанні, його можна кодувати дуже швидко, управляти. Для мене просто найкращий спосіб отримати доступ до даних.

— Антуан Пелтьє,

10

Ця відповідь застаріла. Тепер Linq to SQL підтримує one2many mapping

— Джордж Ланець

201

Я думаю, що швидка і брудна відповідь полягає в тому

LINQ to SQL - це швидкий і простий спосіб зробити це. Це означає, що ви станете швидше і швидше будете працювати, якщо працюєте над чимось меншим.
Entity Framework - це всебічний, неприйнятний для цього спосіб. Це означає, що ви займете більше часу вперед, будете розвиватися повільніше та матимете більшу гнучкість, якщо працюєте над чимось більшим.

— Бред Туттеров
джерело

32

Ви також схильні писати менше рядків коду з L2S, щоб виконати те саме, що і в EF. Без ледачого завантаження в EF означає, що ви завжди перевіряєте, чи щось було завантажено чи ні.

— Пол Мендоса

Бред, що б ти запропонував для сайту електронної комерції? Я маю на увазі, що я не бачу нічого, крім простих CRUD, що там відбуваються ...

— PositiveGuy

2

@CoffeeAddict очевидно, що в топ-3 найбільш проголосованих відповідей говориться про L2S для простого CRUD

— IsmailS

11

@Banford З EF в .NET 4.0 Я думаю, що це краще, ніж L2S. Особливості, які були відсутні у EF у 3.5, що L2S були додані до EF у .NET 4.0. Ваші заяви LINQ зараз у EF в .NET 4.0 виглядатимуть приблизно так само, як і в L2S. EF надає вам кілька додаткових речей, які ви можете зробити зараз, крім того, що пропонує L2S.

— Пол Мендоса

40

Зараз ця відповідь 5 років і досить застаріла. Entity Framework 6 зараз знаходиться в бета-версії і значно вдосконалюється, включає ледачу завантаження, підтримку перерахунків тощо, тощо.

— Тім

109

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

Метт Уоррен описує [LINQ to SQL] як те, що "навіть ніколи не мало існувати". По суті, це було просто готовим, щоб допомогти їм розвивати LINQ до тих пір, поки справжня ОРМ не буде готова.

...

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

...

Розробники не люблять [ADO.NET Entity Framework] через складність.

...

станом на .NET 4.0, LINQ для сутностей буде рекомендованим рішенням доступу до даних для LINQ до реляційних сценаріїв.

— Зак Петерсон
джерело

56

Насправді, нам не подобається EF, тому що він настільки поганий дизайнер і такий надзвичайно, надзвичайно глючно. Я ніколи не виявив, що це все так складно.

— BlueRaja - Danny Pflughoeft

12

Багато основних сайтів електронної комерції використовують LINQ для SQL. Приклади: Redbox, Stackoverflow тощо

— PositiveGuy

14

Я знаю багато хороших розробників, які використовують LINQ для SQL і кажуть, що ці статті повністю перекриті. Я згоден. LINQ до SQL використовується в потужних .coms і досі є.

— PositiveGuy

4

Так, виклик .ToString () на ціле властивість у запиті L2EF не повинен викликати виняток.

— StingyJack

3

@ BlueRaja-DannyPflughoeft Це все-таки правда після більш ніж 5 років?

— Вікас Рана

94

У цій статті @lars розміщено ряд очевидних відмінностей, але коротка відповідь:

L2S щільно пов'язаний - властивість об'єкта до конкретного поля бази даних або, більш правильно, відображення об'єкта на конкретну схему бази даних
L2S буде працювати тільки з SQL Server (наскільки я знаю)
EF дозволяє зіставити один клас на кілька таблиць
EF буде працювати з зв'язками MM
EF матиме змогу націлювати будь-якого постачальника даних ADO.NET

Початковою умовою було те, що L2S призначений для швидкого розвитку, а EF для більш "підприємливих" n-ярусних додатків, але це продаж L2S трохи коротше.

— Джеймс Сагрю
джерело

13

Ваша цитата "L2S буде працювати лише з SQL Server (наскільки я знаю)" потребує оновлення: проект з відкритим кодом "dblinq" замінює збірку LINQ на SQL на той, який може спілкуватися з MySQL, PostgreSQL, Ingres, Firebird, SQLite. .. та Microsoft SQL (звичайно).

— Контанго

1

зачекайте ... значить EF не створює щільно зв'язаних об'єктів DL?

— PositiveGuy

7

Так, первісна передумова, що L2S не є рішенням, здатним до підприємництва, вже не відповідає дійсності. Я маю на увазі, що StackOverflow працює на L2S та купі інших .coms, таких як Redbox, та багато іншого.

— PositiveGuy

74

LINQ в SQL

Однорідний джерело даних: SQL Server
Рекомендується для невеликих проектів лише там, де структура даних добре розроблена
Картографування можна змінити без повторної поповнення за допомогою SqlMetal.exe
.dbml (мова розмітки бази даних)
Повторне відображення між таблицями та класами
Підтримує спадкування ТПГ
Не підтримує складні типи
Підхід до зберігання
Перегляд бази даних, орієнтований на базу даних
Створено командою C #
Підтримуються, але не передбачаються подальші вдосконалення

Entity Framework

Гетерогенний джерело даних: Підтримка багатьох постачальників даних
Рекомендується для всіх нових проектів, крім:
- малі (LINQ до SQL)
- коли джерелом даних є плоский файл (ADO.NET)
Картографування може бути змінено без повторної повторної поповнення під час встановлення моделі та відображення файлів Артефакт метаданих процес для копіювання у вихідний каталог
.edmx (модель даних об'єктів), яка містить:
- SSDL (Мова визначення схеми зберігання)
- CSDL (Мова визначення концептуальної схеми)
- MSL (Мова специфікації картографії)
Відображення «один на один», «один на багато», «багато на один» між таблицями та класами
Підтримує успадкування:
- TPH (Таблиця за ієрархією)
- TPT (таблиця на тип)
- TPC (таблиця на клас бетону)
Підтримує складні типи
Код-перший, Модель-перший, Зберігання-підходи
Вигляд бази даних, орієнтований на додаток
Створено командою SQL Server
Майбутнє API даних Microsoft

Дивись також:

— Рішард Джеган
джерело

6

Це найбільш актуальна і детальна відповідь.

— ErTR

2

Чи не використовує Entity Framework LINQ для SQL, коли, скажімо, ви пишете dbSet<Orders>.Where()...ToList()? Я думаю, що Entity Framework протилежний LINQ до SQL, оманливо.

— Дон Чідл

4

@mmcrae EF не використовує L2S, обидва є постачальниками linq для базових баз даних. Якщо ви інтерпретуєте це як база даних Linq до бази даних, схожа на linq-to-object та linq-to-xml, то так, обидва подібні у linq-to-a-database. Але ні, EF не використовує L2S (або навпаки). Два повністю відокремлені інструменти.

— Маартен

4

"Рекомендується для всіх нових проектів, крім ... малих" Я не погоджуюся. Code First - це надзвичайно швидкий спосіб досягти нових проектів. Крім цього, велике оновлення цього питання.

— DrewJordan

51

Мій досвід роботи з Entity Framework був менш зоряним. По-перше, вам належить успадкувати базові класи EF, тому попрощайтеся з POCO. Ваша конструкція повинна бути навколо EF. З LinqtoSQL я міг би використовувати свої існуючі бізнес-об’єкти. Крім того, немає ледачого завантаження, ви повинні це здійснити самостійно. Існує деяка робота з використання POCO та ледачого завантаження, але вони існують IMHO, оскільки EF ще не готовий. Планую повернутися до нього після 4.0

— Jiyosub
джерело

7

Відсутність підтримки POCO є причиною номер один, що я вибирав LINQ для SQL через Entity Framework. Я можу переглянути EF, коли вони включать його в наступній версії, як вони обіцяють. Є кілька додаткових проектів, які роблять POCO для EF, але недостатньо чисто.

— Джозеф Ферріс

27

Якщо хтось (як я) не знає, що означає POCO: Plain Old CLR Object

— CBono

4

Я дійсно не бачу, в чому полягає велика метушня щодо непідтримки POCO ... це ще один рівень абстракції. Створіть фабрику, вставте сховище даних і побудуйте там свої POCO. Мабуть, це все-таки гарна ідея.

— EightyOne Unite

3

Я чую, що POCO можливий в EF 4

— PositiveGuy

8

Підтримка POCO недоступна в ці дні і успадкування більше не є обов'язковим вимога для класів сутностей @CoffeeAddict спокою тільки простий об'єкт, без опори на конкретні рамках і є важливою частиною сучасних каркасної суті моделей

— Chris McGrath

46

Я знайшов дуже хороший відповідь тут , який пояснює , коли використовувати то , що в простих словах:

Основне правило, яку рамку потрібно використовувати, - це планування редагування даних у вашому презентаційному шарі.

Linq-To-Sql - використовуйте цей фреймворк, якщо плануєте редагувати взаємозв'язок своїх даних у вашому презентаційному шарі. Це означає, що ви не плануєте поєднувати дані з декількох таблиць у будь-якому одному перегляді чи сторінці.

Entity Framework - використовуйте цей фреймворк, якщо плануєте поєднувати дані з декількох таблиць у вашому перегляді чи на сторінці. Щоб зробити це зрозумілішим, наведені вище умови стосуються даних, які будуть маніпулювати у вашому перегляді чи сторінці, а не просто відображатися. Це важливо для розуміння.

За допомогою Entity Framework ви зможете "об'єднати" складені дані разом, щоб представити шару презентації у редагованій формі, і тоді, коли ця форма буде подана, EF дізнається, як оновити ВСІ дані з різних таблиць.

Можливо, є більш точні причини вибору EF над L2S, але це, мабуть, було найпростішим для розуміння. L2S не має можливості об'єднати дані для подання перегляду.

— Наваз
джерело

36

Моє враження, що ваша база даних є надзвичайно величезною або дуже погано розроблена, якщо Linq2Sql не відповідає вашим потребам. У мене є близько 10 веб-сайтів як більших, так і менших, які використовують Linq2Sql. Я багато разів переглядав і Entity Framework, але не можу знайти вагому причину для використання його над Linq2Sql. Це означає, що я намагаюся використовувати свої бази даних як модель, тому я вже маю 1 до 1 зіставлення між моделлю та базою даних.

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

— тержетіл
джерело

1

Ваша упущена справа - навіть при невеликих базах даних вам може знадобитися щось інше, ніж співвідношення 1: 1 між таблицями бази даних та об'єктами коду / домену. Просто залежить від того, яку кількість абстракцій потрібно в об'єктах шини / домену.

— алхімічна

18

Я зрозумів це :) Сьогодні я люблю вводити коди своїх суб’єктів господарювання. Я все ще використовую Linq2sql, але тільки всередині моїх сховищ, де я отримую дані за допомогою Linq2sql і перетворюю об'єкти linq2sql в мої власні суб'єкти господарювання. Можливо, трохи більше роботи, ніж використання маркера or-mapper, але все ж я люблю захищати свій бізнес-шар від будь-якого коду, специфічного для OR або mapper.

— terjetyl

25

Ви можете знайти хороше порівняння тут:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-bet between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

— Омер К
джерело

2

Деякі речі у відповіді невірні. EDMX не потрібен, якщо ви використовуєте Code First. І я не розумію, як DI вступає в гру, коли ви використовуєте Code First.

— Маартен

1

Крім того, Linq до SQL може добре заповнити БД з класів моделі. Не впевнений, чи може він також генерувати БД, але генерування схеми та таблиць підпадає під Linq до можливостей SQL.

— Том Лінт

Дякую за відповідь, я думаю, що хтось може використовувати sqlmetal.exe docs.microsoft.com/en-us/dotnet/framework/tools/… для генерування коду / відображення з бази даних при використанніLinq to SQL

— Srivastav

23

Відповіді тут охопили багато відмінностей між Linq2Sql та EF, але є ключовий момент, якому не приділяли великої уваги: Linq2Sql підтримує лише SQL Server, тоді як EF має провайдерів для таких RDBMS:

Надано Microsoft:

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

Через сторонніх постачальників:

MySQL
Oracle
DB2
VistaDB
SQLite
PostgreSQL
Інформукс
U2
Sybase
Синергекс
Жар-птиця
Npgsql

назвати декілька.

Це робить EF потужною абстракцією програмування над вашим реляційним сховищем даних, тобто розробники мають послідовну модель програмування, з якою можна працювати, незалежно від базового сховища даних. Це може бути дуже корисно в ситуаціях, коли ви розробляєте продукт, який хочете переконатися, що він буде взаємодіяти з широким спектром поширених RDBMS.

Інша ситуація, коли ця абстракція є корисною, це коли ви є частиною команди розробників, яка працює з кількома різними клієнтами або різними бізнес-підрозділами в організації, і ви хочете підвищити продуктивність розробників за рахунок зменшення кількості RDBMS, якими вони повинні стати. знайомий з тим, щоб підтримувати цілий спектр різних додатків поверх різних RDBMS.

— вітрило
джерело

15

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

Це було однією з причин, що я спочатку почав працювати з linq2sql. Я не знаю, чи EF ще дозволив цю функціональність, але я пам’ятаю, що читав, що це було призначено для того, щоб не допустити цього.

— Банфорд
джерело

12

Якщо ваша база даних проста і проста, LINQ для SQL зробить. Якщо вам потрібні логічні / абстраговані об'єкти зверху ваших таблиць, перейдіть до Entity Framework.

— вінтана
джерело

4

Entity Framework дозволяє прошарку абстрагування верхньої частини бази даних. Проблема з багатьма АБО Mappers сьогодні (на мою думку) полягає в тому, що вони пропонують 1 - 1 зіставлення між таблицями та класами. Модель бази даних не завжди відображає те, як ми думаємо про неї з точки зору ділової моделі.

— сенфо

Вибіг місця. Так чи інакше, виходячи з сказаного вище, я б стверджував, що ваша відповідь не є повною.

— сенфо

7

Я думаю, що це дійсно погана порада. L2S хороший незалежно від простоти чи складності вашої бази даних. У справжній пастці немає належного розділення проблем. Якщо ви спробуєте об'єднати рівень свого бізнесу та рівень доступу до даних та використовувати об’єкти Linqed up для всього, тоді ви знайдете обмеження L2S. Але це проблема із надмірно спрощеним та монолітним дизайном. L2S - це великий DAL, і якщо ви вважаєте, що запити та наполегливість є окремою проблемою від правил вашого бізнесу, ви позбавите себе від багатьох проблем у багатьох областях у довгостроковій перспективі.

— mattmc3

1

це мені нічого не говорить. Що просте у ваших термінах?

— PositiveGuy

1

і що ви маєте на увазі як приклад для потреби "логічного / абстрагованого". Так, я знаю, що таке абстракція, але приклад у вашому контексті, будь ласка ... поясніть мені, що саме ви говорите ... опишіть це, не просто дайте мені загальний сленг ... це все відносно того, хто говорить доповідач ці слова, тому я не маю поняття, що ви розумієте під цим.

— PositiveGuy

8

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

Цікаво, що з NHibernate або OpenAccess ...

— Джон Дунаган
джерело

3

Просторові типи даних SQL Server 2008 (Відкритий геопросторовий консорціум OGS) підтримуються в рамках Entity Framework 5. Інші постачальники (Devart for Oracle) також підтримуються. Див. Msdn.microsoft.com/en-us/data/dn194325 .

— subsci

6

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

Linq2Sql може бути хорошим союзником, використовуючи його, коли LinQ відкриває чудові моменти, що розвиваються.

— MRFerocius
джерело

4

"немає дивних речей у середині", добре, що ви розумієте під цим. Приклад "дивної речі посередині"

— PositiveGuy

Було б непогано відредагувати або видалити цю відповідь, вона більше не корисна для сучасного розвитку і може привести людей до неправильного шляху.

— Джуліо Каччін

6

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

Зараз EF розвинулася, і Linq-SQL не вистачає підтримки для асинхронізації, що чудово підходить для високомасштабних сервісів. Іноді у нас є 100+ запитів в секунду, і, незважаючи на те, що ми оптимізували наші бази даних, для більшості запитів все ще потрібно кілька мілісекунд. Через синхронні дзвінки до бази даних, потік блокується та недоступний для інших запитів.

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

Додаток грудень 2018: Microsoft рухається до .NET Core і Linq-2-SQL не підтримує .NET Core, тому вам потрібно перейти до EF, щоб переконатися, що ви зможете перейти до EF.Core в майбутньому.

Існують також деякі інші варіанти, які слід врахувати, наприклад, LLBLGen . Це зріле рішення ORM, яке існує вже давно і було доведено більш надійним у майбутньому, ніж рішення даних MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

— Рамон де Кляйн
джерело

2

Linq-to-SQL

Це постачальник, який підтримує лише SQL Server. Це картографічна технологія для зіставлення таблиць баз даних SQL Server на об’єкти .NET. Це перша спроба Microsoft створити ORM - Object-Relational Mapper.

Linq-to-Entities

Це та сама ідея, але використовуючи Entity Framework у фоновому режимі, як ORM - знову ж таки від Microsoft, це підтримка декількох баз даних. Основна перевага структури фреймворку - розробник може працювати на будь-якій базі даних, не потрібно вивчати синтаксис для виконання будь-яких операцій на різних різних базах даних

Згідно з моїм особистим досвідом, Ef краще (якщо ви не маєте поняття про SQL), продуктивність у LINQ трохи швидша порівняно з мовою EF LINQ, написаною на лямбда.

— Уманг Патва
джерело