ADO.NET实体框架和NHibernate - 何时使用其中一个

Question

我在Microsoft .NET商店工作，可以使用NHibernate或ADO.NET EF。当你应该选择一个而不是另一个时，我们应该使用什么指导？

例如，似乎在编写Silverlight应用程序时，EF-to-＆gt; ADO.NET数据服务-to-＆gt; Silverlight可以提高工作效率，并为您提供REST服务API，无需额外工作。

还有哪些其他内容可以帮助您按应用指导应用？

更新（根据评论）： 这一个稍微有用What differentiates Nhibernate from other ORM’s?其他人进入奇怪的切线（如SubSonic）并且不直接比较两者。我想我是专门寻找使用两者的人，并根据项目决定他们将使用哪个项目。

Answer 1

简而言之，EF没有开箱即用的Persistence Ignorance支持。当我去年第一次尝试使用EF构建解决方案时，我有点恼火，你不能在你的应用程序中使用POCO。我想要与我的模型更高程度的解耦，所以我最终切换到NHibernate。从那以后，有人写了一个EF POCO适配器。 http://code.msdn.microsoft.com/EFPocoAdapter - 但它实际上只是一个代码生成器，它生成一个适配器层来映射对象。

出于某种原因，我的应用程序也在NHibernate下运行得更快。拿着那粒盐，因为我不熟悉配置任何一种解决方案。

Answer 2

Microsoft最近开始开发一种名为.NET Ria Services的新解决方案（目前为止），该解决方案将“独立于ORM”，用于从服务器上的业务逻辑层获取和退出Silverlight。

他们已经公开提到（在MIX的幻灯片上，甚至），这里将支持NH 。

如果您正在寻找拥有最多社区支持的解决方案，那么NHibernate绝对是答案。我承认它有一个陡峭的学习曲线，但根据我的经验，它肯定是值得的。只需对“实体框架”和“nhibernate”进行比较搜索，您就会明白我的意思。大多数EF的东西将是“按下”，而NHibernate的东西实际上将是技术性的，血腥的细节。还有问题。回答。

但正如其他海报所提到的那样 - 我确信实体框架会随着时间的推移而改善。但就目前而言，我相信他们正试图用一个工具集解决太多问题。 NHibernate只做了一件事，但做得非常好。

这里还有应用程序设计的问题。 EF似乎（目前的化身）是为了向C＃应用程序提供数据库而构建的。 NHibernate采用另一种方式，可以更容易地保持对象模型的持久性。

Answer 3

我现在可能完全避开实体框架。有vote of no confidence给出了famework，更不用说它不像NHibernate那样成熟。

话虽如此，我会继续评估实体框架，因为我相信它会随着时间的推移而得到改善。