为什么使用EF / Linq to sql创建性能较差的查询非常容易

Question

我一直在使用linq-to-sql＆amp; ado.net entityframework。每次我们遇到性能问题时，几乎总是由于使用了EF / linq到sql。编写代码似乎很容易，它会触发大量查询，或者在给出实际结果之前首先获取1000条记录来完成一些内部工作。即便有我的知识和遇到这个问题的经验，我经常发现自己使用某种逻辑C＃语句来向数据库发出一个非常不合逻辑的执行查询。

一个简单的例子：假设您有2个表Customer和Invoices。 Invoice具有Customer表的CustomerID

这将首先从数据库中获取所有发票记录，然后检查是否有任何记录。如果您的客户有1000张发票，则会从数据库向您的应用程序发送1000条记录

Customer.Invoices.Any() //or .Where or some paging statement or ...

这里的解决方案是直接在datacontext上查询

db.Invoices.Any(invoice=>invoice.CustomerID=Customer.CustomerID)

我确信总会有技术解释和解决方案来解决这个问题，但是映射器看起来很不合理，因此很容易搞砸应用程序的性能。这些映射器很容易，所以任何初级程序员都可以使用它，并带来一切后果。我见过一些或多或少经验丰富的开发人员甚至都不知道这个问题。为什么我在谷歌上找不到任何关于这个“陷阱”的提法？我没有看到正确的道路吗？像NHibernate这样的其他ORM会遭遇同样的问题吗？

Answer 1

这是所谓的物体 - 关系阻抗不匹配的一部分。除了在SQL出现时对其进行手动编码，除此之外没有通用的解决方案。

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

是的，所有ORM在某种程度上都受此影响。我见过的最好的方法是创建表示应该返回什么数据的声明性指令的对象。只有在最后一刻，您才将所有指令组合到一个SQL语句中以便执行。我认为这基本上就是LINQ已经做过的事情。