是否有充分的理由不使用 ORM? [英] Are there good reasons not to use an ORM?
问题描述
在我的学徒期间，我已经将 NHibernate 用于一些较小的项目，我主要使用我自己编码和设计.现在，在开始一些更大的项目之前，讨论了如何设计数据访问以及是否使用 ORM 层.因为我还在学徒期，仍然认为自己是企业编程的初学者，所以我并没有真正尝试推动我的观点，即使用对象关系映射器到数据库可以大大简化开发.开发团队的其他程序员都比我有经验，所以我想我会按照他们说的去做.:-)
During my apprenticeship, I have used NHibernate for some smaller projects which I mostly coded and designed on my own. Now, before starting some bigger project, the discussion arose how to design data access and whether or not to use an ORM layer. As I am still in my apprenticeship and still consider myself a beginner in enterprise programming, I did not really try to push in my opinion, which is that using an object relational mapper to the database can ease development quite a lot. The other coders in the development team are much more experienced than me, so I think I will just do what they say. :-)
然而，我并不完全理解不使用 NHibernate 或类似项目的两个主要原因:
However, I do not completely understand two of the main reasons for not using NHibernate or a similar project:
- 您只需使用 SQL 查询构建自己的数据访问对象，然后从 Microsoft SQL Server Management Studio 中复制这些查询即可.
- 调试 ORM 可能很困难.
所以，当然我可以用很多 SELECT 等来构建我的数据访问层，但在这里我错过了自动连接、延迟加载代理类和较低维护工作的优势如果一个表有一个新列或一个列被重命名.(更新大量 SELECT、INSERT 和 UPDATE 查询与更新映射配置并可能重构业务类和 DTO.)
So, of course I could just build my data access layer with a lot of SELECTs etc, but here I miss the advantage of automatic joins, lazy-loading proxy classes and a lower maintenance effort if a table gets a new column or a column gets renamed. (Updating numerous SELECT, INSERT and UPDATE queries vs. updating the mapping config and possibly refactoring the business classes and DTOs.)
此外，如果您不太了解框架，使用 NHibernate 可能会遇到无法预料的问题.例如，这可能是信任 Table.hbm.xml，您将字符串的长度设置为自动验证.但是，我也可以想象在基于简单"SqlConnection 查询的数据访问层中存在类似的错误.
Also, using NHibernate you can run into unforeseen problems if you do not know the framework very well. That could be, for example, trusting the Table.hbm.xml where you set a string’s length to be automatically validated. However, I can also imagine similar bugs in a "simple" SqlConnection query based data access layer.
最后，上面提到的那些论点真的是不将 ORM 用于基于非平凡数据库的企业应用程序的一个很好的理由吗?他们/我可能错过了其他争论吗?
Finally, are those arguments mentioned above really a good reason not to utilise an ORM for a non-trivial database based enterprise application? Are there probably other arguments they/I might have missed?
(我可能应该补充一点，我认为这就像第一个需要团队合作的大型"基于 .NET/C# 的应用程序.良好的实践，在 Stack Overflow 上被视为很正常，例如单元测试或持续集成, 直到现在这里都不存在.)
(I should probably add that I think this is like the first "big" .NET/C# based application which will require teamwork. Good practices, which are seen as pretty normal on Stack Overflow, such as unit testing or continuous integration, are non-existing here up to now.)
推荐答案
近年来 ORM 呈爆炸式增长，您更有经验的同事可能仍在思考每个数据库调用都应该通过存储过程"心态.
There's been an explosion of growth with ORMs in recent years and your more experienced coworkers may still be thinking in the "every database call should be through a stored procedure" mentality.
为什么 ORM 会使调试变得更难?无论它来自存储过程还是来自 ORM，您都会得到相同的结果.
Why would an ORM make things harder to debug? You'll get the same result whether it comes from a stored proc or from the ORM.
我想我能想到的使用 ORM 的唯一真正不利之处是安全模型的灵活性稍差.
I guess the only real detriment that I can think of with an ORM is that the security model is a little less flexible.
我刚刚重新阅读了您的问题，看起来他们正在将查询复制并粘贴到内联 sql 中.这使得安全模型与 ORM 相同，因此与 ORM 相比，这种方法绝对没有优势.如果他们使用未参数化的查询，那么实际上存在安全风险.
I just re-read your question and it looks they are copy and pasting the queries into inline sql. This makes the security model the same as an ORM, so there would be absolutely no advantage over this approach over an ORM. If they are using unparametrized queries then it would actually be a security risk.
这篇关于是否有充分的理由不使用 ORM?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
