我在一家开发公司，其开发的中小型网络为基础的项目工作，我们主要使用微软的技术，目前我们在技术选型阶段，我们正在研究的ORM，我们需要选择标准的ORM我们未来的项目，现在我们缩小了选分为两个： -

•NHibernate的： -

成熟。 开启源。 丰富的功能。 配置和灵活的，最高的延伸。 将一个强大的社区很好的支持。 证明是成功的很多地方。

•的EntityFramework： -

在微软的产品;这意味着紧密集成与其他Microsoft产品。 高度支持和丰富的资源网络，具有较强的社区网络。 在不断发展的速度非常快，修复是走出非常快，它是由一天比一天好起来。 LINQ。 比NHibernate的降低学习曲线。

该技术是根据测得的以下分别： -

易于使用 - 时间真的在我们的项目中一个关键的事情 在长期的决定，我意味着我们不打算 保持技术之间进行切换。 在与微软产品集成。 支持，在合规性工具（如ActiveRecord的对NHibernate的），社区和发行期限。 这将是我们将使用的唯一标准。 灵活的配置。 特点 - 我们并不需要很多复杂的映射，也没有二级缓存，我们可以与SP的替代配料现在。

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

不要误会我对这个错误的;我知道，NHibernate的是暂时的正确的答案，但会是在不久的将来正确的选择，甚至在遥远的未来，同时为考虑的EntityFramework的快速发展。

一些我一直依赖于与我的研究资源： -

http://ayende.com/blog/4351/ NHibernate的-VS-实体框架4-0

nhibernate,实体框架，活动记录或LINQ2SQL

Which ORM工具我应该使用.Net开发

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

解决方案   

我知道，NHibernate的是暂时的正确的答案，但   会是在不久的将来正确的选择，甚至远   未来，回吐考虑的EntityFramework的快速发展。

没人能回答这个问题。我相信，即使是ADO.NET队伍有问题，这是因为在这个时候，甚至有没有路线图将在未来实现的功能。此刻的发展过程由数据UserVoice的的大多驱动，也没有办法来知道哪些功能我们可以期待下个月，其特点我们可以期待明年，我们将永远不会有其特点。

没有正确的答案。而且整个标准化的过程中，你正在试图做的是错的。使用正确的解决方案为您当前的问题！选择单一的标准不管什么问题，你将不得不解决在将来不知道这个问题，不知道什么工具将在该时间内是一种愚蠢。

您的整个想法违背了敏捷性和对最佳实践。它甚至可以长到internal框架或SW工厂的。 .NET开发是高度动态的领域。今天有什么可以认为不错的选择可以pcated明年去$ P $所以不约束自己与标准。可以有更有趣的选择，在未来或在技术和实践（例如NoSQL数据库），更有趣的转变。

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

I’m working in a development company, which develops small to medium size web based projects, we mainly use Microsoft technology, currently we are in technology selection phase, and we are looking into ORMs, we need to select the standard ORM for our future projects, for now we narrowed the chooses into two: -

• Nhibernate: -

Mature. Open source. Feature rich. Configurable and flexible, to the highest extends. Well supported by a strong community. Proven to be successful many places.

• EntityFramework : -

A Microsoft product; which means tight integration with other Microsoft products. Highly Supported and plenty of resources online, with fairly strong communities online. Evolving very fast, fixes is coming out very fast and it is getting better day by day. LINQ. Lower learning curve than Nhibernate.

The technology is measured according to the following respectively: -

Ease of use - time is really a critical thing in our project. Long term decision, I’m mean we are not going to keep shifting between technologies. Integration with Microsoft products. Support, in term of compliance tools (such as activerecord for Nhibernate), communities and releases. It’ll be the only standards that we’ll use. Flexibility in configuration. Features - we don't require a lot of complex mapping, nor 2nd level caching, and we can replace batching with SPs for now.

My Questions Choosing Entity Framework against Nhibernate, as our company future default implementation of ORM, what are the cons and pros for such a decision in the long run?

Don’t get me wrong on this; I know that Nhibernate is the right answer for the time being, but will it be the right choice for the near future, or even the far future, taking is consideration the fast evolution of EntityFramework.

some of the resources I have relied on with my research: -

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

解决方案

I know that Nhibernate is the right answer for the time being, but will it be the right choice for the near future, or even the far future, taking is consideration the fast evolution of EntityFramework.

Nobody can answer this question. I believe even ADO.NET team would have problem with this because at this time there is even no road map for features that will be implemented in the future. At the moment the development process is mostly driven by Data UserVoice and there is no way to know which features we can expect next month, which features we can expect next year and which features we will never have.

There is no right answer. Moreover whole "standardization" process you are trying to do is wrong. Use the right solution for your current problem! Selecting single "standard" for whatever problem you will have to solve in the future without knowing that problem and without knowing what tools will be available in that time is a stupidity.

Your whole idea goes against agility and against best practices. It can even grow to internal frameworks or SW factories. .NET development is highly dynamic area. What can be supposed good choice today can be deprecated next year so don't bind yourselves with "standards". There can be even more interesting choice in the future or more interesting shift in technology and practices (for example NoSql databases).

If you want long time strategic solution use mainframes and COBOL. They already proved their lifetime.