Entity Framework & LINQ To SQL - Конфликт интересов?

Question

Я читал в блогосфере за прошлую неделю, что Linq to SQL мертв [и долго живет в EF и Linq для Entities]. Но когда я прочитал обзор MSDN, мне показалось, что Linq to Entities генерирует eSQL так же, как Linq to SQL генерирует SQL-запросы.

Теперь, поскольку базовая реализация (и поскольку SQL Server еще не является ODBMS) по-прежнему является реляционным хранилищем, в какой-то момент структура Entity должна произвести перевод в SQL-запросы. Почему бы не исправить проблемы Linq to SQL (отношения m: m, только поддержка SQL-сервера и т. Д.) И использовать Linq для SQL в качестве слоя, который генерирует эти запросы?

Это из-за производительности или EF использует другой способ преобразования выражения eSQL в SQL?

Мне показалось - по крайней мере, для моего неопытного ума - естественным образом подходит для досуга Linq к SQL в EF.

Комментарии?

Answer 1

Стоит отметить, что Entity Framework имеет (по крайней мере) три способа потребляются:

• LINQ для лиц с помощью служб объекта над Клиентом Entity
• Entity SQL с помощью служб объектов над Entity Client
• Entity SQL с использованием объектов командной строки Entity Client (наиболее похоже на классический ADO.NET)

Клиент Entity в конечном счете выплевывает представление команды ESQL (в каноническая, агностическая база данных), которую поставщик ADO.NET для конкретной СУБД несет ответственность за преобразование в SQL-файл хранилища. Это правильная модель ИМХО, поскольку на протяжении многих лет было потрачено много времени (и будет продолжаться инвестирование) в создание великих поставщиков ADO.NET для каждого магазина.

Поскольку Entity Framework необходимо работать со многими магазинами, и поэтому у многих поставщиков ADO.NET меньше возможностей для их оптимизации, что создает клиент Entity Client на основе каждого хранилища (по крайней мере, это то, где мы находимся с v1) , Команда LINQ to SQL имела гораздо меньшую проблему для решения - «работает только с SQL Server» и, следовательно, может легче хранить определенные вещи. Я знаю, что команда EF знает, что есть случаи, когда EF для SQL Server производит TSQL менее эффективно, чем L2S, и работает над улучшением этого для V2.

Интересно, что эта модель позволяет добавлять новые возможности между клиентом Entity и поставщиком ADO.NET для магазина. Эти «поставщики упаковки» могут добавлять такие сервисы, как ведение журнала, аудит, безопасность, кэширование. Это обсуждается как функция V2 по адресу http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

Если вы посмотрите на них, то на большой картинке вы увидите, что было бы ужасно сложно и действительно ограничивать попытку и каким-то образом модифицировать генерацию TSQL L2S в архитектуру Entity Framework.

Answer 2

Большая разница между Linq to SQL и Entity Framework заключается в том, что EF реализует спецификацию модели данных сущностей (EDM), и есть другие продукты, которые построены вокруг EDM, например ADO.NET Data Services (aka Astoria).

EDM теперь используется для расширения AtomPub в новой спецификации Open Data Protocol (OData http://odata.org/), которая используется для стандартизации CRUD поверх REST.

Answer 3

На самом деле, EF не генерирует EntitySQL при переводе запросов LINQ.В EF мы имеем представление на основе структуры данных для всех запросов, называемых CQT или канонических деревьев запросов. И переводчик LINQ, и парсер EntitySQL производят CQT, а остальная часть конвейера трансляции запросов использует CQT (и другие внутренние промежуточные формы), которые после того, как различные преобразования превращаются в поставщика ADO.NET (как CQT на уровне магазина) который затем отвечает за перевод его на SQL-запрос бэкэнда. Таким образом, пути LINQ -> CQT -> SQL или EntitySQL -> CQT -> SQL.