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

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

好吧，这里的答案大部分已经涵盖了（还有一些有趣的观点），但无论如何我还是要再说一遍..

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

以使用 LinqDataSource 进行自动分页为例。如果您不指定 Order By/Group By 那么这是相当经济的。将排序或分组加入其中，你的性能就会开始飙升（变得非常健谈）。然后，您几乎必须编写自己的分页实现（我承认，这并不是很难）。

我将第一个承认 L2S 在生成的 T-SQL 的质量方面比实体框架具有优势（我应该这样做，因为 L2S 是专门为查询 SQL Server 而构建的），并且从概念上和语义上来说，LINQ 的大部分内容to SQL 与 EF 类似，但遇到的困难在于扩展需求和考虑更复杂的实现需求。

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

所以..简而言之..我会这样处理：

a) 学习 LINQ to SQL 作为入门（Microsoft 的 ORM 模式和技术）。它可以让您熟悉与实体框架共享的大部分基础知识，并体验 LINQ 风格的查询（如果您有有 T-SQL 背景）

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

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