要问自己的一个重要问题是，是否可以接受对SQL Server的依赖性。例如，数据库后端是否会更改为Oracle？LINQ to SQL与SQL Server的耦合很强，而NHibernate则不是。我并不是说这一定是一个不好的限制，但考虑这一点很重要。
NHibernate在过去的几年里确实取得了长足的进步。例如，我真的很喜欢Fluent NHibernate，但这并不是说LINQ to SQL有局限性。我喜欢与Visual Studio的集成，它已经证明了自己能够处理一致的负载（例如，Stack Overflow使用LINQ to SQL）。
与普遍的看法相反，LINQ to SQL is not dead。

**编辑：**要问自己的另一个重要问题是是否要更改域模型。LINQ to SQL将对象直接Map到表。另一方面，NHibernate允许一个间接层。顺便说一句，实体框架也是如此。

我会选择NHibernate，因为有一个很好的开源社区支持它，回答关于它的问题，等等。随着你的产品变得越来越大，越来越复杂，你会欣赏NH的强大和灵活性。最后，Linq-to-sql不在微软的长期计划中，因为他们希望你使用实体框架，所以你可能最终会遇到一个死胡同。

我会投Linq-to-SQL的票-为什么？

• 它有一个可视化设计器，可以让你更容易和快速地得到结果和看到的东西
• NHibernate非常强大--但这也使它更难学习;你必须非常非常喜欢尖括号汤（即大量的XMLMap文件）才能跟上NHibernate的速度

如果你没有使用ORM的经验，Linq to SQL比NHibernate更容易学习，它也有更好的与Visual Studio的集成。

我喜欢Linq to SQL，它非常容易使用。实现存储库模式，并使用LINQ to SQL作为您的存储库接口后面的第一个实现。您会发现使用该工具快速建立存储库是如此容易。您可以随时使用NHibernate实现第二个存储库，而不会中断您的应用程序，然后比较您使用这两个工具的体验。
NHibernate“更强大”......我想这意味着你可以用它来对付任何数据库，就这样。还有很多东西要学，如果你真的走这条路，确保你充分利用Fluent NHibernate来避免所有的Map垃圾。它比维护一堆XMLMap要干净得多。
我发现NHibernate令人沮丧，因为我喜欢用LINQ查询数据库，并投影（Map）到模型。我知道有一个LINQ到NHibernate浮动，但我不能说我知道任何人谁使用它。
一般来说，如果你喜欢按ID获取所有信息并从那里遍历对象模型，我会说使用NHibernate。一旦你想执行更复杂的查询，你最好做好一些挫折的准备。

LinqtoSQL应该被实体框架所取代;我认为NHibernate将是一个很好的选择，因为有很多参考文献，而且它似乎也被广泛使用。

除了达林的回答，考虑一下我早些时候读到的这篇文章。
Linq to SQL的实现和集成更容易、更快，但如果你需要更多的控制，Nhib可以给你更大的灵活性。最近，我不得不决定是否在我的新应用项目中使用Linq to SQL-我只是不喜欢缺乏灵活性。
NHibernate vs LINQ to SQLhttp://www.acceptedeclectic.com/2007/12/linq-to-sql-vs-nhibernate-part-1-what.html
如果有用就告诉我。