7

使用OR映射器有意义吗?使用OR-Mapper有意义吗?

我在堆栈溢出的推杆有这个问题,因为这是最好的地方,我知道,找到聪明的开发商愿意给他们的协助和意见。

我的推理如下:

1.)SQL属于哪里?

a)在我所从事的每一个专业项目中,数据的安全性都是关键要求。存储过程为控制访问和审计提供了一个自然的途径。

湾),在生产应用中的问题往往可以在表和存储过程之间没有扑灭新版本得到解决。

2.)如何控制生成的SQL?我相信分析树来生成高效的SQL。 我在SQL-Server和Oracle中优化SQL的经验相当丰富,但如果我再也不用这样做,就不会感到受骗。 :)

3)是什么,如果我从存储过程中让我的数据使用OR映射器的意义呢?

我已经使用存储库模式与本土通用数据访问层。 如果一个集合需要缓存,我将其缓存。我也有在一个小的CRUD应用程序上使用EF的经验,并有经验帮助调整出现性能问题的NHibernate应用程序。所以我有点偏见,但愿意学习。

在过去的几年里,我们都已经听到了很多尊敬的开发商提倡使用特定的OR映射器(实体框架,NHibernate的,等等)的。

有谁能告诉我为什么有人应该转向ORM进行主流项目的主流开发吗?

编辑:http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html似乎对这个话题的讨论强,但它是过时的。

另一个编辑: 由于各自的性能优势以及能够将编程逻辑添加到数据更近的能力,每个人似乎都同意Stored Procedures将用于重型企业应用程序。

我看到支持OR映射器的最强论据是开发人员的生产力。

我怀疑ORM运动的一个大动力是开发人员偏好保持持久性不可知(不关心数据是否在内存中[除非缓存]或数据库)。

对于本地和小型Web应用程序,ORM似乎是非常出色的时间保护程序。

也许我看到的最好的建议是从client09:使用ORM的设置,但使用存储过程对数据库密集型的东西(AKA当ORM似乎是不够的)。

+2

CSLA不是一个OR映射器。这是一个普遍的误解。 – 2011-03-17 18:49:30

+1

也许这对你来说是最新的。 http://stackoverflow.com/questions/404083/is-orm-still-the-vietnam-of-computer-science – dkretz 2011-03-21 23:37:53

回答

4

我是一个多年的专业SP,并且认为这是做DB开发的唯一正确方法,但是我已经完成了最后的3-4个项目,我在EF4.0中完成了w/out SP和改进在我的工作效率方面真的令人敬畏 - 现在我可以用几行代码来完成这些事情,而这些代码将会在一天之前带走我。

我仍然认为SP对于某些事情很重要(有些时候你可以通过精心选择的SP来显着提高性能),但是对于一般的CRUD操作,我无法想象会回头。

所以对我来说简短的答案是,开发人员的生产力是使用ORM的原因 - 无论如何,一旦你完成了学习曲线。

1

存储过程非常适合将数据库逻辑封装在一个地方。我曾参与一个只使用Oracle存储过程的项目,目前正在使用Hibernate。我们发现开发冗余过程非常容易,因为我们的Java开发人员不熟悉PL/SQL包依赖关系。

作为该项目的DBA,我发现Java开发人员更喜欢将所有内容都保存在Java代码中。你遇到了偶尔的问题,“为什么我不能循环所有刚刚返回的对象?”这导致了一些“为什么不是索引照顾这个?”的问题。

使用Hibernate,您的实体不仅可以包含其链接的数据库属性,还可以包含对它们采取的任何操作。

例如,我们有一个任务实体。人们可以添加或修改一个任务等等。这可以在命名查询中的Hibernate实体中建模。

所以我会说去一个ORM设置,但使用数据库密集的东西程序。

将SQL保留在Java中的一个缺点是,运行开发人员使用非参数化查询将应用程序打开到SQL注入的风险。

+0

为了回应:“使用Hibernate,您的实体不仅可以包含其链接的数据库属性,还可以包含对他们采取的任何行动。“但是我可以在没有ORM的情况下得到它。此外,单一的责任也必须在这里发挥作用。 Dto的作用是什么:传输数据或基于计算的关闭值? – RBZ 2011-03-31 20:15:27

3

另一种方法......现在,随着无SQL运动的增加,您可能想尝试使用对象/文档数据库来存储数据。这样,你基本上就会避免那个OR Mapping的地狱。将数据存储为应用程序使用它们的数据,并在工作进程中对场景进行转换,以将其转换为更多关系/ OLAP格式以供进一步分析和报告。

1

以下是我的私人意见,所以它是比较主观的。

1.)我认为需要区分本地应用程序和企业应用程序。对于本地和一些Web应用程序,直接访问数据库是可以的。对于企业应用程序,我认为更好的封装和权限管理使存储过程最终成为更好的选择。

2.)这是ORM的一个大问题。它们通常针对特定的查询模式进行优化,只要您使用那些生成的SQL通常具有良好的质量。但是,对于需要靠近数据执行以保持高效的复杂操作,我的感觉是,使用手动SQL代码是stilol的方式,在这种情况下代码会进入SP。与直接访问“松散”数据集(即使这些数据是键入的)相比,处理作为数据实体的对象也是有益的。将结果集反序列化为对象图是非常有用的,无论结果集是由SP返回还是从动态SQL查询返回。

如果您使用SQL Server,我邀请您看看我的开源bsn ModuleStore项目,它是一个DB模式版本控制框架,并通过一些轻量级的ORM概念使用SP(调用对象时的序列化和反序列化SP)中。

相关问题