背景
提起orm，在我开发这几年可是阴魂不散，因为我的开发没人带，全是自己琢磨，好处是很多东西都懂，都理解的透彻，缺点是见得少，接触少。而我一直没用orm，但是又到处听说orm，但我总想不明白有啥用处，还感觉挺麻烦，当初也主要靠sql解决事情。也就一直没用，主要也是有点不愿意改变自己的意思。
有一次，一个项目，我搞来搞去，自己搞了套类似orm的东西，想替代实体类， 后来反转来去，终于发现orm的优势了。其实orm与sql是共同必须的，新人容易纠结在过程当中无法自拔，只要融会贯通了就简单了。
以下转载部分知识当初为了记下这个事情找的文章，不是个人观点。
转载部分
目前我们所接触到的许多项目开发，大多数都应用了 ORM 技术来实现与数据库的交互，ORM 虽然有诸多好处，但是在实际工作中，特别是在大型项目开发中，容易发现 ORM 存在一些缺点，在复杂场景下，反而容易大大增加开发的复杂度及牺牲灵活度。使用 ORM 不写 SQL 而使数据库交互变得简单易行，是否能够达到预期效果，要画一个问号。
主要问题可能存在于以下几点：
1.大幅度牺牲性能。
2.虽然隐藏了数据层面的设计，但并没有从根本上降低数据访问复杂度，只是将复杂纬度从一个点（SQL，存储过程）转移到另一个点（代码），以EF为例，最终生成的代码性能与C#书写有很大关系，且难以通过成熟的数据库技术反查性能瓶颈。
3.对于复杂查询，ORM 力不从心，虽然从技术角度说实现肯定都能实现，但是代价是不值的。
有朋友认为 ORM 可以使不懂数据库的开发人员也能在开发中轻松实现与数据库的交互，但是，在大型项目中，让不懂数据库的开发人员做这块工作，Are you kidding me?
在我自己的项目开发经验中，ORM 还存在以下问题：
1.对于大型项目的开发，表示数据的实体类和数据库层面的持久化设计并非一一对应的关系，使用ORM根据数据库表生成一一对应的实体类模型，并不能完全适用，这是促使我实现自己的增强组件的重要原因之一；
2.在实体类中，需要进行其它编码工作，如额外的属性定义，附加额外的Attribute，部分功能实现和业务操作等，而使用ORM来生成实体类，生成时会覆盖现有实体类而导致项目自身的编码工作丢失；