评估ORM for .NET的标准是什么？[关闭]

我正在评估ORM。

我使用了SubSonic，Linq-to-SQL和Entity Framework。我有一个从初级到高级的开发人员团队。

评估ORM for .NET的标准是什么？

这是一个充满挑战的问题。
有很多非常好的ORM都以不同的哲学来对待这个主题。
没有一个是完美的，一旦您偏离了他们的黄金之路，它们都会变得复杂（有时甚至坚持下去）。

选择ORM时应问自己的问题：

1. 它需要为您做什么？
   如果您已经对应用程序有一组要求，那么应该选择更适合这些要求的ORM，而不是假设的“最佳”。

2. 您的数据是共享的还是仅本地的？
   ORM中的许多繁琐工作是由于当多个用户持有相同数据的版本时，它们如何处理并发和对数据库中数据的更改而引起的。
   如果您的数据存储区是供单用户使用的，那么大多数ORM都会做得很好。但是，在多用户方案中，请问一些难题：如何处理锁定？删除对象会怎样？它如何影响其他相关对象？ORM是在后端金属附近工作还是在缓存大量数据（提高性能却以增加陈旧风险为代价）。

3. ORM是否适合您的应用程序类型？ 如果特定的ORM用于服务中或位于Web应用程序内部，则可能难以使用（很多性能开销，难以编写代码）。相反，它对于桌面应用程序可能很棒。

4. 您是否必须放弃特定于数据库的增强功能？
   ORM倾向于使用SQL的最低公分母集来确保它们与许多不同的数据库后端一起工作。
   所有ORM都会在可用功能上进行折衷（除非它们专门针对单个后端），但是某些ORM允许您实施其他行为以利用所选后端中可用的特定增强功能。
   典型的特定于数据库的增强功能是例如全文搜索功能；确保您的ORM在需要时为您提供了一种访问这些功能的方法。

5. ORM如何管理数据模型中的更改？
   有些可以在一定范围内自动更新数据库，有些则什么也不做，您将不得不自己做一些肮脏的工作。其他提供了用于处理更改的框架，使您可以控制数据库更新。

6. 您是否打算将应用程序耦合到ORM的对象，还是希望处理POCO并为持久性使用用户适配器？
   前者通常易于处理，但会在各地随处创建特定于ORM的数据对象的依赖关系，后者则更为灵活，但需要花费更多代码。

7. 您是否需要远程传输对象？
   从远程服务器获取对象时，并不是所有的ORM都是平等的，请仔细研究可能或不可能做什么。有些有效，有些则没有。

8. 您可以找人帮助吗？
   是否有良好的商业支持？项目周围的社区有多活跃？
   现有用户使用该产品有哪些问题？
   他们有快速的解决方案吗？

我看过的一些ORM：

• 
  来自Developer Express的XPO：小巧，简单，以代码为中心。他们将其用于应用程序框架eXpressApp。
• NHibernate
  是免费的，但是学习曲线相当陡峭。很多东西，但是有时在所有零散的文档中很难找到真正相关的东西。
• LLBLGen Pro
  非常成熟的项目，不是最简单的，但是已经考虑了很多。
• 实体框架
  在那里。尽管与其他更成熟的ORM相比，它还有些年轻，但最后一个版本非常好，MS正在监听。
• DataObject.Net
  看起来很有前途，但对于IMHO上的重要项目来说，这也是一个新风险。虽然很活跃。

当然还有很多其他的。

您可以查看有争议的网站ORM Battle，其中列出了一些性能基准，尽管您必须知道原始速度不一定是项目的最重要因素，并且网站的生产者是DataObject.Net。

我正在使用NHibernate，并且发现它相当不错。

就我而言，链接到MS Sql数据库，但是您可以连接到其他数据库。

不需要花很长时间就可以启动并运行-只需将您的对象映射到模型-我使用xml文件，但是您可以在代码中流畅地做到这一点。有一个很棒的社区，而且我个人发现Ayende的工作非常有帮助-我使用NHProf（这是一个SQL分析工具）。

我主要使用开箱即用的功能-直接对象映射，但是我也使用了Hibernate Query Language，这很容易掌握。

可悲的是，在我的前三份工作中，我们有三个本地ORM。在每种情况下，它们大多是出于各种原因而吮吸。

我最近一直在评估Entity Framework 4及其对POCO的支持（这里是一个不错的演练），并给我留下了深刻的印象，那就是它很好地掩盖了我的脸，使我感到自己像在重新编程，而不是聚集数据。

ORMBattle.NET上的ORM比较和基准

我非常喜欢Linq to Sql。它很简单，并且有一个不错的设计师。但是，我希望生命周期结束时支持实体框架。我希望能够利用修改生成器的能力，以便可以拥有定制的对象。

这些工具相对于其他工具的最大好处（我认为）是它们与VS兼容。这也是负面的，因为您受制于MS（请参阅Linq to Sql）。

[免责声明：我为DevExpress工作]

您可以在此处查看由DevExpress应用程序框架创建的典型应用程序的屏幕截图。此页面还包含对我们产品的非常简短的评论。有关为什么的更多详细信息，建议您在我们的网站上查看相应的产品页面。

对于DevExpress XAF和XPO，这很好地解释了为什么选择我们的应用程序框架。另外，我们提供支持和文档，这也很重要，值得一提。如有任何疑问，请随时与我们联系。

我们在小型项目上使用NHibernate + Fluent NHibernate和Linq-to-Sql。原因是：

1）（不是主要原因）NHibernate在开发人员中似乎具有更高的“尊重”因素（是真的吗？），

2）与linq-to-SQL相比，nHibernate允许Db对象与不一对一映射的实体之间进行ORM映射，

3）我们尚未将nHibernate与Entity Framework 4.0进行广泛比较，但这是一个很好的比较： http //ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate确实有一些陡峭的学习曲线，其XML映射可能非常冗长，但是从Fluent Nhibernate网站文档开始，然后逐步进行。

没有一个“最佳”的ORM框架，因为它们都有长处和短处的不同组合，并且往往会出现这样的情况：如果开发人员选择专注于使一个领域变得更好，那么在比较中还有其他领域（代码优先vs首先是模型还是数据库）。

另一方面，还有很多非常好的，其中一些会比其他人更适合您的个人情况和哲学。

编辑：对于它的价值，我目前正在使用Linq to SQL-主要是因为它在那里，部分原因是它以最小的努力做了很多正确的工作，并且很可能会再次“因为它在那里”而前进到Entity Framework（尽管类似地，有关EF4的很多知识，以及一些错误的知识）。关注点（尤其是后者）必须是性能，但在我的大多数情况下，这并不是一个大问题，并且能够从模型（L2S和EF）运行动态数据和OData的能力对我而言具有可观的收益，便宜”获胜。

我建议您看一下DevExpress XPO。一旦跨越了学习曲线，它与DevExpress XAF一起将使任何开发人员的生活变得轻松。

我们在实体框架方面万事如意。但是，我们的情况有些不同寻常-我们为报告团队进行数据收集，因此他们实际上是在设计数据库。我们得到数据库，然后仅使用EF从中生成数据访问类。对我们来说效果很好，但是我们只是进行批量数据加载，因此我不能保证它在更具事务性的环境中的表现如何。

NHibernate（+ FluentNHibernate）将是我的默认选项。它非常灵活，可扩展且健壮。它拥有大量的用户，并且非常积极地维护着它。不利的一面是陡峭的学习曲线。

MindScape的LightSpeed简单易用，但仍然相当灵活且功能强大。它具有L2S / EF之类的设计器图面和UnitOfWork实现。

好吧，没有“最佳”选择，但是我要说的是，常规的旧Linq to SQL可以满足您的需求。它本身不是一个“真正的” ORM，但是它非常轻巧，并且可以让您灵活地编写代码而无需意识到。我的意思是，您可以继续正常编写代码，而不必真正拥有Linq而不是拥有dbml文件。您仍然可以使用存储库或网关模式在其上编写抽象，并且L2S发挥ORM的主要作用，即避免对象关系不匹配。

实体框架有点沉重，虽然我只涉猎了一点，但它比基本的Linq to Sql更“令人难忘”，但是EF比Linq更像是一个真正的ORM。我将查看您在ORM中寻找的所有条件。仅仅是因为您要避免编写原始SQL，或者更糟的是要拥有数百个存储过程？您是否需要原始Linq to Sql无法提供的一些额外功能？您需要回答这些问题，但是基于您的简短要求（“轻便且易于使用”），我认为Linq比Subsonic之类的产品要容易一些，并且内置于Visual Studio中。

ECO :)它不仅包括一个ORM，还包括状态机和可执行的OCL（即EAL）支持。有一个免费版本，其中包含12个域类限制，对于小项目，我认为它应该很简洁。