使用 OR-Mapper 有意义吗？
使用 OR 映射器有意义吗？
我将这个问题放在堆栈溢出上，因为这是我所知道的找到愿意提供帮助和意见的聪明开发人员的最佳地方。
我的推理如下：
1.) SQL 属于哪里？
a.) 在我从事的每个专业项目中，数据安全性一直是关键要求。存储过程提供了控制访问和审核的自然网关。
b.) 生产中的应用程序问题通常可以在表和存储过程之间解决，而无需发布新版本。
2.) 如何控制生成的 SQL？我相信解析树能够生成高效的 SQL。 我在 SQL-Server 和 Oracle 中优化 SQL 方面有相当多的经验，但如果我不再需要这样做，我也不会感到受骗。 :)
3.) 如果我从存储过程获取数据，那么使用 OR-Mapper 的意义何在？
我使用了带有本地通用数据访问层的存储库模式。 如果需要缓存一个集合，我就会缓存它。我还有在小型 CRUD 应用程序上使用 EF 的经验，以及帮助调整遇到性能问题的 NHibernate 应用程序的经验。所以我有点偏向，但是愿意学习。
在过去的几年里，我们一直听到许多受人尊敬的开发人员提倡使用特定的 OR-Mappers（Entity-Framework、NHibernate 等）。
谁能告诉我为什么有人应该转向 ORM 来进行大型项目的主流开发？
编辑： http ://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html似乎对这个主题有强烈的讨论，但它是已经过时了。
另一个编辑： 每个人似乎都同意存储过程用于重型企业应用程序，因为它们具有性能优势并且能够在更接近数据的位置添加编程逻辑。
我发现支持 OR 映射器的最有力的论据是开发人员的生产力。
我怀疑 ORM 运动的一个重要动机是开发人员倾向于保持与持久性无关（不关心数据是在内存中[除非缓存]还是在数据库中）。
对于本地和小型 Web 应用程序来说，ORM 似乎可以节省大量时间。
也许我看到的最好建议来自 client09：使用 ORM 设置，但对数据库密集型内容使用存储过程（又称 ORM 似乎不足时）。
Does it make sense to use an OR-mapper?
I am putting this question of there on stack overflow because this is the best place I know of to find smart developers willing to give their assistance and opinions.
My reasoning is as follows:
1.) Where does the SQL belong?
a.) In every professional project I have worked on, security of the data has been a key requirement. Stored Procedures provide a natural gateway for controlling access and auditing.
b.) Issues with Applications in production can often be resolved between the tables and stored procedures without putting out new builds.
2.) How do I control the SQL that is generated? I am trusting parse trees to generate efficient SQL.
I have quite a bit of experience optimizing SQL in SQL-Server and Oracle, but would not feel cheated if I never had to do it again. :)
3.) What is the point of using an OR-Mapper if I am getting my data from stored procedures?
I have used the repository pattern with a homegrown generic data access layer.
If a collection needed to be cached, I cache it. I also have experience using EF on a small CRUD application and experience helping tuning an NHibernate application that was experiencing performance issues. So I am a little biased, but willing to learn.
For the past several years we have all been hearing a lot of respectable developers advocating the use of specific OR-Mappers (Entity-Framework, NHibernate, etc...).
Can anyone tell me why someone should move to an ORM for mainstream development on a major project?
edit: http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html seems to have a strong discussion on this topic but it is out of date.
Yet another edit:
Everyone seems to agree that Stored Procedures are to be used for heavy-duty enterprise applications, due to their performance advantage and their ability to add programming logic nearer to the data.
I am seeing that the strongest argument in favor of OR mappers is developer productivity.
I suspect a large motivator for the ORM movement is developer preference towards remaining persistence-agnostic (don’t care if the data is in memory [unless caching] or on the database).
ORMs seem to be outstanding time-savers for local and small web applications.
Maybe the best advice I am seeing is from client09: to use an ORM setup, but use Stored Procedures for the database intensive stuff (AKA when the ORM appears to be insufficient).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我多年来一直是一名专业 SP，并认为这是进行数据库开发的唯一正确方法，但我完成的最后 3-4 个项目是在 EF4.0 中完成的，没有 SP，并且我的工作效率得到了提高真是令人惊叹——我现在可以用几行代码完成以前需要一天时间才能完成的事情。
我仍然认为 SP 对于某些事情很重要（有时您可以通过精心选择的 SP 显着提高性能），但对于一般的 CRUD 操作，我无法想象会回到过去。
所以对我来说简短的回答是，开发人员的生产力是使用 ORM 的原因——无论如何，一旦你克服了学习曲线。
I was a pro SP for many, many years and thought it was the ONLY right way to do DB development, but the last 3-4 projects I have done I completed in EF4.0 w/out SP's and the improvements in my productivity have been truly awe-inspiring - I can do things in a few lines of code now that would have taken me a day before.
I still think SP's are important for some things, (there are times when you can significantly improve performance with a well chosen SP), but for the general CRUD operations, I can't imagine ever going back.
So the short answer for me is, developer productivity is the reason to use the ORM - once you get over the learning curve anyway.
不同的方法...随着现在 No SQL 运动的兴起，您可能想尝试使用对象/文档数据库来存储数据。这样，你基本上就可以避免 OR Mapping 的地狱了。在应用程序使用数据时存储数据，并在工作进程中在后台进行转换，将其转换为更相关的/OLAP 格式，以便进一步分析和报告。
A different approach... With the raise of No SQL movement now, you might want to try object / document database instead to store your data. In this way, you basically will avoid the hell that is OR Mapping. Store the data as your application use them and do transformation behind the scene in a worker process to move it into a more relational / OLAP format for further analysis and reporting.
存储过程非常适合将数据库逻辑封装在一处。我曾参与过一个仅使用 Oracle 存储过程的项目，目前正在参与一个使用 Hibernate 的项目。我们发现开发冗余过程非常容易，因为我们的 Java 开发人员不熟悉 PL/SQL 包依赖性。
作为该项目的 DBA，我发现 Java 开发人员更喜欢将所有内容保留在 Java 代码中。您偶尔会遇到这样的问题：“为什么我不循环遍历刚刚返回的所有对象呢？”这引发了许多人的疑问：“为什么指数不处理这个问题？”问题。
使用 Hibernate，您的实体不仅可以包含其链接的数据库属性，还可以包含对其采取的任何操作。
例如，我们有一个任务实体。除其他事项外，人们还可以添加或修改一项任务。这可以在命名查询的 Hibernate 实体中建模。
所以我会说采用 ORM 设置，但对数据库密集型内容使用过程。
将 SQL 保留在 Java 中的一个缺点是，开发人员可能会使用非参数化查询，从而使您的应用程序面临 SQL 注入的风险。
Stored procedures are great for encapsulating database logic in one place. I've worked on a project that used only Oracle stored procedures, and am currently on one that uses Hibernate. We found that it is very easy to develop redundant procedures, as our Java developers weren't versed in PL/SQL package dependencies.
As the DBA for the project I find that the Java developers prefer to keep everything in the Java code. You run into the occassional, "Why don't I just loop through all the Objects that just returned?" This caused a number of "Why isn't the index taking care of this?" issues.
With Hibernate your entities can contain not only their linked database properties, but can also contain any actions taken upon them.
For example, we have a Task Entity. One could Add or Modify a Task among other things. This can be modeled in the Hibernate Entity in Named Queries.
So I would say go with an ORM setup, but use procedures for the database intensive stuff.
A downside of keeping your SQL in Java is that you run the risk of developers using non-parameterized queries leaving your app open to a SQL Injection.
以下只是我个人的看法，所以比较主观。
1.) 我认为需要区分本地应用程序和企业应用程序。对于本地和一些Web应用程序，直接访问数据库是可以的。对于企业应用程序，我认为更好的封装和权限管理最终使存储过程成为更好的选择。
2.) 这是 ORM 的大问题之一。它们通常针对特定查询模式进行优化，只要您使用这些模式，生成的 SQL 通常具有良好的质量。然而，对于需要在靠近数据执行以保持效率的复杂操作，我的感觉是使用手动 SQL 代码仍然是可行的方法，在这种情况下，代码进入 SP。
3.) 与直接访问“松散”数据集（即使这些数据集是键入的）相比，将对象作为数据实体进行处理也是有益的。将结果集反序列化为对象图非常有用，无论结果集是由 SP 返回还是由动态 SQL 查询返回。
如果您使用的是 SQL Server，我邀请您查看我的开源 bsn ModuleStore 项目，它是一个数据库模式版本控制和通过一些轻量级 ORM 概念（调用 SP 时对象的序列化和反序列化）使用 SP 的框架。
The following is just my private opinion, so it's rather subjective.
1.) I think that one needs to differentiate between local applications and enterprise applications. For local and some web applications, direct access to the DB is okay. For enterprise applications, I feel that the better encapsulation and rights management makes stored procedures the better choice in the end.
2.) This is one of the big issues with ORMs. They are usually optimized for specific query patterns, and as long as you use those the generated SQL is typically of good quality. However, for complex operations which need to be performed close to the data to remain efficient, my feeling is that using manual SQL code is stilol the way to go, and in this case the code goes into SPs.
3.) Dealing with objects as data entities is also beneficial compared to direct access to "loose" datasets (even if those are typed). Deserializing a result set into an object graph is very useful, no matter whether the result set was returned by a SP or from a dynamic SQL query.
If you're using SQL Server, I invite you to have a look at my open-source bsn ModuleStore project, it's a framework for DB schema versioning and using SPs via some lightweight ORM concept (serialization and deserialization of objects when calling SPs).