Question

我一直在研究用于我正在设计的基于Web的新项目的数据层，我非常希望看到将LINQ加入SQL。它显而易见的简单性，灵活性和设计器支持确实很吸引人，并且与SQL Server的隐式绑定很好。

但是，最近已经宣布，LINQ to SQL现在已经退回到实体框架，因为它已被传递给ADO.NET团队（http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx）。当然，它将在未来得到支持，但它不太可能会看到更多的开发工作。

考虑到这一点，你会建议我在我的项目中使用这项技术，还是值得选择一种替代的ORM（nHibernate？）或手动编写一般的DAL？

该项目本身是基于ASP.NET和SQL Server 2005/2008的，并且可能会使用MVC，即使它仍处于测试阶段。这是一个个人项目，数据库不会过于复杂，主要用作查看.NET未来技术的原型。我将基于我从这一方面学到的东西来建立未来的项目，所以我做出的选择将影响更大的解决方案。

是的，我意识到微软可能会在明天推出全新的数据访问技术！ ;）

Answer 1

选择NHibernate。它将作为一个概念或实际的ORM保持一段时间。因此，学习两者都会很有用。

Answer 2

IMO，这整件事情确实不成比例。

微软没有说LINQ to SQL会死掉。他们更多地表示它将合并到实体框架中。

我将专注于使用Entity Framework作为解决方案，因为我们知道LINQ to SQL的大部分内容都会被融入其中。

现在确实没有那么大的差别。最大的抱怨是实体框架不是轻量级的。只要你的等级之间有很好的分离，这真的很重要吗？

Answer 3

嗯，这里的答案大部分已经包含在答案中（也有一些有趣的观点），但无论如何我都会再说一遍......

LINQ to SQL（L2S）非常通用，但从我的观点来看，它感觉有点太基础了。在大多数情况下，它在做简单的事情上做得很好，但是一旦你多了一点，它就会变得昂贵。这根本不是一件坏事。我实际上认为LINQ to SQL实际上很好地补充了实体框架。

以LinqDataSource为例进行自动分页。如果您没有指定Order By / Group By那么它非常经济。将排序或分组投入到混合中，你开始获得性能上升（变得非常健谈）。然后你几乎必须编写自己的分页实现（这不是非常难，我承认）。

我将是第一个承认L2S在生成的T-SQL质量方面优于实体框架的优势（我应该，因为L2S专门用于查询SQL Server），并且在概念和语义上， LINQ to SQL的大部分内容与EF类似，但是您可以在这里扩展需求并考虑更复杂的实现要求。

如果我从头开始并选择投入个人开发时间，我会选择实体框架。有趣的是，我正在研究一个使用L2S的项目，它正在设计用于扩展nad处理重负载，但是当我们达到一些更“创造性”的要求时，我们常常被迫扩展SQL Metal （例如，多对多关系）。

所以......简而言之......我会接近它：

a）学习LINQ to SQL作为介绍（对于微软的ORM模式和技术）..它让你熟悉与实体框架共享的大部分基础知识，以及LINQ风格查询的味道（获得的品味）如果你有T-SQL的背景知识）

b）一旦掌握了LINQ to SQL，我建议跳转到实体框架以了解其他好处（eSQL等）

c）在两者中实施概念验证项目并比较结果。

Answer 4

L2S，恕我直言，完全没有问题，正如你所说，不会去任何地方。我工作的公司已经成为我们的数据访问标准，我们将它用于从小5个用户小众应用到1000多个用户企业应用程序的所有应用程序。

Answer 5

查看SubSonic：

http://subsonicproject.com/

Answer 6

我认为EDM的目标远远大于LINQ to SQL的目标。如果您正在寻找一个简单的ORM，那么我认为LINQ to SQL是可行的方法。如果您打算在具有与具有关系结构的数据库表相关的继承结构的类中构建并执行其他高级映射，那么EDM可能是一个不错的选择。

Answer 7

值得一提的是，该站点是使用LINQ to SQL构建的。 Jeff谈到在StackOverflow播客上使用它。

Answer 8

L2S是一项非常棒的技术，我永远不会回到原来的ADO。

但正如你所提到的，它正在落后于L2E。 L2S非常强大，我已经用它做了很多应用程序并且非常高兴。但听说它不再先进，就把刀放在我的身边。所以我去看看L2E，它与几乎在SQL交互方面是一样的，在很多方面我觉得它更容易，更不用说它的关系处理更有效了。有了这些相似之处，选择L2E似乎是合乎逻辑的。

我写了一篇关于进行切换和比较两个框架的帖子：http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

我几乎可以保证你会对这些框架中的任何一个感到满意，它们是发展的天赐之物。避免简单性和错误是首屈一指的。我个人倾向于L2E，因为它会更积极地开发L2S。

Answer 9

我在当前的Web项目中大量使用L2S，我相信你会发现最大的挂起是关于进行n层数据库开发的最佳方式的文档冲突。

首先需要提前实现的是，DataContext对象只能持续工作单元，句号。另外，DataContext是无状态的。一旦掌握了这两个原理，在n层环境中使用LINQ就会开始运行良好。

另一方面，你会看到很多人推荐一些非常非常糟糕的方法来使用Linq。不要让你的DataContext变得静态，这是我早期做的一个错误，它一直有效，直到它不起作用，然后在不同的会话中不正确的数据交叉是绝对可怕的等等。简单地说，这可能是最大的使用Linq的最大禁忌，并且应该在每个文档中用粗体字母书写。此外，在Session变量中持久存储DataContext也是一个不错的主意。

我遇到LINQ时遇到的另一个主要问题是，在进行断开连接的更新时，您需要在整个调用中使用相同的DataContext。例如：

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }

除非您设置DataContext.ObjectTrackingEnabled = false，否则您不能简单地传入在不同datacontext中创建的用户并希望更新工作，我不建议这样做。相反，在同一个DataContext中，您应该检索现有对象，更新其值，然后提交更改。将所有类似的任务保存在同一个DataContext中。

我会推荐L2S，一旦你克服了一些琐碎的问题（如上所述），这是一项伟大的技术，绝对可以节省时间。但是我会建议在你的DAL周围做一个薄的包装，这样你就可以轻松改变。我正在考虑（出于经济原因）将我的部分代码移植到使用OpenAccess ORM - ＆gt; MySql用于我的一部分数据访问，并且具有正确定义的层，此任务应该只需要几个小时。

Answer 10

我同意Echostorm。 L2S有利于您的需求。使用它很容易......

Answer 11

如果您正确设计应用并隔离数据访问层，则应使用L2S。从我从你的帖子推断，它不是一个大项目，所以L2S应该很好地满足你的要求，而普通的旧ADO.NET只是一个禁忌，实体框架，是......只是不要使用它，好？无论如何，如果你很好地隔离你的DAL，如果项目增长，你可以在未来将L2S换成其他东西。即使L2S没有去任何地方，它也不会去任何地方。 MS停止投资，但它不会被弃用或其他什么，所以它仍然是一个安全的投资。或者，您应该评估NHibernate，它简单而成熟。

你会为新项目使用LINQ to SQL吗？

11 个答案: