在我的学徒期间，我使用过NHibernate http://nhibernate.org/对于一些较小的项目，这些项目主要是我自己编码和设计的。现在，在开始一些更大的项目之前，讨论了如何设计数据访问以及是否使用 ORM 层。由于我仍处于学徒期，并且仍然认为自己是企业编程的初学者，因此我并没有真正尝试推动我的观点，即使用数据库的对象关系映射器可以大大简化开发。开发团队中的其他程序员比我更有经验，所以我想我会按照他们说的去做。 :-)
然而，我并不完全理解不使用 NHibernate 或类似项目的两个主要原因：
- 人们可以使用 SQL 查询构建自己的数据访问对象，并将这些查询复制到 Microsoft SQL Server Management Studio 之外。
- 调试 ORM 可能很困难。
所以，当然我可以用很多东西来构建我的数据访问层SELECT等，但在这里我错过了自动连接、延迟加载代理类的优点，以及在表获得新列或重命名列时较低的维护工作量。 （更新众多SELECT, INSERT and UPDATE查询与更新映射配置以及可能重构业务类和 DTO。）
另外，如果您不太了解 NHibernate 框架，那么您可能会遇到无法预见的问题。例如，这可能是信任 Table.hbm.xml，您在其中设置要自动验证的字符串长度。然而，我也可以想象在基于“简单”SqlConnection 查询的数据访问层中存在类似的错误。
最后，上面提到的这些论点真的是不将 ORM 用于基于数据库的企业应用程序的好理由吗？他们/我可能错过了其他论点吗？
（我可能应该补充一点，我认为这就像第一个基于 .NET/C# 的“大型”应用程序，需要团队合作。良好的实践在 Stack Overflow 上被视为非常正常，例如单元测试或持续集成，但它们并不适用。 -到目前为止还存在。）
简短的回答是肯定的，确实有充分的理由。事实上，在某些情况下您无法使用 ORM。
举个例子，我在一家大型企业金融机构工作，我们必须遵循很多安全准则。为了满足我们的规则和规定，通过审核的唯一方法是将数据访问保留在存储过程中。现在有些人可能会说这简直是愚蠢的，但老实说事实并非如此。使用 ORM 工具意味着工具/开发人员可以插入、选择、更新或删除他或她想要的任何内容。存储过程提供了更高的安全性，特别是在处理客户端数据的环境中。我想这是最值得考虑的原因。安全。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
