ORM是否必要?

发布网友 发布时间：2022-04-09 16:27

我来回答

共3个回答

热心网友 时间：2022-04-09 17:56

ORM可以防止注入作为附加功能，SQL也可以带来反注入机制。ORM的主要作用是将数据库域的对象映射到面向对象的域中，因为开发人员更熟悉它们。

开发人员在开发时更倾向于用对象的方式思考

虽然大多数ORM工具还提供接口，如组，加入和总和，ActiveRecord实际上提供了内在的连接，它必须拼左连接和交叉连接，但它实际上并没有多大的帮助。

直接写作是最简单、最直接的方法。

因为在OLAP应用程序中，思维不是面向对象的，而是面向主题、维度和度量的核心。

ORM的基本含义是将这个抽象结构暴露到应用程序代码中。

具体来说，当ORM时，您处理字段通信，当您使用SQL直接操作时，这很明显，您使用大脑将业务逻辑与SQL相匹配。

另一种方法是

热心网友 时间：2022-04-09 19:14

工程上没有绝对必要的东西，但是工程上说，ORM是极有价值的东西。当年也有人觉得 ORM 浪费资源，思路不清晰，虽然用了 Hibernate ，还是直接写 SQL ，手工操作。

什么是ORM

ORM框架采用元数据来描述对象一关系映射细节，元数据一般采用XML格式，并且存放在专门的对象一映射文件中。

只要提供了持久化类与表的映射关系，ORM框架在运行时就能参照映射文件的信息，把对象持久化到数据库中。当前ORM框架主要有三种：Hibernate，iBATIS，EclipseLink。

ORM从未从数据库中逃脱。如果你无法逃脱，为什么还要坚持呢?

有时，使用编程语言(而不是SQL(我也走了弯路，由MS讲道linq和linqtosql使用)来实现的复杂的SQL查询后台非常困难，因此，为什么复杂性的问题会出现在2、3甚至N度.

它真的能减轻开发的工作量吗?对不起，这不是放松。直接使用SQL访问(JDBC或ADO.net)相对较重。但是，复杂性并不是专注于业务的逻辑实现，而是UI层和用户交互。

如何设计查询、传入参数到IQuery

配置层XML来编写SQL语句。该程序的主要业务不是集中在这些方面，而是只关注于接口(仅针对IQuery)。对于XML层，可以自动地编写代码、复杂的SQL或人工干预，以及关于UI的复杂查询可以手动处理。

最后：我觉得任何语言都是相通的吧，没有什么必要不必要。

热心网友 时间：2022-04-09 20:49

ORM的好处是，您不必中断面向对象的过程来考虑SQL，并编写代码以使其平滑。但是缺点是有很多*，有时不像SQL那样灵活。但是能够迁移到不同的数据库还有一个好处。

一.ORM的概念是必要的，但是物极必反

RM生成的SQL质量不高，与框架相关，高、低;同样与人相关的是，熟悉SQL的人通常有更高的代码质量，这是编写由C程序员编写的良好质量的C代码的一个很好的理由，这些代码是由理解硬件的C程序员编写的。

在单位时间上提高了ORM的生产质量和效率。我想说明这一点。至于你写ORM代码是否会不可避免的比人为的好，我就是消极的态度。特别是对我来说，我认为几乎不可能超过我的手工编码的ORM。

然而，ORM允许我将一些复杂工作的人力成本压缩到可以接受的程度。例如，我正在研究一个数据建模工具。如果手工编码，我想考虑是否有一个模式，是否有serials，特定的数据库，不同的语法变化，以及不同生成的不同生成的目的。我将为自己编写一堆编译过的代码，因为我有一个成熟的、易于使用的、质量控制的ORM工具，为什么不呢?至少我可以减少3 / 4的代码。

二.ORM最终也是执行sql语句

ORM是通过提供的接口完成的，使用ORM直接获取数据，返回的数据通常是经过封装后的，资源的使用必须大于原始的SQL，在显示的时候方便，对于一个对象和一个简单的没有太大区别的组合。ORM最终执行SQL语句，我觉得我只是在用一堆代码来生成一个字符串。不可否认，它在某些地方确实很好，比如保存、添加和修改，这是很方便的。重用希望是好的。如果我只是使用orm来拼写SQL语句，我就不会有太多的感觉。实际上，我也使用ORM，在后面我使用ORM，我的前台80%是原始SQL

三.CQRS 核心就是领域层和读取数据分离

CQRS实际上是DDD的着陆框架。查询不需要通过存储库路径，所以越快越好，例如，直接使用SQL选择直接读取数据库是最好的，最快的。可以省略命令部分，而不是使用应用程序层，但是如果项目很大，最好使用命令。

在实际开发中，我认为你应该敞开心扉，不要局限于规则。它是为简单、效率和实用性而设计的。所谓的标准也是为了这个目的。