C# 是否有充分的理由不使用 ORM？

Are there good reasons not to use an ORM?

提问by hangy

During my apprenticeship, I have used NHibernatefor 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用于一些较小的项目，这些项目主要是我自己编码和设计的。现在，在开始一些更大的项目之前，讨论了如何设计数据访问以及是否使用 ORM 层。因为我还在学徒期，仍然认为自己是企业编程的初学者，所以我并没有真正尝试推动我的观点，即使用对象关系映射器到数据库可以大大简化开发。开发团队的其他程序员都比我有经验，所以我想我会按照他们说的去做。:-)

However, I do not completely understand two of the main reasons for not using NHibernate or a similar project:

但是，我并不完全理解不使用 NHibernate 或类似项目的两个主要原因：

1. One can just build one's own data access objects with SQL queries and copy those queries out of Microsoft SQL Server Management Studio.
2. Debugging an ORM can be hard.

1. 您可以使用 SQL 查询构建自己的数据访问对象，然后从 Microsoft SQL Server Management Studio 中复制这些查询。
2. 调试 ORM 可能很困难。

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, INSERTand UPDATEqueries vs. updating the mapping config and possibly refactoring the business classes and DTOs.)

所以，当然我可以只用很多SELECTs 等来构建我的数据访问层，但是在这里我错过了自动连接、延迟加载代理类的优势以及如果表获得新列或列获得的较低维护工作更名。（更新大量SELECT,INSERT和UPDATE查询与更新映射配置并可能重构业务类和 DTO。）

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.

此外，如果您不太了解框架，使用 NHibernate 可能会遇到无法预料的问题。例如，这可能是信任 Table.hbm.xml，您可以在其中设置要自动验证的字符串长度。但是，我也可以想象在“简单”的基于 SqlConnection 查询的数据访问层中存在类似的错误。

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?

最后，上面提到的这些论点真的是不将 ORM 用于基于数据库的非平凡企业应用程序的一个很好的理由吗？他们/我可能错过了其他论点吗？

(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.)

（我应该补充一点，我认为这就像第一个需要团队合作的“大型”基于 .NET/C# 的应用程序。在 Stack Overflow 上被视为非常正常的良好实践，例如单元测试或持续集成，是非- 一直存在在这里。）

采纳答案by Giovanni Galbo

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 呈爆炸式增长，您更有经验的同事可能仍在思考“每个数据库调用都应该通过存储过程”的心态。

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 会使调试变得更难？无论它来自存储过程还是来自 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.

我想我能想到的使用 ORM 的唯一真正不利之处是安全模型的灵活性稍差。

EDIT: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.

编辑：我刚刚重新阅读了您的问题，看起来他们正在将查询复制并粘贴到内联 sql 中。这使得安全模型与 ORM 相同，因此与 ORM 相比，这种方法绝对没有优势。如果他们使用未参数化的查询，那么实际上会存在安全风险。

回答by Keith Elder

The short answer is yes, there are really good reasons. As a matter of fact there are cases where you just cannot use an ORM.

简短的回答是肯定的，确实有很好的理由。事实上，有些情况下你不能使用 ORM。

Case in point, I work for a large enterprise financial institution and we have to follow a lot of security guidelines. To meet the rules and regulations that are put upon us, the only way to pass audits is to keep data access within stored procedures. Now some may say that's just plain stupid, but honestly it isn't. Using an ORM tool means the tool/developer can insert, select, update or delete whatever he or she wants. Stored procedures provide a lot more security, especially in environments when dealing with client data. I think this is the biggest reason to consider. Security.

例如，我在一家大型企业金融机构工作，我们必须遵循很多安全准则。为了满足强加给我们的规则和规定，通过审计的唯一方法是在存储过程中保持数据访问。现在有些人可能会说这很愚蠢，但老实说，事实并非如此。使用 ORM 工具意味着该工具/开发人员可以插入、选择、更新或删除他或她想要的任何内容。存储过程提供了更高的安全性，尤其是在处理客户端数据的环境中。我认为这是考虑的最大原因。安全。

回答by Mike

I worked on one project where not using an ORM was very successfully. It was a project that

我曾参与过一个项目，在该项目中不使用 ORM 非常成功。这是一个项目

1. Had to be horizontally scalealbe from the start
2. Had to be developed quickly
3. Had a relatively simple domain model

1. 从一开始就必须水平缩放
2. 必须快速开发
3. 有一个相对简单的领域模型

The time that it would have taken to get NHibernate to work in a horizontally partitioned structure would have been much longer than the time that it took to develop a super simple datamapper that was aware of our partitioning scheme...

让 NHibernate 在水平分区结构中工作所花费的时间比开发一个了解我们的分区方案的超级简单数据映射器所花费的时间要长得多......

So, in 90% of projects that I have worked on an ORM has been an invaluable help. But there are some very specific circumstances where I can see not using an ORM as being best.

因此，在我从事的 90% 的 ORM 项目中，ORM 都提供了宝贵的帮助。但是在某些非常特殊的情况下，我认为不使用 ORM 是最好的。

回答by Oli

Runtime performance is the only real downside I can think of but I think that's more than a fair trade-off for the time ORM saves you developing/testing/etc. And in most cases you should be able to locate data bottlenecks and alter your object structures to be more efficient.

运行时性能是我能想到的唯一真正的缺点，但我认为这不仅仅是 ORM 为您节省开发/测试/等时间的公平权衡。在大多数情况下，您应该能够定位数据瓶颈并更改对象结构以提高效率。

I haven't used Hibernate before but one thing I have noticed with a few "off-the-shelf" ORM solutions is a lack of flexibility. I'm sure this depends on which you go with and what you need to do with it.

我之前没有使用过 Hibernate，但我注意到一些“现成的”ORM 解决方案缺乏灵活性。我敢肯定这取决于您选择哪种方式以及您需要用它做什么。

回答by mattlant

I think that using an ORM is still a good idea. Especially considering the situation you give. It sounds by your post you are the more experienced when it comes to the db access strategies, and I would bring up using an ORM.

我认为使用 ORM 仍然是一个好主意。特别是考虑到你给出的情况。听起来你的帖子在数据库访问策略方面你更有经验，我会提出使用 ORM。

There is no argument for #1 as copying and pasting queries and hardcoding in text gives no flexibility, and for #2 most orm's will wrap the original exception, will allow tracing the queries generated, etc, so debugging isnt rocket science either.

#1 没有任何参数，因为在文本中复制和粘贴查询和硬编码没有灵活性，而对于 #2，大多数 orm 将包装原始异常，将允许跟踪生成的查询等，因此调试也不是火箭科学。

As for validation, using an ORM will also usually allow much easier time developing validation strategies, on top of any built in validation.

至于验证，在任何内置验证之上，使用 ORM 通常还可以更轻松地开发验证策略。

Writing your own framework can be laborious, and often things get missed.

编写自己的框架可能很费力，而且经常会遗漏一些东西。

EDIT: I wanted to make one more point. If your company adopts an ORM strategy, that further enhances its value, as you will develop guidelines and practices for using and implementing and everyone will further enhance their knowledge of the framework chosen, mitigating one of the issues you brought up. Also, you will learn what works and what doesnt when situations arise, and in the end it will save lots of time and effort.

编辑：我想再说明一点。如果您的公司采用 ORM 策略，则会进一步提高其价值，因为您将制定使用和实施的指南和实践，并且每个人都将进一步增强他们对所选框架的了解，从而减轻您提出的问题之一。此外，当情况出现时，您将了解哪些有效，哪些无效，最终将节省大量时间和精力。

回答by Alan Hensel

There are a wide range of common problems for which ORM tools like Hibernate are a god-send, and a few where it is a hindrance. I don't know enough about your project to know which it is.

有很多常见问题，像 Hibernate 这样的 ORM 工具是天赐之物，也有一些是障碍。我对你的项目了解不够，不知道是哪个项目。

One of Hibernate's strong points is that you get to say things only 3 times: every property is mentioned in the class, the .hbm.xml file, and the database. With SQL queries, your properties are in the class, the database, the select statements, the insert statements, the update statements, the delete statements, and all the marshalling and unmarshalling code supporting your SQL queries! This can get messy fast. On the other hand, you know how it works. You can debug it. It's all right there in your own persistence layer, not buried in the bowels of a 3rd party tool.

Hibernate 的强项之一是您只能说 3 次：每个属性都在类、.hbm.xml 文件和数据库中提及。对于 SQL 查询，您的属性位于类、数据库、选择语句、插入语句、更新语句、删除语句以及支持 SQL 查询的所有编组和解组代码中！这会很快变得混乱。另一方面，你知道它是如何工作的。你可以调试它。它就在你自己的持久层中，而不是埋在第 3 方工具的内部。

Hibernate could be a poster-child for Spolsky's Law of Leaky Abstractions. Get a little bit off the beaten path, and you need to know deep internal workings of the tool. It can be very annoying when you know you could have fixed the SQL in minutes, but instead you are spending hours trying to cajole your dang tool into generating reasonable SQL. Debugging is sometimes a nightmare, but it's hard to convince people who have not been there.

Hibernate 可能是斯波尔斯基泄漏抽象定律的典型代表。稍微偏离常规，您需要了解该工具的深层内部工作原理。当您知道您可以在几分钟内修复 SQL 时，这可能会非常烦人，但您却要花费数小时试图哄骗您的 dang 工具生成合理的 SQL。调试有时是一场噩梦，但很难说服没有去过那里的人。

EDIT: You might want to look into iBatis.NET if they are not going to be turned around about NHibernate and they want control over their SQL queries.

编辑：如果他们不打算改变 NHibernate 并且他们想要控制他们的 SQL 查询，您可能想要查看 iBatis.NET。

EDIT 2: Here's the big red flag, though: "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." So, these "experienced" developers, what are they experienced in developing? Their job security? It sounds like you might be among people who are not particularly interested in the field, so don't let them kill your interest. You need to be the balance. Put up a fight.

编辑 2：不过，这是一个很大的危险信号：“在 Stack Overflow 上被视为非常正常的良好做法，例如单元测试或持续集成，到目前为止还不存在。” 那么，这些“经验丰富”的开发人员，他们在开发过程中经历了什么？他们的工作有保障吗？听起来你可能对这个领域不是特别感兴趣，所以不要让他们扼杀你的兴趣。你需要保持平衡。投入了战斗。

回答by Ajaxx

Let me first say that ORMs can make your development life easier if integrated properly, but there are a handful of problems where the ORM can actually prevent you from achieving your stated requirements and goals.

首先让我说，如果正确集成，ORM 可以使您的开发生活更轻松，但是存在一些问题，ORM 实际上会阻止您实现既定的要求和目标。

I have found that when designing systems that have heavy performance requirements that I am often challenged to find ways to make the system more performant. Many times, I end up with a solution that has a heavy write performance profile (meaning we're writing data a lot more than we're reading data). In these cases, I want to take advantage of the facilities the database platform offers to me in order to reach our performance goals (it's OLTP, not OLAP). So if I'm using SQL Server and I know I have a lot of data to write, why wouldn't I use a bulk insert... well, as you may have already discovered, most ORMS (I don't know if even a single one does) do not have the ability to take advantage of platform specific advantages like bulk insert.

我发现在设计具有高性能要求的系统时，我经常面临着寻找使系统性能更高的方法的挑战。很多时候，我最终得到的解决方案具有很高的写入性能配置文件（这意味着我们写入数据的次数远远超过读取数据的次数）。在这些情况下，我想利用数据库平台为我提供的便利来实现我们的性能目标（它是 OLTP，而不是 OLAP）。因此，如果我正在使用 SQL Server 并且我知道我有很多数据要写入，为什么我不使用批量插入......好吧，正如您可能已经发现的那样，大多数 ORMS（我不知道是否即使是一个）也无法利用平台特定的优势，如批量插入。

You should know that you can blend the ORM and non-ORM techniques. I've just found that there are a handful of edge cases where ORMs can not support your requirements and you have to work around them for those cases.

您应该知道您可以混合 ORM 和非 ORM 技术。我刚刚发现在一些边缘情况下 ORM 无法支持您的要求，您必须针对这些情况解决这些问题。

回答by dacracot

There are two aspects of ORMs that are worrisome. First, they are code written by someone else, sometimes closed source, sometimes open source but huge in scope. Second, they copy the data.

ORM 有两个方面令人担忧。首先，它们是由其他人编写的代码，有时是闭源代码，有时是开源代码，但范围很广。其次，他们复制数据。

The first problem causes two issues. You are relying on outsiders code. We all do this, but the choice to do so should not be taken lightly. And what if it doesn't do what you need? When will you discover this? You live inside the box that your ORM draws for you.

第一个问题导致两个问题。您正在依赖外部代码。我们都这样做，但不应掉以轻心的选择。如果它不能满足您的需求怎么办？你什么时候会发现这个？你住在你的 ORM 为你绘制的盒子里。

The second problem is one of two phase commit. The relational database is being copied to a object model. You change the object model and it is supposed to update the database. This is a two phase commit and not the easiest thing to debug.

第二个问题是两阶段提交之一。正在将关系数据库复制到对象模型。您更改对象模型，它应该更新数据库。这是一个两阶段提交，并不是最容易调试的事情。

回答by Javier

Personally, i have (until recently) opposed to use an ORM, and used to get by with writing a data access layer encapsulating all the SQL commands. The main objection to ORMs was that I didn't trust the ORM implementation to write exactly the right SQL. And, judging by the ORMs i used to see (mostly PHP libraries), i think i was totally right.

就个人而言，我一直（直到最近）反对使用 ORM，并且习惯于编写封装所有 SQL 命令的数据访问层。对 ORM 的主要反对意见是我不相信 ORM 实现能够编写完全正确的 SQL。而且，从我曾经看到的 ORM（主要是 PHP 库）来看，我认为我是完全正确的。

Now, most of my web development is using Django, and i found the included ORM really convenient, and since the data model is expressed first in their terms, and only later in SQL, it does work perfectly for my needs. I'm sure it wouldn't be too hard to outgrow it and need to supplement with hand-written SQL; but for CRUD access is more than enough.

现在，我的大部分 Web 开发都使用 Django，而且我发现包含的 ORM 非常方便，而且由于数据模型首先用它们的术语表示，然后才用 SQL 表示，因此它确实可以完美满足我的需求。我相信它不会太难超过它并且需要补充手写 SQL；但是对于 CRUD 访问来说已经绰绰有余了。

I don't know about NHibernate; but i guess it's also "good enough" for most of what you need. But if other coders don't trust it; it will be a prime suspect on every data-related bug, making verification more tedious.

我不知道 NHibernate；但我想它对于您需要的大部分内容也“足够好”。但如果其他编码人员不信任它；它将成为每个与数据相关的错误的主要嫌疑人，使验证变得更加乏味。

You could try to introduce it gradually in your workplace, focus first on small 'obvious' applications, like simple data access. After a while, it might be used on prototypes, and it might not be replaced...

您可以尝试在您的工作场所逐步引入它，首先关注小型“明显”应用程序，例如简单的数据访问。过一段时间，它可能会被用在原型上，它可能不会被取代......

回答by pabloide86

I think that maybe when you work on bigger systems you can use a code generator tool like CodeSmith instead of a ORM... I recently found this: Cooperator Frameworkwhich generates SQL Server Stored Procedures and also generates your business entities, mappers, gateways, lazyload and all that stuff in C#...check it out...it was written by a team here in Argentina...

我想，也许当你在更大的系统中工作，你可以用这样的CodeSmith而不是ORM代码生成工具......最近，我发现这一点：合作者框架生成SQL Server存储过程和也产生你的企业实体，映射器，网关，懒加载和 C# 中的所有东西......检查一下......它是由阿根廷的一个团队编写的......

I think it's in the middle between coding the entire data access layer and use a ORM...

我认为它介于对整个数据访问层进行编码和使用 ORM 之间...