Linq to SQL仍然是开发应用程序的可行选择吗？

Question

在Ruby on Rails的短暂（偶尔持续）工作之后，我再次阅读.NET内容。我想知道在为新应用程序选择ORM时LINQ仍然是一个选择，或者我是否应该学习类似NHibernate的东西，而这似乎仍然很强大。我知道Linq基本上被实体框架所包含，但是当我尝试使用EF（这是前一段时间）时，我发现它太沉重而且“鼠标驱动”（即很多人都在和设计师一起玩）。我在NHibernate上观看了一些简短的截屏视频，我确实喜欢它所强调的关注点的分离，以及你的模型可以保持清洁的想法。

Linq的语法非常好，但它不是一个真正的ORM，我不想看到学习一些基本上过时的东西，当我可以学习正在使用或将被使用的东西时（EF和/或NHibernate，for例子）。

因此，Linq仍然应该考虑在应用程序中使用（让我们假设一些中等复杂性;不是一个简单的应用程序，而不是一项巨大的任务;与像37Signal的Highrise一样复杂的基于Web的应用程序）或者是否有更好的东西值得一看呢？

Answer 1

Linq不是ORM，Linq很棒。如果可能的话，你很可能想要使用Linq。

LinqToSql是一个ORM，虽然它非常轻巧。它为您提供基于SQL Server数据库定义的活动记录类型数据层类的基本（主要是一次）代码生成。虽然它支持一些基本的ORM功能，但大多数你想要的东西，你将不得不自己创建。

EntityFramework也是一个ORM。虽然它分享了LinqToSql的一些限制，但它也做了一些更好的事情，有些事情更糟。当前的V1有许多限制，其中一些将在Visual Studio 2010推出的下一个版本（V4）中得到解决。

LinqToSql或EntityFramework都不是成熟的，经过验证的ORM。两者都有明显的缺点，你可能会遇到大多数“正常”的软件开发项目。

NHibernate提供了比微软ORM更多的功能，你会发现它几乎适用于任何“现实世界”的情况。如果您喜欢ActiveRecord模式，然后是Microsoft的ORM，NHibernate也支持Castle ActiveRecord。

所有这三个ORM都支持Linq。

提醒一句。在项目中期切换ORM可能既困难又昂贵，具体取决于您将数据层与其他层分开的程度。你不能轻易地从例如LinqToSql开始，然后在遇到LinqToSql的许多限制之一时切换到例如NHibernate，除非你真的很聪明你如何将你的ORM与其他实现分离出来，根据ORM，这可能非常困难。

Answer 2

您需要将LINQ区分为程序设计语言概念（语言集成查询），将Linq-to-SQL区分为面向SQL Server的数据库映射（“ORM”）工具。

LINQ本身 - 作为一种技术 - 肯定会留下来 - 毫无疑问。

Linq-to-SQL有点不同，因为微软不再为其进一步的开发投入太多资源。对于.NET 4.0，它们会出现一些增强功能和错误修复，但没有什么重要的。

因此，如果您的应用程序很小并且您没有真正想象它可以在生产中使用10年或更长时间，您仍然可以选择Linq-to-SQL作为一种非常可行且有用的技术，可以快速轻松地启动和运行 - 只要您只需要SQL Server作为数据库后端。

如果您处于面向企业的环境中，如果您的应用程序可能会持续10年或更长时间，或者您需要异构数据库后端，或者您需要在数据库中的不同物理架构与对象之间进行映射域模型 - 然后选择ADO.NET实体框架和Linq到实体。它提供了比Linq-to-SQL更多的冲击 - 以更高的学习曲线为代价。

您的选择 - 这两种技术绝对是今天和未来2年，3年，5年内构建应用程序的好方法 - 之后，所有赌注都将关闭： - ）

马克

Answer 3

我相信StackOverflow（仍然）在LINQ to SQL上运行，所以说它不是一个可行的选择会有点奇怪。我在WPF和ASP.NET中做了一些演示，它很简单，易于使用。用直接SQL做什么是你不能做的。

Answer 4

我想补充一点，你在.NET上使用的是one of the fastest options。考虑到支持的LINQ功能的质量，它可以是各种情况下的最佳选择。

Answer 5

LINQ to SQL对于需要实现不是非常复杂的数据库访问层的开发人员来说是一个方便的选择（这是相当常见的情况）。
我们公司正在不断改进LINQ to SQL tecnology for Oracle, MySQL, PostgreSQL and SQLite databases的实施。