ORM，介面封裝在 ORM 機制內部，不對外暴露，理論上防止了 SQL 注入。
但是，外界訪問你的網站不可能直接使用你的物件介面，也就是說你還要提供一個從 on-wire protocol 到你的物件介面的轉換。
這個轉換的 decode/encode（或者叫做 serialize/deserilize 或者 parsing）也同樣存在被 malformat 資料攻擊的問題。
你只不過把一個叫做「SQL 注入」的特定攻擊變成了你自定義介面格式的攻擊而已。
所以，針對 on-wire 資料，避免攻擊的方法是儘量減少格式的複雜度和功能（從這個角度說，你的自定義格式應該比 SQL 的複雜度和功能要低，這是好的），而且儘量用形式化方法來定義和解析格式（比如說，用真正的 BNF 和 parsing 來解析 text-plain 資料就比用 blindly-replace 或者 regexp 解析受到攻擊的威脅低）。在有些情況下，使用 pre-compiled SQL 來接受引數就更好，因為這時的引數已經無法修改 AST。
所以，這是一個要綜合考慮的問題。比如說，你的 ORM 可能很重量級，而降低威脅的能力可能還不如就簡單的採用 pre-compiled SQL。
所以不能！！！！！！！！
ORM，介面封裝在 ORM 機制內部，不對外暴露，理論上防止了 SQL 注入。
但是，外界訪問你的網站不可能直接使用你的物件介面，也就是說你還要提供一個從 on-wire protocol 到你的物件介面的轉換。
這個轉換的 decode/encode（或者叫做 serialize/deserilize 或者 parsing）也同樣存在被 malformat 資料攻擊的問題。
你只不過把一個叫做「SQL 注入」的特定攻擊變成了你自定義介面格式的攻擊而已。
所以，針對 on-wire 資料，避免攻擊的方法是儘量減少格式的複雜度和功能（從這個角度說，你的自定義格式應該比 SQL 的複雜度和功能要低，這是好的），而且儘量用形式化方法來定義和解析格式（比如說，用真正的 BNF 和 parsing 來解析 text-plain 資料就比用 blindly-replace 或者 regexp 解析受到攻擊的威脅低）。在有些情況下，使用 pre-compiled SQL 來接受引數就更好，因為這時的引數已經無法修改 AST。
所以，這是一個要綜合考慮的問題。比如說，你的 ORM 可能很重量級，而降低威脅的能力可能還不如就簡單的採用 pre-compiled SQL。
所以不能！！！！！！！！