談談IBatis的動態SQL應該改進的架構設計！

[b]sqlmap?的動態sql是什麼？[/b]

sqlmap?的動態sql就是一條sql語句，根據傳入的引數情況動態拼裝出sql。這也是ibatis引以自豪的強大功能。

像ibatis的動態sql控制一樣，要有足夠的簡潔的控制命令:

1. if

2. choose(when,otherwise)

3. where,set

ibatis還有乙個foreach，我覺得沒什麼用，不需要支援（歡迎舉例反駁我）。

if用來控制條件判斷，如：

select * from blog where state = „active‟ and title like #

choose用來控制if/else if/else if.../else語句。


....
select * from blog
state = #
and title like #
and title like #
update author
username=#,
password=#,
email=#,
bio=#
where id=#

[b]與ibatis不同，我希望引數是強型別的:[/b]

在sql引數進行條件判斷時，我希望雖然傳入的引數可能都是字串，但在執行條件判斷時，能夠自動轉換並按照正確的型別做條件檢測。比如上面的：


state = #

如果state是乙個int型別，我希望寫成：


0 」>
state = #

這樣準確性高，判斷語句更簡潔，而且不容易寫錯。再比如日期，則可以更容易寫條件了，如：


readonly = true

當然，對於引數的型別我需要自己指定，免得出錯。如：


0 」>
state = #
readonly = true

對於引數state，我指定資料型別借用領域物件的blogstate屬性為其型別（blogstate為int型別變數）；對於createdtime，我直接指定型別為datetime，如果傳入的引數為字串，按照"yyyy-mm-dd"格式解析成時間。

[b]當然，無論如何動態，引數必須要按照preparedstatement執行:[/b]

避免被sql注入，這一點無容置疑了。

[b]相比ibatis的ognl，我覺得支援型別自身方法更實用 :[/b]

舉例來說，對於ibatis的例子：

select * from blog where state = "active" and title like # and title like # and featured = 1

假設這裡的state為string型別（，雖然從sql優化的角度不合適），我更希望寫成這樣：


select * from blog where state = "active"
0」>
and title like #
0」>
and title like #
and featured = 1

因為雖然這兒傳入的blog引數看起來很美，但大部分情況下我需要傳入的是頁面提交的引數，是乙個map。在map中我希望相容性更好，不僅能處理null，傳入的空字串也能處理掉。當然了，如果title為null，title.trim()這些直接返回false即可，不要報空指標異常。

這樣寫起來，看起來會更加整潔。而且實現起來的執行速度肯定要比ognl快很多，struts2對ognl的大量使用就是乙個效能警示。

[b]我沒想好，是否需要支援複雜的判斷邏輯 :[/b]

比如，支援括號，如：


0 and order ~= 'desc') or (id > 10 and name == 'abc') 」>
state = #

這種複雜的邏輯，支援括號，支援or操作符，支援字串包含匹配，大小寫不敏感匹配等，是否有必要？或者哪些有必要？

也許更多的運算子比較有價值，括號之類的就算了。

其他的哪？

歡迎討論。