ORM和NH为商务人士

时间:2010-08-03 18:00:00

标签: nhibernate

我必须准备一个案例来说服管理者使用ORM促进发展。在这种情况下,我不想深入了解技术细节,商业人士可以看到这些好处

我对我直到现在写下的论点不太满意有没有我忘记的观点,包括PRO和CONTRA?

我要提出的案例将分为两点:

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

ORM的PRO:

  • 解决连接对象的丰富生态系统与行为和标量值的表格列表之间的阻抗不匹配
  • 更高的生产力=>缩短编写繁琐的数据访问代码的时间可以让您更专注于解决“真正的”业务问题
  • 更高的可维护性=>减少LOC ==系统的数量更容易理解(嗯......也许......)
  • 使用正确
  • 时几乎没有性能损失

ORM的CONTRA:

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

PRO的NH:

  • 非常成熟的产品
  • 支持很多DB =>开发人员不必在每个其他项目上学习新的SQL方言
  • .net社区领袖的高度分享
  • 许多示例,文章,博客文章
  • 它是开源的

对于NH的CONTRA:

  • 完全不适合批量处理
  • 无代码生成或代码设计器=>有些人认为这可以提高开发人员的工作效率
  • 由于懒惰编码而导致声誉不佳(==滥用延迟加载)
  • 不是来自Microsoft
  • 这是开源=>有些公司不喜欢那样

6 个答案:

答案 0 :(得分:4)

商务人士通常会考虑成本和可交付成果。除此之外,大多数人都没有掌握或关心技术原因。

您已经提到了更高的生产力方面..尝试说明在业务规则上花费更多时间,减少重复CRUD代码的时间。

我添加并突出显示:

  • 降低发展摩擦使会议期限更容易
  • 降低使用数据库所花时间的开发成本
  • 降低维护成本
  • NHib很灵活;可以自动处理对象映射,并在需要时允许特定的查询/存储过程

同时结帐Fluent NHibernateFluent Migrator

答案 1 :(得分:3)

我其实想要指责一些负面因素。

  

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产品不同的是,支持由知道内部人员的人提供,并且可以在几小时而不是几年内修复它们。

答案 2 :(得分:2)

当您的经理决定您必须使用哪种技术时,您的经理应该能够理解技术原因。否则,他应该相信开发人员(他们有决定的知识)来决定。我可以为管理者考虑更多有用的东西,而不是做出他不够了解的技术决策。

如果你的老板就像Dilberts尖头发的老板,我会花时间和省钱的论点(对于经理想要参与的每一项技术决定)。

答案 3 :(得分:2)

看看this list of features of a real-world ORM。对于任何非平凡的项目,您最终使用这些功能的80%以上。因此,您可以自己构建这些功能,也可以使用NHibernate。如果您选择自己构建,请准备投资$7.5M and 140 person years。 或者您可以使用NHibernate,节省资金和精力,并从网络,书籍,社区等方面的庞大知识库中受益,甚至可以使用(如有必要)高质量的商业支持提供商。< / p>

答案 4 :(得分:1)

您需要在时间和金钱方面表达它 - 对开发和维护时间的影响以及对用户时间的影响。 ORM的使用常常是导致系统在性能不佳时陷入困境的原因(现在在设计路径上的变化太远),所以你需要向管理者说明你打算如何避免这样做。坦率地说,开发时间和维护时间都是花生,相比之下浪费的用户来自糟糕的ORM实施时间。是的,可以正确地做到这一点,但通常不是这样。这通常是因为使用ORM的开发人员不了解数据库而不想理解数据库。 ORM掌握在数据库专家手中,好东西,ORM掌握在一个无法编写基本SQL的应用程序员手中,谁甚至不了解连接,灾难等待发生。

答案 5 :(得分:1)

  

无代码生成或代码设计器

正如迭戈所指出的,还有第三方工具。但是,我想强调的是,不必使用设计师是NHibernate的优势。设计师通常不会通过以下方式进行扩展:

  • 当应用程序有许多实体时,设计界面有什么用处?视觉设计师只会让你在那时减慢噪音。
  • 设计师通常会遇到合并问题。当只有一个开发人员需要一次编辑模型时,它们工作得很好。您对项目的开发人员越多,合并设计器文件的麻烦就越大。