商务人士的 ORM 和 NH答案

【问题标题】：ORM and NH for business people商务人士的 ORM 和 NH
【发布时间】：2010-08-03 18:00:00
【问题描述】：

我必须准备一个案例来说服经理使用 ORM 来促进开发。在这种情况下，我不想详细介绍技术细节，好处必须对业务人员可见。

到目前为止，我对自己写下的论点不太满意。有没有我忘记的要点，无论是 PRO 还是 CONTRA？

我要说明的情况有两点：

说服经理使用 ORM
说服经理使用 NHibernate

ORM 的专业人士：

解决具有行为的连接对象的丰富生态系统与标量值的表格列表之间的阻抗不匹配
更高的工作效率 => 减少编写繁琐的数据访问代码的时间，让您更专注于解决“真正的”业务问题
更高的可维护性 => 减少 LOC 的数量 == 系统更容易理解（嗯……也许……）
正确使用几乎不会影响性能

ORM 的 CONTRA：

O/R 映射工具在批量处理数据时表现不佳。存储过程可能具有更好的性能，但不可移植
严重依赖 ORM 软件已被认为是产生设计不佳的数据库的主要因素

NH 的专业人士：

非常成熟的产品
支持许多 DB => 开发人员不必在每个其他项目中学习新的 SQL 方言
在 .net 社区领导者中的高度评价
许多示例、文章、博客文章
它是开源的

NH 的 CONTRA：

根本不适合批处理
没有代码生成或代码设计器 => 有些人认为这可以提高开发人员的工作效率
由于延迟编码导致声誉不佳（== 滥用延迟加载）
不是来自 Microsoft
它是开源的 => 有些公司就是不喜欢它

【问题讨论】：

"•正确使用时几乎不会影响性能" 几乎从来没有正确使用。

标签： nhibernate

【解决方案1】：

商务人士通常会考虑成本和可交付成果。除此之外，大多数人并不了解或关心技术原因。

您已经提到了更高的生产力方面。尝试将其表述为在业务规则上花费更多时间，而在重复性 CRUD 代码上花费更少时间。

我要添加并突出显示：

较低的开发摩擦使满足最后期限更容易
减少使用数据库的开发成本
降低维护成本
NHib 是灵活的；可以自动处理对象映射，并在需要时允许特定的查询/存储过程

还可以查看Fluent NHibernate 和Fluent Migrator。

【讨论】：

【解决方案2】：

其实我想反驳一些负面观点。

O/R 映射工具在数据批量处理方面表现不佳。存储过程可能有更好的性能，但不可移植

NH 对批量数据处理进行了许多优化（首先想到的是批处理和缓存）。在某些情况下，您始终可以添加存储过程，这不是“全有或全无”的建议。

严重依赖 ORM 软件被认为是产生设计不佳的数据库的主要因素

我实际上看到了相反的情况：所谓的优化 DB-first 设计在实现实际用例时就会崩溃。无论如何，这是开发人员的失败；无论有没有 ORM，你都可以做得很差

根本不适合批处理

绝对不是真的。 NH 具有许多专门为批处理而设计的功能，例如无状态会话。当然，在 DB 服务器中运行的 SP 的性能很难超越，但除此之外，它通常与 adhoc ADO.NET 代码一样好。

没有代码生成或代码设计器

错误。有几种产品可以提供这一点。检查http://nhforge.org/wikis/general/commercial-product-ecosystem.aspx

由于懒惰的编码而声誉不佳

如果您执行 SELECT * FROM TABLE，它的性能也会很差。我不明白 NH 应该受到怎样的责备。

不是来自微软

甲骨文、iPod 或宝马都不是，但人们使用它们

它是开源的

提供商业支持。而且，与 MS 产品不同的是，支持由了解内部结构的人员提供，并且可以在几个小时而不是几年内修复它们。

【讨论】：

喜欢您的回复。感谢这些论点。

【解决方案3】：

当您的经理决定您必须使用哪种技术时，您的经理应该能够理解技术原因。否则，他应该相信开发人员（他们有知识做出决定）来决定。对于经理来说，我能想出比做出他不够了解的技术决策更有用的事情。

当你的老板像呆头呆脑的尖头老板时，我会选择节省时间和金钱的论据（对于经理想要参与的每一个技术决策）。

【讨论】：

【解决方案4】：

看看this list of features of a real-world ORM。对于任何重要的项目，您将最终会使用 80% 以上的这些功能。因此，您可以自己构建这些功能，也可以使用 NHibernate。如果您选择自己构建它，请准备好投资$7.5M and 140 person years。或者您可以只使用 NHibernate，节省金钱和精力，并从网络、书籍、社区等提供的庞大知识库中受益，甚至使用（如有必要）可用的高质量商业支持提供商之一。

【讨论】：

【解决方案5】：

您需要用时间和金钱来表达——对开发和维护时间的影响以及对用户时间的影响。 ORM 的使用往往是导致系统性能不佳（并且现在在设计路径上改变太远）的原因，因此您需要向管理人员说明您打算如何避免这样做。坦率地说，与糟糕的 ORM 实施所浪费的用户时间相比，开发时间和维护时间是微不足道的。是的，可以正确地避免这种情况，但通常不是。这通常是因为使用 ORM 的开发人员不了解数据库，也不想了解数据库。 ORM 在数据库专家手中，好事，ORM 在不会写基本 SQL 甚至连联接都不懂的应用程序程序员手中，灾难等着发生。

【讨论】：

【解决方案6】：

没有代码生成或代码设计器

正如 Diego 所指出的，存在第三方工具。但是，我想强调的是，不必使用设计器是 NHibernate 的优势。设计师通常不会通过以下方式进行扩展：

当应用程序有很多很多实体时，设计图面有什么用？视觉设计师只会在这一点上用噪音减慢你的速度。
设计人员通常会遇到合并问题。当一次只有一名开发人员需要编辑模型时，它们的效果很好。项目中的开发人员越多，合并设计器文件的潜在麻烦就越大。

【讨论】：