选择实体框架作为Nhibernate，cons和pros的默认实现ORM？

Question

我在开发公司，开发中小型基于Web的项目，我们主要使用Microsoft技术，目前我们处于技术选择阶段，我们正在研究ORM，我们需要选择标准ORM对于我们未来的项目，现在我们将选择范围缩小为两个： -

•Nhibernate： -

1. 成熟。
2. 开源。
3. 功能丰富。
4. 可配置且灵活，达到最高范围。
5. 得到强大社区的支持。
6. 事实证明，许多地方都取得了成功。

•EntityFramework： -

1. Microsoft产品;这意味着与其他Microsoft产品紧密集成。
2. 在线拥有高度支持和丰富的资源，在线社区相当强大。
3. 进展非常快，修复速度非常快，并且日益好转。
4. LINQ。
5. 比Nhibernate更低的学习曲线。

该技术分别按以下方法测量： -

1. 易于使用 - 在我们的项目中，时间确实是一件至关重要的事情。
2. 长期决定，我的意思是我们不会这样做 不断在技术之间转换。
3. 与Microsoft产品集成。
4. 支持，包括合规工具（如Nhibernate的activerecord），社区和发布。
5. 这将是我们将使用的唯一标准。
6. 配置灵活。
7. 功能 - 我们不需要很多复杂的映射，也不需要二级缓存，我们现在可以用SP替换批处理。

我的问题选择针对Nhibernate的实体框架，作为我们公司未来的ORM默认实施，从长远来看，这样的决定有什么缺点和优点？

不要误会我的意思;我知道Nhibernate暂时是正确的答案，但它是不久的将来，甚至远期未来的正确选择，考虑到EntityFramework的快速发展。

---

我赖以研究的一些资源： -

http://ayende.com/blog/4351/nhibernate-vs-entity-framework-4-0

NHibernate, Entity Framework, active records or linq2sql

Which ORM tool should I use for .Net development

http://blogs.msdn.com/b/adonet/archive/2012/03/22/ef5-beta-2-available-on-nuget.aspx

Answer 1

  

我知道Nhibernate暂时是正确的答案，但是   它是不久的将来，甚至是远方的正确选择   未来，考虑到EntityFramework的快速发展。

没人能回答这个问题。我相信即使是ADO.NET团队也会遇到这个问题，因为此时甚至还没有将来会实现的功能的路线图。目前，开发过程主要由Data UserVoice驱动，并且无法知道下个月我们可以预期哪些功能，明年我们可以预期哪些功能以及我们永远不会拥有哪些功能。

---

没有正确答案。而且你想要做的整个“标准化”过程是错误的。为您当前的问题使用正确的解决方案！为将来必须解决的问题选择单一的“标准”而不知道该问题，并且不知道那时候可用的工具是愚蠢的。

您的整个想法违背了敏捷性和最佳做法。它甚至可以增长到internal frameworks or SW factories。 .NET开发是一个高度动态的领域。今天可以被认为是好的选择可以在明年被弃用，所以不要用“标准”来约束自己。未来可能会有更有趣的选择，或者技术和实践中更有趣的转变（例如NoSql数据库）。

如果您想要长时间的战略解决方案，请使用大型机和COBOL。他们已经证明了自己的一生。

Answer 2

我建议您在做出决定时，立即专注于NHibernate和EF提供的功能。查看您必须提出的精确要求，并将它们与ORM进行匹配。在上面的问题中，您应该注意到也可以对NHibernate执行linq查询。此外，您已经满足了对二级缓存的需求。如果您正在寻找一个长期灵活的平台，您一定要考虑到它。