ORM最核心的问题，还是性能。因为通常数据库就是系统的性能瓶颈。
PS：ORM肯定防SQL注入，这不用说，^_^
先看一个事实：是不是ORM没有JDBC/ADO.NET手写SQL快？
是的。必然的，因为ORM要比JDBC/ADO.NET多做很多很多很多事啊……
所以，我们（在大型/高并发访问项目中）就不应该使用ORM？
归纳我们的编程开发三观（性能篇）：
所以随着：
ORM因其便利、高效、作为面向对象设计/开发（OOD）的基石，已成为企业级应用开发必不可少的工具组件，完全不用ORM的项目应该已经绝迹了——尤其是新项目。
除非“面向对象数据库”能够普及……
我们期望的，始终是：功能强大，但学习成本低。
但是所有框架/组件/工具都一样：学习成本和功能成正比。
所以只有选择：
包括读取配置，都是比较消耗性能的。所以很多ORM都是在项目/应用启动的时候，一次性的完成反射和映射配置读入等工作，此后就直接使用这些已读入内容。
所以这些项目启动就会比较慢……
有些ORM会自动的完成上述工作，屏蔽了这些内容，不需要开发人员操心（比如EntityFramework）；
有些ORM需要开发人员注意（比如Hibernate），它把这个部分的工作抽象成Factory Building，那整个项目我们就只需要建一次工厂（一般用静态单例模式实现）！千万不要到处都是Factory Building。
ORM生成的SQL语句，增删改其实都还好，就我们自己手写，也就这么个样子。
日常开发中绝大部分的SQL查询，包括一些稍微有那么一点点复杂的（比如ORDER/GROUP/JOIN/子查询……）的查询，现在的ORM都可以很好的完成。
但确实还是有一些复杂查询，ORM无法自动生成，或者生成的查询比较“弱智”需要优化，这时候就需要ORM对原生SQL的支持，即：
由开发人员写好SQL语句（包括存储过程调用），交ORM执行并将结果封装成相应对象。
所以，仅仅是因为“ORM生成的SQL语句无法满足要求”而拒绝使用ORM的理由是站不住脚的。
#体会#：八二原则。
有时候我们只需要一个简单明确的数据库操作，就没有必要用session存着entity的快照啥的，花费额外的资源追踪这些entity的状态啥的。
ORM也允许我们使用一个无状态追踪的session以节约开销。
很多开发人员拒绝使用ORM是因为他们认为ORM是一个“黑箱”，不知道它具体是怎么工作的。
实际上ORM可以提供了详尽log，告诉我们非常非常多的信息。
我们应该养成查看log的习惯和能力。
和JDBC/ADO.NET一样，ORM也提供了批处理、连接池等技术
飞哥当年刚入行，.NET的ORM还没有普及。
我看到公司的代码，一定要先load()一下拿到数据生成对象，然后修改对象的属性，最后存入数据库……
于是下班路上和公司另外一个同事吐槽（其实是想秀一下自己的技术，心虚+半壶水嘛）……
他听了我说的不接话，脸上淡淡的笑容，记忆犹新！
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
