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

Я читал в блогосфере на прошлой неделе, что 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 to SQL в качестве слоя, который генерирует эти запросы?

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

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

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

Ответы

Ответ 1

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

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

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

Поскольку Entity Framework должна работать со многими магазинами, и поэтому у многих поставщиков ADO.NET меньше возможностей для них, чтобы легко оптимизировать то, что генерирует клиент Entity на основе каждого хранилища (по крайней мере, это то, где мы находимся с 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.

Ответ 2

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

Ответ 3

Большая разница между 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.