在LINQtoSQL上是否可以实现干净的SQL？

在LINQtoSQL中是否可以实现干净（或者说性能）的SQL

我希望Linq Sql生成以下代码：

SELECT C.CustomerID, COUNT(O.CustomerID) AS N
FROM Customers C
LEFT JOIN Orders O ON O.CustomerID = C.CustomerID
GROUP BY C.CustomerID

我遵循这个准则：

下面是我的代码版本：

var q = from c in db.Customers
        join o in db.Orders on c.CustomerID equals o.CustomerID into sr
        from x in sr.DefaultIfEmpty()
        group x by c.CustomerID into y
        select new { y.Key, N = y.Count(t => t.CustomerID != null) };

但是它产生了这个

SELECT [t2].[CustomerID] AS [Key], (
    SELECT COUNT(*)
    FROM [Customers] AS [t3]
    LEFT OUTER JOIN [Orders] AS [t4] ON [t3].[CustomerID] = [t4].[CustomerID]
    WHERE ([t4].[CustomerID] IS NOT NULL) AND ((([t2].[CustomerID] IS NULL) AND ([t3].[CustomerID] IS NULL)) OR (([t2].[CustomerID] IS NOT NULL) AND ([t3].[CustomerID] IS NOT NULL) AND ([t2].[CustomerID] = [t3].[CustomerID])))
    ) AS [N]
FROM (
    SELECT [t0].[CustomerID]
    FROM [Customers] AS [t0]
    LEFT OUTER JOIN [Orders] AS [t1] ON [t0].[CustomerID] = [t1].[CustomerID]
    GROUP BY [t0].[CustomerID]
    ) AS [t2]

…这是我无法接受的

然后我试试这个

var q = from c in db.Customers
        join o in db.Orders on c.CustomerID equals o.CustomerID into sr
        from x in sr.DefaultIfEmpty()
        group x by c.CustomerID into y                                        
        select new { y.Key, N = y.Sum(t => t.CustomerID != null ? 1 : 0 )};

…下面是生成的查询：

SELECT SUM(
    (CASE
        WHEN [t1].[CustomerID] IS NOT NULL THEN @p0
        ELSE @p1
     END)) AS [N], [t0].[CustomerID] AS [Key]
FROM [Customers] AS [t0]
LEFT OUTER JOIN [Orders] AS [t1] ON [t0].[CustomerID] = [t1].[CustomerID]
GROUP BY [t0].[CustomerID]

虽然有点干净，看起来也很好，但与更简单的语句相比，仍然不够简洁和高效：

COUNT（O.CustomerID）

在LINQtoSQL中，我试图做的是可能的吗

---

其他ORM呢？值得注意的是，NHibernate能否将HQL语句转换为真正的SQL？

我认为您通常必须接受LINQ to SQL生成的内容，但希望LINQ to SQL将允许您完全忽略SQL（大多数情况下）——我发现这是一个有价值的权衡

---

对于复杂的报表，我通常会退出LINQ，转而编写纯SQL，尤其是当查询涉及大量特定于数据库的内容时；我不希望抽象层更好。我同意，似乎我只会将ORM用于持久层。我不认为ORMs（或者至少在linqtosql中）可以直接满足报告需求（尤其是那些复杂的需求）。虽然我想知道其他开发人员是否在使用ORM满足他们的报告需求方面取得了一定程度的成功，但你有可能会吹毛求疵吗？这些查询的执行计划是什么？您是否担心SQL只是出于风格目的而不是出于实用目的？它很实用，子查询是性能杀手。不是出于风格的目的，如果子查询被证明性能良好，我对此没有问题