项目里该不该用ORM？

最近在用python写支付系统，正在纠结该不该用ORM来限制下

回复内容：

个人经验，各个一开头立志简洁不用orm的项目，随着业务复杂度提高，最后都发展出自己的一套残缺版orm 大的项目还是推荐ORM。如果你裸写SQL，随着业务和人员的增加你也会试着封装与DB连接的模块，那么恭喜你，你自己写了一个ORM。 使用 ORM 的好处：

1. 避免裸写 SQL 语句，一个是看起来简洁，另一个是借助 ORM 框架防止 SQL 注入

2. 将 Data 抽象为 Object，由此可以融入现有的 OO 编程方法

缺点：

1. 据说 ORM 性能不行

不过以我自身的姿势水平，还没到考虑 ORM 对性能消耗的地步，另外从周围前辈们的经验来看，基本也都推荐使用 ORM 作为最佳实践 why not?
再说了，object在mvc里还用得上呢

对于复杂的逻辑
可以自己写sql啊
然后让mapper做or映射 一开始决定不用ORM的，最终都被逼得自己重新造了个蹩脚的ORM*；
一开始决定使用ORM的，最终都被逼得绕开ORM自己挽起袖子裸写SQL。
药丸！ 我不用……

然后，我创造了*……

现在我的原则是，后台系统坚决用，挂在前面的网站最好不用。
orm要用好不容易，特别很多滥用级联的，
本来用json序列化一个对象，结果序列化了一个数据库……
所以，当你不知道用不用级联好的时候，那还是最好不要用了…… 我觉得稍微大一点的项目，都要用，业务模型一复杂起来，如果随便修改一个东西，我要修改很多处的话，很容易出错。
效率问题，sqlalchemy已经为我们做到很好很好了，比我们很多人手写的sql效率都要高。如果确实担心效率问题，你完全可以在常用接口，手写sql，其他还是用orm。
至于上面所说的，互联网公司不用，更是扯淡。互联网公司的产品迭代非常快，改动比较多，要是有200个接口，全是用sql写，你很容易就会出错。
我目前用flask框架作为http前端，sqlalchemy做orm，twisted用作tcp服务器，twisted方面，基本只访问redis，就是以为twisted本身自带的dbpool基本都手写sql，业务模型稍微一修改，sql语句都要找半天，真是浪费时间。
还有上面说的，多个数据库，或者读写分离的，拜托，大哥，这个问题sqlalchemy不知道哪年就解决了。
还有缓存问题，我现在基本都用redis作为缓存，基础数据redis里放一份，sql里面放一份，同时更改。常用查询，完全可以自己做一个缓存，这个很难吗？ 本来倾向于高效SQL，现在人多了开始用简单ORM，提高开发效率，解决数据库切换问题。
至于性能，可以用缓存。 选用灵活支配SQL的ORM，谁用谁知道。 不用浪费时间。不如用。
SQLAlchemy用起来不复杂。手写更复杂。
======
能少些代码，就不要多写。无论如何，这个策略错不了。