Entity Framework & LINQ To SQL - конфликт интересов?
На прошлой неделе я читал в блогосфере, что 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.
Комментарии?
3 ответа
Стоит отметить, что 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.
На самом деле EF не генерирует EntitySQL при трансляции запросов LINQ. В EF у нас есть представление на основе структуры данных для всех запросов, называемое CQT или каноническими деревьями запросов. И преобразователь LINQ, и анализатор EntitySQL создают CQT, а остальная часть конвейера преобразования запросов использует CQT (и другие внутренние промежуточные формы), которые после различных преобразований превращаются в поставщика ADO.NET (как CQT уровня хранилища), который затем отвечает за перевод его на диалект SQL сервера. Таким образом, пути LINQ -> CQT -> SQL или EntitySQL -> CQT -> SQL.
Большая разница между Linq для SQL и Entity Framework заключается в том, что EF реализует спецификацию модели данных Entity (EDM), и существуют другие продукты, построенные на основе EDM, такие как ADO.NET Data Services (также известная как Astoria).
В настоящее время EDM используется для расширения AtomPub в новой спецификации под названием Open Data Protocol (OData http://odata.org/), которая используется для стандартизации CRUD поверх REST.