ORM是否必要？
ORM可以防止注入作为附加功能，SQL也可以带来反注入机制。ORM的主要作用是将数据库域的对象映射到面向对象的域中，因为开发人员更熟悉它们。
开发人员在开发时更倾向于用对象的方式思考
虽然大多数ORM工具还提供接口，如组，加入和总和，ActiveRecord实际上提供了内在的连接，它必须拼左连接和交叉连接，但它实际上并没有多大的帮助。
直接写作是最简单、最直接的方法。
因为在OLAP应用程序中，思维不是面向对象的，而是面向主题、维度和度量的核心。
ORM的基本含义是将这个抽象结构暴露到应用程序代码中。
当您直接访问数据库时，结构是外部的，在文档内部和程序员的头脑中。代码中没有物理对应关系。ORM为您提供了物理结构。具体来说，当ORM时，您处理字段通信，当您使用SQL直接操作时，这很明显，您使用大脑将业务逻辑与SQL相匹配。
另一种方法是
工程上没有绝对必要的东西，但是工程上说，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的复杂查询可以手动处理。
最后：我觉得任何语言都是相通的吧，没有什么必要不必要。
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选择直接读取数据库是最好的，最快的。可以省略命令部分，而不是使用应用程序层，但是如果项目很大，最好使用命令。
在实际开发中，我认为你应该敞开心扉，不要局限于规则。它是为简单、效率和实用性而设计的。所谓的标准也是为了这个目的。
