LinqToSQL是否足够强大？难道不是更容易构建更强大但同样流畅的界面吗？

Question

在上一个问题中，我询问ORM库是否是次优解决方案，并收到了很多好评。当我进一步考虑该问题时，我得出的结论是，LinqToSQL（现在）的主要好处和LinqToEntities（在未来）的承诺在于它们能够减少程序代码与SQL之间的“不匹配”。鉴于LinqToSQL作为一种完整的数据查询语言的局限性，我不愿意同意它的优势远不止于此，但我想知道其他人的看法。

首先，程序代码与SQL之间的“不匹配”是什么意思？如果您曾经开发过数据库应用程序，那么您可能已经熟悉（和厌倦了）与数据库交互所需的步骤：设置所有参数，输入SQL命令，然后将预期结果手动转换回变量或代码中使用的实例。

LinqToSql通过使用“流利的”接口，lambda表达式，扩展方法等使此操作变得更加容易。最终结果是，很容易将本机C＃标量类型推入数据检索调用中，并且易于自动生成本机C＃类实例。从MS网站上获取以下示例：

var q =
   from c in db.Customers
   where c.City == "London"
   select c;
foreach (var cust in q)
   Console.WriteLine("id = {0}, City = {1}",cust.CustomerID, cust.City);

很酷！

那是什么问题呢？

好吧，正如我在顶部链接的文章中指出的那样，存在许多问题。在 最大的
为我的搅局者是人谁是SQL微创主管会马上打路障。不仅仅是许多替代SQL的结构不熟悉甚至笨拙（Group By？我们在LinqToSql中讨论的是 丑陋
的问题）。更大的问题是，有许多本机不支持的常见构造（例如DateDiff）。充其量，您可以“逃脱” Linq，然后将SQL代码提交到Linq调用流中。

因此，以允许您自由声明SQL但又使您轻松进行参数嵌入和自动转换为本机类的方式，简单地将SQL嵌入C＃（或VB）中不是更好吗？例如，如果我们在一个类中仅实现六个函数，则可以编写如下代码（其中qry是查询类的实例）：

var ListOfEnrollees = 
           qry.Command("Select b.FirstName, b.LastName, b.ID From ClassEnroll a inner join Folder b on (a.ClientID = b.ClientID) ")
             .Where ("a.ClassID", classID)
             .AND()
             .Append("(DateDiff(d, a.ClassDate, @ClassDate) = 0) Order By LastName;")
             .ParamVal(classDate)
             .ReturnList<EnrollListMemberData>();

该 命令 只是开始我们送行收集SQL语句时， 如果 开始我们的SQL Where子句，并进入第一个参数， 追加 更多的SQL大头钉，
ParamVal 刚刚进入一个参数值，以便与SQL参数上一行找到， ReturnList
做转换为类所需的魔术。请注意，这只是SQL：连接很简单，支持DateDiff（或任何其他SQL构造），等等。我们可以在SQL窗口中对其进行测试，然后将其剪切并粘贴到我们的代码中，并根据需要将其分解以输入我们的参数。再简单不过了。

现在，上面显示的基本构造对我来说简直太简单了，它可以使用 已经 拥有的SQL知识来处理 任何
SQL构造。我确实必须使用一些反射和其他一些很酷的新C＃3构造来使ReturnList（和类似的调用）工作，但是总的来说，这非常简单。我还添加了许多功能，使界面更加流畅。所以，这是我的问题，也是我想听听社区意见的地方：
__

为什么我需要掌握LinqToEntities的复杂性，甚至会产生LinqToSql的开销？这难道不是给我LinqToSql给我的一切吗？除了奇异的关系到对象的映射之外，它是否还不包括LinqToEntities？

更新 ：哈米什·史密斯（Hamish
Smith）在下面提出论点，即有朝一日，LINQ可能是一种功能全面的数据处理语言，其功能如此强大，甚至不需要SQL。这是一个重要的临界点论点，我没有讨论，但我同意。我的立场的实质是，尽管LinqToSql有一些实际的优势，但仍然
远远 没有达到Hamish的目标。这是一个非常现实的重大缺陷。

Hamish还正确地指出，我仍在使用嵌入式SQL-我尚未“解决”该问题。但是对我来说，这是一个 功能，
而不是错误。SQL在选择和操作关系数据（毕竟是我们正在使用的数据）方面仍然要好得多，我 希望
能够使用它来设计解决方案。我认为嵌入式SQL的问题不仅仅在于嵌入式SQL与C＃之间的阻抗不匹配。但是，通过使用受Linq启发的C＃3的新功能，我可以在很大程度上消除这种“阻抗不匹配”并获得两全其美的效果。

Answer 1

因此，以允许您自由声明SQL但又使您轻松进行参数嵌入和自动转换为本机类的方式，简单地将SQL嵌入C＃（或VB）中不是更好吗？

我通常所做的非常接近这一点。我在存储过程中编写SQL，因此可以自由使用真正的SQL。在C＃中，我使用Linq的DBML以自然的方式访问存储过程。这感觉就像两全其美。

真正的解决方案对我来说更简单：将SQL嵌入C＃代码中，并让编译器生成强大的类。如果Visual Studio支持这一点，我怀疑有人会使用其他任何东西。

（总有人尝试创建实体框架并“架构”掉SQL的需求。据我所知，这仅仅是因为结果很难维护且非常缓慢而从未真正奏效。）