Entity Framework против 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 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 - используйте этот фреймворк, если вы планируете редактировать взаимно-однозначные отношения ваших данных на уровне представления. Это означает, что вы не планируете объединять данные из более чем одной таблицы в одном представлении или на одной странице.

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

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

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

Ответы здесь охватывают многие различия между 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

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

Linq-to-Entities

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

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

Я работаю для клиента, у которого есть большой проект, использующий 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).

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

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

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

введите описание изображения здесь

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

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

Я взял этот запрос, где использовал 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-в-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 ...

введите описание изображения здесь

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

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

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

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

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

Если ваша база данных проста и понятна, подойдет 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 в реляционных сценариях.

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