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

Question

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

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

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

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

Комментарии

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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