項目裡該不該用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用起來不複雜。手寫更複雜。
======
能少些代碼，就不要多寫。無論如何，這個策略錯不了。

