实体框架与LINQ To SQL-利益冲突? [英] Entity Framework & LINQ To SQL - Conflict of interest?

问题描述

在过去的一周里，我一直在博客圈上读到Linq to SQL已死[并且EF和Linq to Entities寿命很长].但是，当我阅读有关MSDN的概述时，对我来说，Linq to Entities似乎就像Linq to SQL生成SQL查询一样生成eSQL.

现在，由于基础实现(并且由于SQL Server还不是ODBMS)仍然是关系存储，因此在某些时候，实体框架必须将其转换为SQL查询.为什么不解决Linq到SQL的问题(m:m关系，仅支持SQL Server等)，并使用Linq到SQL作为生成这些查询的层?

这是因为性能还是EF使用了将eSQL语句转换为SQL的另一种方式?

在我看来-至少对于我没有学识的人来说-很自然地适合EF中的SQL的狗粮Linq.

评论?

解决方案

值得注意的是，Entity Framework具有(至少)三种使用方式:

• LINQ到实体客户端上的对象服务上的实体
• 基于实体客户端的对象服务上的实体SQL
• 使用Entity Client命令对象的Entity SQL(与经典ADO.NET最相似)

实体客户端最终发出ESQL命令的表示形式(规范的，与数据库无关的形式)，该ESQL命令的特定RDBMS的ADO.NET Provider负责将其转换为存储特定的SQL.恕我直言，这是正确的模型，因为多年来已经投入了大量时间(并将继续投入)为每个商店生产出色的ADO.NET提供程序.

由于Entity Framework需要与许多商店配合使用，因此许多ADO.NET Provider的使用范围较小，可以轻松地优化Entity Client基于每个商店生成的内容(至少-这就是我们使用v1的方式). LINQ to SQL团队要解决的问题要小得多-仅适用于SQL Server"，因此可以更轻松地存储特定内容.我知道EF团队知道，在某些情况下，SQL Server的EF生成TSQL的效率不如L2S，并且正在为V2进行改进.

有趣的是，此模型允许在实体客户端和商店的ADO.NET提供程序之间添加新功能.这些包装提供程序"可以添加服务，例如日志记录，审核，安全性，缓存.在 http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

如果从更大的角度看，您会发现尝试以某种方式将L2S TSQL生成改造到实体框架的架构中将是非常困难的，而且确实是限制性的.

I've been reading on the blogosphere for the past week that Linq to SQL is dead [and long live EF and Linq to Entities]. But when I read the overview on MSDN, it appeared to me Linq to Entities generates eSQL just the way Linq to SQL generates SQL queries.

Now, since the underlying implementation (and since SQL Server is not yet an ODBMS) is still a Relational store, at some point the Entity framework has to make the translation into SQL queries. Why not fix the Linq to SQL issues (m:m relationships, only SQL server support etc.) and use Linq to SQL in as the layer that generates these queries?

Is this because of performance or EF uses a different way of transforming the eSQL statement into SQL?

It seemed to me - at least for my unlearned mind - a natural fit to dogfood Linq to SQL in EF.

Comments?

解决方案

It is worth noting that Entity Framework has (at least) three ways of being consumed:

• LINQ to Entities over Object Services over Entity Client
• Entity SQL over Object Services over Entity Client
• Entity SQL using Entity Client command objects (most similar to classic ADO.NET)

Entity Client ultimately spits out a representation of the ESQL command (in a canonical, database agnostic form) which the ADO.NET Provider for the specific RDBMS is responsible for converting into store specific SQL. This is the right model IMHO as over the years a lot of time has been invested (and will continue to be invested) in producing great ADO.NET Providers for each store.

As Entity Framework needs to work with many stores and therefore many ADO.NET Providers there is less scope for them to easily optimise what the Entity Client generates on a per store basis (at least - thats where we are with v1). The LINQ to SQL team had a much smaller problem to solve - "works only with SQL Server" and hence could do store specific stuff more easily. I know the EF team are aware that there are cases where EF to SQL Server is producing TSQL less efficiently than L2S and are working on improving this for V2.

Interestingly this model allows new capabilities to be added between the Entity Client and the ADO.NET Provider for a store. These "wrapping providers" can add services such as logging, auditing, security, caching. This is discussed as a V2 feature over at http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

If you look therefor at the bigger picture you can see that it would be horribly difficult and indeed restrictive to try and somehow retrofit L2S TSQL generation into the archiecture of the Entity Framework.

这篇关于实体框架与LINQ To SQL-利益冲突?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！