使用ORM有什么好处?

As a web developer looking to move from hand-coded PHP sites to framework-based sites, I have seen a lot of discussion about the advantages of one ORM over another. It seems to be useful for projects of a certain (?) size, and even more important for enterprise-level applications.

作为一个希望从手工编码的PHP站点迁移到基于框架的站点的web开发人员，我看到了很多关于一个ORM相对于另一个的好处的讨论。它似乎对某些(?)大小的项目有用，对企业级应用程序更重要。

What does it give me as a developer? How will my code differ from the individual SELECT statements that I use now? How will it help with DB access and security? How does it find out about the DB schema and user credentials?

作为一个开发人员，它给了我什么?我的代码与我现在使用的单独的SELECT语句有何不同?它将如何帮助DB访问和安全性?它如何发现DB模式和用户凭证?

Edit: @duffymo pointed out what should have been obvious to me: ORM is only useful for OOP code. My code is not OO, so I haven't run into the problems that ORM solves.

编辑:@duffymo指出了我应该明白的一点:ORM只对OOP代码有用。我的代码不是OO，所以我没有遇到ORM解决的问题。

13 个解决方案

#1

I'd say that if you aren't dealing with objects there's little point in using an ORM.

我想说，如果你不是在处理对象，那么使用ORM就没有什么意义了。

If your relational tables/columns map 1:1 with objects/attributes, there's not much point in using an ORM.

如果您的关系表/列与对象/属性映射为1:1，那么使用ORM没有多大意义。

If your objects don't have any 1:1, 1:m or m:n relationships with other objects, there's not much point in using an ORM.

如果您的对象与其他对象没有1:1、1:m或m:n的关系，那么使用ORM就没有多大意义了。

If you have complex, hand-tuned SQL, there's not much point in using an ORM.

如果您有复杂的、手动调优的SQL，那么使用ORM没什么意义。

If you've decided that your database will have stored procedures as its interface, there's not much point in using an ORM.

如果您已经确定数据库将使用存储过程作为接口，那么使用ORM没有多大意义。

If you have a complex legacy schema that can't be refactored, there's not much point in using an ORM.

如果您有一个不能重构的复杂遗留模式，那么使用ORM没有多大意义。

So here's the converse:

这是相反的:

If you have a solid object model, with relationships between objects that are 1:1, 1:m, and m:n, don't have stored procedures, and like the dynamic SQL that an ORM solution will give you, by all means use an ORM.

如果您有一个实体对象模型，对象之间的关系是1:1,1:m和m:n，没有存储过程，就像ORM解决方案会给您的动态SQL一样，使用ORM。

Decisions like these are always a choice. Choose, implement, measure, evaluate.

像这样的决定总是一个选择。选择,实现,测量,评估。

#2

ORMs are being hyped for being the solution to Data Access problems. Personally, after having used them in an Enterprise Project, they are far from being the solution for Enterprise Application Development. Maybe they work in small projects. Here are the problems we have experienced with them specifically nHibernate:

ORMs被大肆宣传为数据访问问题的解决方案。就我个人而言，在企业项目中使用它们之后，它们远不是企业应用程序开发的解决方案。也许他们在小项目中工作。以下是我们在nHibernate中遇到的问题:

1. Configuration: ORM technologies require configuration files to map table schemas into object structures. In large enterprise systems the configuration grows very quickly and becomes extremely difficult to create and manage. Maintaining the configuration also gets tedious and unmaintainable as business requirements and models constantly change and evolve in an agile environment.

   配置:ORM技术要求配置文件将表模式映射到对象结构中。在大型企业系统中，配置增长非常快，并且非常难以创建和管理。由于业务需求和模型在敏捷的环境中不断地变化和发展，维护配置也变得单调乏味和不可维护。

2. Custom Queries: The ability to map custom queries that do not fit into any defined object is either not supported or not recommended by the framework providers. Developers are forced to find work-arounds by writing adhoc objects and queries, or writing custom code to get the data they need. They may have to use Stored Procedures on a regular basis for anything more complex than a simple Select.

   自定义查询:不支持或不支持框架提供者建议的自定义查询的映射能力。开发人员*通过编写特定的对象和查询或者编写定制代码来获取他们需要的数据来找到解决方案。对于任何比简单的选择更复杂的东西，他们可能必须定期使用存储过程。

3. Proprietery binding: These frameworks require the use of proprietary libraries and proprietary object query languages that are not standardized in the computer science industry. These proprietary libraries and query languages bind the application to the specific implementation of the provider with little or no flexibility to change if required and no interoperability to collaborate with each other.

   所有者绑定:这些框架需要使用私有库和私有对象查询语言，这些语言在计算机科学行业中是没有标准化的。这些专有库和查询语言将应用程序绑定到提供者的特定实现上，如果需要的话，几乎没有灵活性进行更改，并且没有互操作性来相互协作。

4. Object Query Languages: New query languages called Object Query Languages are provided to perform queries on the object model. They automatically generate SQL queries against the databse and the user is abstracted from the process. To Object Oriented developers this may seem like a benefit since they feel the problem of writing SQL is solved. The problem in practicality is that these query languages cannot support some of the intermediate to advanced SQL constructs required by most real world applications. They also prevent developers from tweaking the SQL queries if necessary.

   对象查询语言:提供称为对象查询语言的新查询语言，用于对对象模型执行查询。它们自动生成针对数据库的SQL查询，并将用户从该进程中抽象出来。对于面向对象的开发人员来说，这似乎是一个好处，因为他们认为编写SQL的问题已经解决。实际的问题是，这些查询语言不能支持大多数实际应用程序所需的高级SQL构造。它们还防止开发人员在必要时调整SQL查询。

5. Performance: The ORM layers use reflection and introspection to instantiate and populate the objects with data from the database. These are costly operations in terms of processing and add to the performance degradation of the mapping operations. The Object Queries that are translated to produce unoptimized queries without the option of tuning them causing significant performance losses and overloading of the database management systems. Performance tuning the SQL is almost impossible since the frameworks provide little flexiblity over controlling the SQL that gets autogenerated.

   性能:ORM层使用反射和内省实例化并使用来自数据库的数据填充对象。这些操作在处理方面代价高昂，而且会降低映射操作的性能。对象查询被转换为生成未优化的查询，而没有对其进行调优的选项，这将导致严重的性能损失和数据库管理系统的过载。对SQL进行性能调优几乎是不可能的，因为框架对控制自动生成的SQL提供了很少的灵活性。

6. Tight coupling: This approach creates a tight dependancy between model objects and database schemas. Developers don't want a one-to-one correlation between database fields and class fields. Changing the database schema has rippling affects in the object model and mapping configuration and vice versa.

   紧密耦合:这种方法在模型对象和数据库模式之间创建了紧密的依赖关系。开发人员不希望数据库字段和类字段之间存在一对一的相关性。更改数据库模式会在对象模型和映射配置中产生涟漪效应，反之亦然。

7. Caches: This approach also requires the use of object caches and contexts that are necessary to maintian and track the state of the object and reduce database roundtrips for the cached data. These caches if not maintained and synchrnonized in a multi-tiered implementation can have significant ramifications in terms of data-accuracy and concurrency. Often third party caches or external caches have to be plugged in to solve this problem, adding extensive burden to the data-access layer.

   缓存:这种方法还需要使用对象缓存和上下文，这对maintian来说是必要的，并跟踪对象的状态，并减少缓存数据的数据库往返。如果在多层实现中不进行维护和同步，这些缓存将在数据准确性和并发性方面产生重大影响。通常需要插入第三方缓存或外部缓存来解决这个问题，这给数据访问层增加了很大的负担。

For more information on our analysis you can read: http://www.orasissoftware.com/driver.aspx?topic=whitepaper

有关我们的分析的更多信息，请阅读:http://www.orasissoftware.com/driver.aspx?

#3

At a very high level: ORMs help to reduce the Object-Relational impedance mismatch. They allow you to store and retrieve full live objects from a relational database without doing a lot of parsing/serialization yourself.

在一个非常高的层次上:ORMs有助于减少对象-关系阻抗的不匹配。它们允许您从关系数据库中存储和检索完整的活动对象，而无需自己进行大量的解析/序列化。

What does it give me as a developer?

作为一个开发人员，它给了我什么?

For starters it helps you stay DRY. Either you schema or you model classes are authoritative and the other is automatically generated which reduces the number of bugs and amount of boiler plate code.

首先，它可以帮助你保持干燥。您的模式或您的模型类是权威的，另一个是自动生成的，这减少了错误的数量和锅炉板代码的数量。

It helps with marshaling. ORMs generally handle marshaling the values of individual columns into the appropriate types so that you don't have to parse/serialize them yourself. Furthermore, it allows you to retrieve fully formed object from the DB rather than simply row objects that you have to wrap your self.

它有助于编组。ORMs通常将各个列的值编组到适当的类型中，这样您就不必自己解析/序列化它们。此外，它允许您从DB中检索完全成形的对象，而不是简单地将自己包装起来的行对象。

How will my code differ from the individual SELECT statements that I use now?

我的代码与我现在使用的单独的SELECT语句有何不同?

Since your queries will return objects rather then just rows, you will be able to access related objects using attribute access rather than creating a new query. You are generally able to write SQL directly when you need to, but for most operations (CRUD) the ORM will make the code for interacting with persistent objects simpler.

由于您的查询将返回对象，而不是返回行，因此您将能够使用属性访问访问相关的对象，而不是创建新的查询。通常您可以在需要时直接编写SQL，但是对于大多数操作(CRUD)， ORM将使与持久对象交互的代码更简单。

How will it help with DB access and security?

它将如何帮助DB访问和安全性?

Generally speaking, ORMs have their own API for building queries (eg. attribute access) and so are less vulnerable to SQL injection attacks; however, they often allow you to inject your own SQL into the generated queries so that you can do strange things if you need to. Such injected SQL you are responsible for sanitizing yourself, but, if you stay away from using such features then the ORM should take care of sanitizing user data automatically.

一般来说，ORMs有自己的用于构建查询的API(例如。属性访问)等对SQL注入攻击不那么敏感;但是，它们通常允许您将自己的SQL注入到生成的查询中，以便在需要的时候可以做一些奇怪的事情。这样的注入SQL您负责对自己进行消毒，但是，如果您不使用这些特性，那么ORM应该自动地对用户数据进行消毒。

How does it find out about the DB schema and user credentials?

它如何发现DB模式和用户凭证?

Many ORMs come with tools that will inspect a schema and build up a set of model classes that allow you to interact with the objects in the database. [Database] user credentials are generally stored in a settings file.

许多orm提供了一些工具，它们将检查模式并建立一组模型类，使您能够与数据库中的对象进行交互。用户凭证一般存储在设置文件中。

#4

If you write your data access layer by hand, you are essentially writing your own feature poor ORM.

如果您手工编写数据访问层，您实际上是在编写自己的特性poor ORM。

Oren Eini has a nice blog which sums up what essential features you may need in your DAL/ORM and why it writing your own becomes a bad idea after time: http://ayende.com/Blog/archive/2006/05/12/25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

Oren Eini有一个很好的博客，总结了你在你的DAL/ORM中可能需要的一些基本特性，以及为什么写你自己的博客会成为一个坏主意:http://ayende.com/blog/archive/2006/05/12/25rationsnottowritenobjectrelationalmapper.aspx

EDIT: The OP has commented in other answers that his code base isn't very object oriented. Dealing with object mapping is only one facet of ORMs. The Active Record pattern is a good example of how ORMs are still useful in scenarios where objects map 1:1 to tables.

编辑:OP在其他答案中评论说他的代码库不是面向对象的。处理对象映射只是ORMs的一个方面。活动记录模式是一个很好的例子，说明在对象与表1:1映射的场景中，ORMs仍然很有用。

#5

I can't speak for other ORM's, just Hibernate (for Java).

我不能代表其他ORM，只是Hibernate(代表Java)。

Hibernate gives me the following:

Hibernate给了我以下信息:

• Automatically updates schema for tables on production system at run-time. Sometimes you still have to update some things manually yourself.
• 在运行时自动更新生产系统上的表的模式。有时候你还需要手动更新一些东西。
• Automatically creates foreign keys which keeps you from writing bad code that is creating orphaned data.
• 自动创建外键，防止您编写创建孤立数据的错误代码。
• Implements connection pooling. Multiple connection pooling providers are available.
• 实现连接池。可以使用多个连接池提供程序。
• Caches data for faster access. Multiple caching providers are available. This also allows you to cluster together many servers to help you scale.
• 缓存数据以便更快地访问。可以使用多个缓存提供程序。这也允许您将许多服务器聚在一起，以帮助您扩展。
• Makes database access more transparent so that you can easily port your application to another database.
• 使数据库访问更加透明，以便可以轻松地将应用程序移植到另一个数据库。
• Make queries easier to write. The following query that would normally require you to write 'join' three times can be written like this:
  • "from Invoice i where i.customer.address.city = ?" this retrieves all invoices with a specific city
  • “从发票一开始，顾客地址。”这将检索与特定城市的所有发票
  • a list of Invoice objects are returned. I can then call invoice.getCustomer().getCompanyName(); if the data is not already in the cache the database is queried automatically in the background
  • 返回发票对象的列表。然后我可以调用invoice.getCustomer().getCompanyName();如果数据不在缓存中，数据库将在后台自动查询
• 使查询更容易编写。下面的查询通常要求您写三次“join”，可以这样写:“from Invoice i where i.customer.address”。城市= ?“这个检索所有与特定城市的发票，发票对象的列表被返回。然后我可以调用invoice.getCustomer().getCompanyName();如果数据不在缓存中，数据库将在后台自动查询

You can reverse-engineer a database to create the hibernate schema (haven't tried this myself) or you can create the schema from scratch.

您可以反向设计一个数据库来创建hibernate模式(我自己还没有尝试过)，也可以从头创建这个模式。

There is of course a learning curve as with any new technology but I think it's well worth it.

当然，任何新技术都有学习曲线，但我认为这是值得的。

When needed you can still drop down to the lower SQL level to write an optimized query.

在需要的时候，您仍然可以降低到较低的SQL级别来编写优化的查询。

#6

Top Benefits:

好处:

1. Database Abstraction
2. 数据库抽象
3. API-centric design mentality
4. 设计思维中脱颖而出
5. High Level == Less to worry about at the fundamental level (its been thought of for you)
6. 在最基本的层面上(它被认为是为你而存在的)

I have to say, working with an ORM is really the evolution of database-driven applications. You worry less about the boilerplate SQL you always write, and more on how the interfaces can work together to make a very straightforward system.

我不得不说，使用ORM实际上是数据库驱动的应用程序的进化。您不必担心总是编写的样板式SQL，而需要更多地关注接口如何协同工作，从而构建一个非常简单的系统。

I love not having to worry about INNER JOIN and SELECT COUNT(*). I just work in my high level abstraction, and I've taken care of database abstraction at the same time.

我喜欢不用担心内部连接和选择COUNT(*)。我只是在高级抽象中工作，同时我还负责数据库抽象。

Having said that, I never have really run into an issue where I needed to run the same code on more than one database system at a time realistically. However, that's not to say that case doesn't exist, its a very real problem for some developers.

话虽如此，我从来没有遇到过需要在多个数据库系统上同时运行相同代码的问题。然而，这并不是说这种情况不存在，这对一些开发人员来说是一个非常现实的问题。

#7

Most databases used are relational databases which does not directly translate to objects. What an Object-Relational Mapper does is take the data, create a shell around it with utility functions for updating, removing, inserting, and other operations that can be performed. So instead of thinking of it as an array of rows, you now have a list of objets that you can manipulate as you would any other and simply call obj.Save() when you're done.

使用的大多数数据库是关系数据库，不直接转换为对象。对象-关系映射器所做的是获取数据，并围绕数据创建一个shell，其中包含用于更新、删除、插入和其他可以执行的操作的实用函数。因此，不再把它看作是一行的数组，现在您有了一个objets列表，您可以像其他方法一样操作它，并在完成之后简单地调用object . save()。

I suggest you take a look at some of the ORM's that are in use, a favourite of mine is the ORM used in the python framework, django. The idea is that you write a definition of how your data looks in the database and the ORM takes care of validation, checks and any mechanics that need to run before the data is inserted.

我建议您看一下正在使用的ORM，我最喜欢的是python框架中使用的ORM, django。其思想是，您编写数据在数据库中的外观的定义，ORM负责在插入数据之前进行验证、检查和任何需要运行的机制。

#8

Personally I've not had a great experience with using ORM technology to date. I'm currently working for a company that uses nHibernate and I really can't get on with it. Give me a stored proc and DAL any day! More code sure ... but also more control and code that's easier to debug - from my experience using an early version of nHibernate it has to be added.

我个人还没有使用ORM技术的经验。我目前在一家使用nHibernate的公司工作，我真的无法继续下去。随时给我一个储存的步骤和数据!更多的代码肯定…但也有更容易调试的控制和代码——根据我使用早期版本的nHibernate的经验，必须添加它。

#9

What does it give me as a developer?

作为一个开发人员，它给了我什么?

Saves you time, since you don't have to code the db access portion.

节省您的时间，因为您不必编写db访问部分。

How will my code differ from the individual SELECT statements that I use now?

我的代码与我现在使用的单独的SELECT语句有何不同?

You will use either attributes or xml files to define the class mapping to the database tables.

您将使用属性或xml文件定义到数据库表的类映射。

How will it help with DB access and security?

它将如何帮助DB访问和安全性?

Most frameworks try to adhere to db best practices where applicable, such as parametrized SQL and such. Because the implementation detail is coded in the framework, you don't have to worry about it. For this reason, however, it's also important to understand the framework you're using, and be aware of any design flaws or bugs that may open unexpected holes.

大多数框架都试图遵循db最佳实践(如参数化的SQL等)。因为实现细节是在框架中编码的，所以您不必担心它。然而，出于这个原因，理解您正在使用的框架也很重要，并且要注意任何可能打开意外漏洞的设计缺陷或缺陷。

How does it find out about the DB schema and user credentials?

它如何发现DB模式和用户凭证?

You provide the connection string as always. The framework providers (e.g. SQL, Oracle, MySQL specific classes) provide the implementation that queries the db schema, processes the class mappings, and renders / executes the db access code as necessary.

您将始终提供连接字符串。框架提供程序(例如SQL、Oracle、特定于MySQL的类)提供了查询db模式、处理类映射以及根据需要呈现/执行db访问代码的实现。

#10

Using an ORM will remove dependencies from your code on a particular SQL dialect. Instead of directly interacting with the database you'll be interacting with an abstraction layer that provides insulation between your code and the database implementation. Additionally, ORMs typically provide protection from SQL injection by constructing parameterized queries. Granted you could do this yourself, but it's nice to have the framework guarantee.

使用ORM将从代码中删除对特定SQL方言的依赖关系。不是直接与数据库交互，而是与抽象层交互，抽象层在代码和数据库实现之间提供隔离。此外，ORMs通常通过构造参数化查询来提供对SQL注入的保护。当然，你可以自己做这个，但是有框架担保很好。

ORMs work in one of two ways: some discover the schema from an existing database -- the LINQToSQL designer does this --, others require you to map your class onto a table. In both cases, once the schema has been mapped, the ORM may be able to create (recreate) your database structure for you. DB permissions probably still need to be applied by hand or via custom SQL.

orm的工作方式有两种:一种是从现有数据库中发现模式(LINQToSQL设计器就是这么做的)，另一种需要将类映射到表中。在这两种情况下，一旦模式被映射，ORM可以为您创建(重新创建)数据库结构。DB权限可能仍然需要手工或通过自定义SQL应用。

Typically, the credentials supplied programatically via the API or using a configuration file -- or both, defaults coming from a configuration file, but able to be override in code.

通常，通过API或使用配置文件编程提供的凭据——或者两者都是，默认来自配置文件，但可以在代码中重写。

#11

For a podcast that discusses ORM in detail see the following link. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

对于一个讨论ORM的播客，请参见下面的链接。http://se - radio.net/podcast/2008 12/episode - 121 -或-映射器-迈克尔-巴解组织

#12

While I agree with the accepted answer almost completely, I think it can be amended with lightweight alternatives in mind.

虽然我几乎完全同意公认的答案，但我认为可以考虑使用轻量级替代方案对其进行修改。

• If you have complex, hand-tuned SQL
• 如果您有复杂的、手动调优的SQL
• If your objects don't have any 1:1, 1:m or m:n relationships with other objects
• 如果你的对象没有1:1,1:m或m:n与其他对象的关系
• If you have a complex legacy schema that can't be refactored
• 如果您有一个不能重构的复杂遗留模式

...then you might benefit from a lightweight ORM where SQL is is not obscured or abstracted to the point where it is easier to write your own database integration.

…然后，您可能会受益于一个轻量级的ORM，其中SQL没有被隐藏或抽象到更容易编写自己的数据库集成的程度。

These are a few of the many reasons why the developer team at my company decided that we needed to make a more flexible abstraction to reside on top of the JDBC.

这就是为什么我公司的开发人员团队认为我们需要在JDBC之上构建一个更灵活的抽象的原因。

There are many open source alternatives around that accomplish similar things, and jORM is our proposed solution.

有很多开源的替代方案可以完成类似的事情，jORM是我们提出的解决方案。

I would recommend to evaluate a few of the strongest candidates before choosing a lightweight ORM. They are slightly different in their approach to abstract databases, but might look similar from a top down view.

我建议在选择轻量级ORM之前，先评估几个最强的候选。它们在抽象数据库的方法上略有不同，但从上往下看可能类似。

• jORM
• jORM
• ActiveJDBC
• ActiveJDBC
• ORMLite
• ORMLite

#13

my concern with ORM frameworks is probably the very thing that makes it attractive to lots of developers.

我对ORM框架的关注可能是使它吸引大量开发人员的原因。

nameley that it obviates the need to 'care' about what's going on at the DB level. Most of the problems that we see during the day to day running of our apps are related to database problems. I worry slightly about a world that is 100% ORM that people won't know about what queries are hitting the database, or if they do, they are unsure about how to change them or optimize them.

nameley认为它避免了在DB级别上“关心”正在发生的事情。我们每天运行应用程序时看到的大多数问题都与数据库问题有关。我担心的是一个100%的ORM的世界，人们不知道什么是查询数据库，或者如果他们知道，他们不确定如何改变或优化他们。

{I realize this may be a contraversial answer :) }

{我意识到这可能是一个禁忌的回答:)}