2

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

• 休眠：-

  1. 成熟。
  2. 开源。
  3. 功能丰富。
  4. 可配置且灵活，达到最高水平。
  5. 得到强大社区的大力支持。
  6. 在很多地方都证明是成功的。

• 实体框架：-

  1. 微软产品；这意味着与其他 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

4

2 回答 2

9

我知道 Nhibernate 暂时是正确的答案，但考虑到 EntityFramework 的快速发展，它是否是近期甚至远期的正确选择。

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

没有正确的答案。此外，您尝试执行的整个“标准化”过程是错误的。为您当前的问题使用正确的解决方案！为将来必须解决的任何问题选择单一的“标准”，而不知道那个问题，也不知道当时有哪些工具可用，这是愚蠢的。

您的整个想法与敏捷性和最佳实践背道而驰。它甚至可以发展为内部框架或软件工厂。.NET 开发是高度动态的领域。今天可以认为是好的选择明年可能会被弃用，所以不要用“标准”束缚自己。未来可能会有更有趣的选择，或更有趣的技术和实践转变（例如 NoSql 数据库）。

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

于 2012-04-12T08:27:02.877 回答
1

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

于 2012-04-12T08:52:11.023 回答