帮我根据以下内容在linq to sql和nhibernate之间进行选择

Question

在选择linq2sql和nhibernate之间苦苦挣扎。

让我以点的形式给你一些关于应用的见解：

• 这是一个asp.net mvc应用程序

• 它会有很多表，可能是50-60（sql server 2008）

• 我希望为我完成所有基本的crud逻辑（我认为nhiberate + repository pattern可以给我）

• 我没有太复杂的映射，我的表格看起来像：

用户（userID，用户名） UserProfile（userID，...） 内容（contentID，标题，正文，日期） Content_User（contentID，userID）

所以在 general 中，我将有一个PK表，然后是许多引用该PK的其他表（即FK表）。 我还将有很多映射表，其中包含PK，FK对。

实体明智，我想要User.cs，UserProfile.cs，然后加载每个对象。 我不是在寻找具有UserProfile属性和Content Collection属性的User类（可能会有10-20个与用户相关的表，我只想保持线性，如果有意义的话）。

让我学习nhibernate的一件事是：交叉数据库潜力，以及几乎可以立即在我所有主表中提供基本数据库操作的存储库模式！

Answer 1

因为你似乎有一个非常直接的从一个类到另一个表的映射，Linq到SQL应该可以做到这一点，没有任何困难。这样可以让您快速入门，而无需将域手动映射到数据库的初始工作。

另一种选择可能是使用NHibernate + Fluent NHibernate及其AutoMapping功能，但请记住，Fluent NHibernate AutoMapping还很年轻。

我不太确定我理解你希望你的实体看起来像什么，但是使用Linq to SQL你会得到一个很大的混乱，你可以通过使用部分类来扩展它。 NHibernate允许您根据需要设计类，并且不会为您生成任何开箱即用的内容。您可以使用Linq to SQL的POCO类，但这会消除使用Linq to SQL而不是NHibernate的所有好处。

关于存储库模式和通用存储库的使用，可以很好地完成Linq to SQL，而不仅仅是NHibernate。在我看来，这是Linq to SQL的好处之一。

如果您可能需要支持除SQL Server之外的其他数据库，NHibernate是唯一的选择。但是，如果它可能不是问题，我建议不要在选择时使用它作为主要因素。其他因素可能会更多地影响您的项目。

<强>结论：

总而言之，在这种情况下，我会建议Linq to SQL，因为它可以让您快速入门并且足以满足您的需求。这样做的前提条件是，您在域中生成混乱代码的想法没有问题，并且您确信将来不再需要支持其他数据库。否则我会推荐NHibernate，因为它确实是一个很棒的ORM。

Answer 2

linq2sql真的希望你每个类映射使用1个表。因此，如果您有UserMaster和UserDetail表，那么在使用默认的linq对象生成时，您正在查看两个对象。您可以通过将linq实体映射到业务实体来解决这个问题（请参阅Rob Conery的storefront screencasts），然后您将回到编写对象映射代码或使用类似Automapper的东西。

如果您希望能够跨多个表拆分类，那么我会说NHibernate。如果没有，那么linq的学习曲线较低。

Answer 3

我通过Castle Project的ActiveRecord库使用nHibernate的唯一方法。否则，nHibernate将成为自己的小型基础架构项目。查看一些questions in the nHibernate tag，看看我在说什么。

我唯一可以改变的是将SELECT操作的结果作为List而不是T []返回。当然，使用C＃中的源代码，如果需要，我可以这样做。

使用ActiveRecord，映射信息将保存在您用类修饰的属性中。它是天才，我是模式和这个特殊库的巨大支持者。