Теперь, когда был выпущен .NET v3.5 SP1 (вместе с VS2008 SP1), теперь у нас есть доступ к инфраструктуре .NET.
Мой вопрос в том, что. При попытке решить между использованием Entity Framework и LINQ to SQL как ORM, какая разница?
Как я понимаю, платформа Entity Framework (при использовании с LINQ to Entities) является "большим братом" для LINQ to SQL? Если это так - какие преимущества у него есть? Что он может сделать, чтобы LINQ to SQL не мог сделать сам?
LINQ to SQL поддерживает только 1 к 1 сопоставление таблиц, представлений, sprocs и функций базы данных, доступных в Microsoft SQL Server. Это отличный API для быстрого построения доступа к данным в относительно хорошо разработанные базы данных SQL Server. LINQ2SQL был впервые выпущен с С# 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 Truly Dead? Джонатаном Алленом для 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 к реляционным сценариям.
В этой статье @lars имеется ряд очевидных различий, но короткий ответ:
Исходной предпосылкой был L2S для Rapid Development, а EF - для более "прикладных" n-уровневых приложений, но это мало продается L2S.
См. также:
Мой опыт работы с Entity Framework был меньше звездного. Во-первых, вам нужно унаследовать базовые классы EF, поэтому попрощайтесь с POCOs. Ваш дизайн должен быть вокруг EF. С LinqtoSQL я мог бы использовать мои существующие бизнес-объекты. Кроме того, нет никакой ленивой загрузки, вы должны реализовать это самостоятельно. Там есть некоторые возможности для использования POCOs и ленивой загрузки, но они существуют IMHO, потому что EF еще не готов. Я планирую вернуться к нему после 4.0
Я нашел очень хороший ответ здесь, в котором объясняется, когда использовать то, что простыми словами:
Основное правило, для которого необходимо использовать структуру, - это редактирование ваших данных на уровне презентации.
Linq-To-Sql - используйте эту структуру, если вы планируете отредактировать один-к-одному отношения ваших данных в слое презентации. Значение для вас не планируйте комбинировать данные из более чем одной таблицы в любом представлении или страницы.
Entity Framework - используйте эту структуру, если вы планируете объединяя данные из нескольких таблиц в вашем представлении или на странице. Делать это яснее, указанные выше термины являются специфическими для данных, которые будут манипулировать вашим видом или страницей, а не просто отображаться. Это важно понимать.
С помощью Entity Framework вы можете "объединить" отображаемые данные вместе для представления на уровень представления в редактируемой форме, а затем когда эта форма будет отправлена, EF будет знать, как обновлять ВСЕ данные из разных таблиц.
Вероятно, есть более точные причины выбора EF над L2S, но это, вероятно, будет проще всего понять. L2S не имеют возможность объединить данные для представления презентации.
Мое впечатление, что ваша база данных довольно богата или очень плохо разработана, если Linq2Sql не соответствует вашим потребностям. У меня около 10 веб-сайтов, все больше и меньше, с использованием Linq2Sql. Я много раз искал структуру Entity, но я не могу найти вескую причину для ее использования над Linq2Sql. Тем не менее я пытаюсь использовать свои базы данных в качестве модели, поэтому у меня уже есть сопоставление от 1 до 1 между моделью и базой данных.
В моем текущем задании у нас есть база данных с 200 + таблицами. Старая база данных с множеством плохих решений, поэтому я мог видеть преимущества Entity Framework над Linq2Sql, но все же я бы предпочел перепроектировать базу данных, так как база данных является движком приложения и если база данных плохо спроектирована и медленная, то мое приложение также будет медленным. Использование инфраструктуры Entity в такой базе данных похоже на быстрое исправление для маскировки плохой модели, но она никогда не сможет скрыть плохую производительность, которую вы получаете из такой базы данных.
Вы можете найти хорошее сравнение здесь:
http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1
В ответах здесь были рассмотрены многие различия между Linq2Sql и EF, но есть ключевой момент, которому не уделялось много внимания: Linq2Sql поддерживает только SQL Server, тогда как EF имеет провайдеры для следующих СУБД:
Предоставлено Microsoft:
Через сторонние провайдеры:
чтобы назвать несколько.
Это делает 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 (или с открытым исходным кодом, чтобы сообщество могло это сделать).
Приложение, декабрь 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 и Entity Framework выглядят одинаково на поверхности. Они оба обеспечивают LINQ запрос к базе данных с использованием модели данных.
LINQ to SQL возник из проекта LINQ, который вышел из команды, которая работает с language.While Entity Framework был проектом команды Data Programmability и был сфокусирован на языке Entity SQL. Microsoft не намерена лишать LINQ для SQL.
LINQ to SQL по-прежнему является частью ADO.NET, в то время как структура Entity имеет отдельный API. Структура Entity - это более высокая версия LINQ to SQL. В инфраструктуре Entity Data используется модель данных сущностей для соединения между вашим приложением и вашим хранилищем данных. Именно модель данных Entity или EDM предоставляет определение вашей концептуальной схемы, а также информацию о схеме базы данных, необходимую для взаимодействия с базой данных, и, наконец, схему сопоставления, которая ссылается на две.
Вот некоторая задача, выполняемая Entity Framework (модель данных Entity).
• Автоматически создает классы из модели и обновляет эти классы динамически в любое время, когда модель изменяется.
• берет на себя все подключения к базе данных, чтобы разработчики не обременялись необходимостью писать много кода для взаимодействия с базой данных.
• Предоставляет общий синтаксис запросов для запроса модели, а не базы данных, а затем переводит эти запросы в запросы, которые может понять база данных.
• Предоставляет механизм отслеживания изменений объектов модели, поскольку они используется в приложениях и обрабатывает обновления базы данных.
Linq к SQL
Это поставщик, который поддерживает только SQL Server. Это технология сопоставления для сопоставления таблиц базы данных SQL Server с объектами .NET. Является ли Microsoft первой попыткой ORM-объектно-реляционного сопоставления.
Linq к Entities
Является одной и той же идеей, но с использованием Entity Framework в фоновом режиме, поскольку ORM - снова из Microsoft. Он поддерживает несколько основных преимуществ базы данных для инфраструктуры сущностей - разработчик может работать в любой базе данных, не нужно изучать синтаксис для выполнения любой операции на разные базы данных
По моему личному опыту Ef лучше (если вы не имеете представления о SQL) производительность в LINQ немного быстрее, чем сравнение с языком LINQ LINK, написанным на лямбда.