ORM是否适合复杂项目？ [英] Is ORM fit for complex projects?

问题描述

我尚未开始ORM旅行，

I've not started the ORM trip yet,

因为我不知道当项目变得非常复杂时如何工作。

because I'm not sure how it works when the project becomes very complex.

您的意见或经验是什么？

What's your opinion or experience?

推荐答案

这个问题有时候很难回答。您可能曾听说过对象关系阻抗不匹配;这是ORM工具试图解决的问题，但它充满了问题。它是这样的情况之一，你可以在很短的时间内解决90％的问题，但每增加1％，似乎在增加指数级的复杂性，因为所有的依赖。

This question is a difficult one to answer sometimes. You may have heard of the Object-Relational Impedance Mismatch before; that is the issue that ORM tools attempt to solve, but it is fraught with problems. It is one of those situations where you can solve 90% of the problem in a very short time, but every additional 1% from there on up seems to increase exponentially in complexity because of all the dependencies.

一个ORM框架是一个抽象，并成为几个点上的泄漏抽象：

An ORM framework is an abstraction, and becomes a leaky abstraction at several points:

• 复杂查询/ script包含UDT，CTE，查询提示，临时表，窗口函数等概念。

• Complex queries/scripts involving concepts like UDTs, CTEs, query hints, temporary tables, windowing functions, etc.

性能优化的查询。正如Quassnoi在他的回答中提到的，ORMs正在改进，但经常产生次优查询，有时效果非常明显。

Performance-optimized queries. As Quassnoi mentioned in his answer, ORMs are getting better at this but frequently generate sub-optimal queries, and sometimes the effect is extremely noticeable.

事务管理 -

跨数据库或跨服务器操作时，工作单元模式只能让您处理大批量更新。有解决方法，但它们只是 - 解决方法。

Cross-database or cross-server actions. There are workarounds, but they are just that - workarounds. No ORM I've seen really handles this well.

多表继承 - 这是只有的形式的继承实际上是规范化的，真的不是那么难以管理使用纯SQL和手动映射，但O / R映射器是糟糕的。对于我们中的许多人来说，单表继承是不可接受的选择。

Multiple-table inheritance - this is the only form of inheritance that is actually normalized, and it is really not that hard to manage using pure SQL and manual mapping, but O/R mappers are lousy at it. For many of us, single-table inheritance is not an acceptable alternative.

/ R映射器似乎失败了我们。

Those are some of many areas where O/R mappers seem to fail us. Having said that, this does not mean that O/R Mappers are not "fit" for large projects.

在我看来，ORM在大型项目中并不适合。通用和O / R映射器对于大型项目特别地至关重要。他们节省了大量的努力，并可以帮助你得到一个应用程序出门在一段时间，否则它会带你。他们只是不解决整个问题。你必须准备好分析你的应用程序，看看ORM真正做什么，你必须准备好回到纯SQL，当情况需要它（即在上面的几种情况）。

In my opinion, ORM in general and O/R Mappers specifically are almost vital for large projects. They save enormous amounts of effort and can help you get an application out the door in a fraction of the time it would have taken you otherwise. They just do not solve the whole problem. You have to be prepared to profile your application to see what the ORM is really doing, and you have to be prepared to drop back down to pure SQL when the situation calls for it (i.e. in several of the situations above).

某些框架（如Linq to SQL）希望您这样做，并为您在同一连接上执行命令或存储过程提供现成的工具，映射者的常规职责。 L2S不是唯一的框架，让你这样做，但有几个是更严格的，你最终跳过许多箍，得到你需要的。在选择ORM时，我认为绕过抽象的能力是一个重要的考虑因素，至少今天。

Some frameworks, such as Linq to SQL, expect you to do this and give you ready-made facilities for executing commands or stored procedures on the same connection and in the same transaction used for the mapper's "regular" duties. L2S is not the only framework that lets you do this, but several are more restrictive, and you end up jumping through many hoops to get what you need. When choosing an ORM, I think that the ability to bypass the abstraction is an important consideration, at least today.

我认为这个问题的最佳答案是：是的，它们适合于大型项目，只要您不完全依赖它们即可。了解您选择的ORM工具的限制，在90％的情况下使用它作为节省时间可以，并确保您和您的团队了解这些实例在抽象泄漏时真正发生的事情。

I think the best answer to this question is: Yes, they are fit for large projects, as long as you do not rely exclusively on them. Know the limits of your ORM tool of choice, use it as a time-saver in the 90% of instances when you can, and make sure you and your team understand what's really going on under the hood for those instances when the abstraction leaks.

这篇关于ORM是否适合复杂项目？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！