Entity Framework против LINQ to SQL

В опубликованной статье @lars есть ряд очевидных различий, но краткий ответ:

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

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

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

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

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

LINQ to SQL поддерживает только сопоставление 1: 1 таблиц базы данных, представлений, sprocs и функций, доступных в 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 to SQL мертв?, Джонатан Аллен для InfoQ.com

Matt Warren describes [LINQ to SQL] as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready.

...

The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack.

...

Developers do not like [ADO.NET Entity Framework] because of the complexity.

...

as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.

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

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

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

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

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

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

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

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

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

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

The basic rule of thumb for which framework to use is how to plan on editing your data in your presentation layer.

• Linq-To-Sql - use this framework if you plan on editing a one-to-one relationship of your data in your presentation layer. Meaning you don't plan on combining data from more than one table in any one view or page.

• Entity Framework - use this framework if you plan on combining data from more than one table in your view or page. To make this clearer, the above terms are specific to data that will be manipulated in your view or page, not just displayed. This is important to understand.

With the Entity Framework you are able to "merge" tabled data together to present to the presentation layer in an editable form, and then when that form is submitted, EF will know how to update ALL the data from the various tables.

There are probably more accurate reasons to choose EF over L2S, but this would probably be the easiest one to understand. L2S does not have the capability to merge data for view presentation.

Ответы здесь охватывают многие различия между 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 мощной абстракцией программирования над вашим реляционным хранилищем данных, а это означает, что у разработчиков есть согласованная модель программирования, с которой можно работать независимо от базового хранилища данных. Это может быть очень полезно в ситуациях, когда вы разрабатываете продукт, который, как вы хотите, будет взаимодействовать с широким спектром обычных СУБД.

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

LINQ to SQL

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

Entity Framework

1. Источник данных Heterogenus: Поддержка многих поставщиков данных
2. Рекомендуется для всех новых проектов, кроме:
   • маленькие (LINQ to SQL)
   • когда источником данных является плоский файл (ADO.NET)
3. Сопоставление можно изменить без повторной компиляции при настройке файлов модели и сопоставления Обработка артефактов метаданных для копирования в выходной каталог
4. .edmx (модель данных сущности), который содержит:
   • SSDL (язык определения схемы хранения)
   • CSDL (язык определения концептуальной схемы)
   • MSL (язык спецификации отображения)
5. Сопоставления один к одному, один ко многим, многие к одному между таблицами и классами
6. Поддерживает наследование:
   • TPH (таблица на иерархию)
   • TPT (таблица по типу)
   • TPC (таблица на конкретный класс)
7. Поддерживает сложные типы
8. Code-first, Model-first, Storage-first подходы
9. Ориентированное на приложение представление базы данных
10. Создано командой SQL Server
11. Будущее Microsoft Data API

Смотрите также:

• LINQ To SQL против Entity Framework
• Разница между LINQ to SQL и Entity Framework
• Entity Framework против LINQ TO SQL

Здесь вы можете найти хорошее сравнение:

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

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

Linq-to-SQL

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

Linq-to-Entities

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

According to my personal experience Ef is better (if you have no idea about SQL) performance in LINQ is little bit faster as compare to EF reason LINQ language written in lambda.

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

Теперь EF эволюционировал, и в Linq-to-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).

Вот несколько показателей, ребята ... (КОЛИЧЕСТВЕННОЕ ОПРЕДЕЛЕНИЕ !!!!)

Я взял этот запрос, где использовал Entity Framework

var result = (from metattachType in _dbContext.METATTACH_TYPE
                join lineItemMetattachType in _dbContext.LINE_ITEM_METATTACH_TYPE on metattachType.ID equals lineItemMetattachType.METATTACH_TYPE_ID
                where (lineItemMetattachType.LINE_ITEM_ID == lineItemId && lineItemMetattachType.IS_DELETED == false
                && metattachType.IS_DELETED == false)
                select new MetattachTypeDto()
                {
                    Id = metattachType.ID,
                    Name = metattachType.NAME
                }).ToList();

и изменил его на то, где я использую шаблон репозитория Linq

            return await _attachmentTypeRepository.GetAll().Where(x => !x.IsDeleted)
                .Join(_lineItemAttachmentTypeRepository.GetAll().Where(x => x.LineItemId == lineItemId && !x.IsDeleted),
                attachmentType => attachmentType.Id,
                lineItemAttachmentType => lineItemAttachmentType.MetattachTypeId,
                (attachmentType, lineItemAttachmentType) => new AttachmentTypeDto
                {
                    Id = attachmentType.Id,
                    Name = attachmentType.Name
                }).ToListAsync().ConfigureAwait(false);

Linq-to-sql

            return (from attachmentType in _attachmentTypeRepository.GetAll()
                    join lineItemAttachmentType in _lineItemAttachmentTypeRepository.GetAll() on attachmentType.Id equals lineItemAttachmentType.MetattachTypeId
                    where (lineItemAttachmentType.LineItemId == lineItemId && !lineItemAttachmentType.IsDeleted && !attachmentType.IsDeleted)
                    select new AttachmentTypeDto()
                    {
                        Id = attachmentType.Id,
                        Name = attachmentType.Name
                    }).ToList();

Также знайте, что Linq-to-Sql в 14 раз быстрее, чем Linq ...