选择实体框架作为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,实体框架,活动记录或linq2sql

我应该使用哪种ORM工具进行.Net开发

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驱动,并且无法知道下个月我们可以预期哪些功能,明年我们可以预期哪些功能以及我们永远不会拥有的功能.

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

你的整个想法违背了敏捷性和最佳实践.它甚至可以发展到内部框架或SW工厂..NET开发是一个高度动态的领域.今天可以被认为是好的选择可以在明年被弃用,所以不要用"标准"来约束自己.未来可能会有更有趣的选择,或者技术和实践中更有趣的转变(例如NoSql数据库).

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