Теперь, когда выпущен .NET v3.5 SP1 (вместе с VS2008 SP1), у нас теперь есть доступ к инфраструктуре сущностей .NET.
У меня вопрос такой. При попытке выбора между использованием Entity Framework и LINQ to SQL в качестве ORM, какая разница?
Как я понимаю, Entity Framework (при использовании с LINQ to Entities) является «старшим братом» для LINQ to SQL? Если это так - какие у него преимущества? Что он может сделать, что LINQ to SQL не может сделать самостоятельно?
.net
entity-framework
linq-to-sql
Крис Робертс
источник
источник
Ответы:
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
источник
В этой статье @lars опубликовано несколько очевидных отличий, но короткий ответ:
Первоначально предполагалось, что L2S предназначен для быстрой разработки, а EF - для более «корпоративных» n-уровневых приложений, но это продает L2S немного меньше.
источник
LINQ to SQL
Entity Framework
Смотрите также:
источник
dbSet<Orders>.Where()...ToList()
? Я думаю, что вводить Entity Framework в противоположность LINQ to SQL вводит в заблуждение.Мой опыт работы с Entity Framework был менее чем звездным. Во-первых, вы должны наследовать от базовых классов EF, так что попрощайтесь с POCO. Ваш дизайн должен быть вокруг EF. С LinqtoSQL я мог использовать свои существующие бизнес-объекты. Кроме того, нет ленивой загрузки, вы должны реализовать это самостоятельно. Существует несколько способов использования POCO и отложенной загрузки, но они существуют, IMHO, потому что EF еще не готов. Я планирую вернуться к нему после 4.0
источник
Я нашел очень хороший ответ здесь , который объясняет , когда использовать то , что в простых словах:
источник
У меня сложилось впечатление, что ваша база данных довольно обширна или очень плохо спроектирована, если Linq2Sql не соответствует вашим потребностям. У меня есть около 10 веб-сайтов, больше и меньше, все используют Linq2Sql. Я смотрел и Entity Framework много раз, но я не могу найти вескую причину для его использования над Linq2Sql. Тем не менее, я пытаюсь использовать свои базы данных в качестве модели, поэтому у меня уже есть соотношение 1: 1 между моделью и базой данных.
На моей текущей работе у нас есть база данных с более чем 200 таблицами. Старая база данных с множеством плохих решений, поэтому я мог видеть преимущество Entity Framework по сравнению с Linq2Sql, но все же я бы предпочел изменить структуру базы данных, поскольку база данных является ядром приложения, а если база данных плохо спроектирована и работает медленно, тогда мое приложение также будет медленным. Использование Entity Framework в такой базе данных кажется быстрым исправлением, чтобы скрыть плохую модель, но она никогда не сможет скрыть плохую производительность, которую вы получаете от такой базы данных.
источник
Вы можете найти хорошее сравнение здесь:
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
источник
sqlmetal.exe
docs.microsoft.com/en-us/dotnet/framework/tools/… для генерации кода / отображения из базы данных при использованииLinq to SQL
Здесь приведены ответы на многие из различий между Linq2Sql и EF, но есть ключевой момент, которому не было уделено много внимания: Linq2Sql поддерживает только SQL Server, тогда как EF имеет поставщиков для следующих RDBMS:
Предоставлено 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).
источник
Это провайдер, он поддерживает только SQL Server. Это технология отображения для сопоставления таблиц базы данных SQL Server с объектами .NET. Это первая попытка Microsoft создать ORM - объектно-реляционный маппер.
Это та же идея, но с использованием Entity Framework в фоновом режиме, как ORM - опять-таки от Microsoft. Он поддерживает несколько баз данных. Основное преимущество Entity Framework - разработчик может работать с любой базой данных, нет необходимости изучать синтаксис для выполнения каких-либо операций с различными различными базами данных.
источник