Atitit.数据操作dsl 的设计 ---linq 方案
?
?
Atitit.數據操作dsl 的設計 ---linq 方案
?
1.1. sql與api方式1
1.2. Linq方案與stream方案的選擇,1
1.3. 前綴表達式 vs 中綴表達式1
1.4. 要不要字符串分隔符1
1.5. 盡可能的兼容sql標準2
1.6. 多數據源的支持2
1.7. 結論2
1.8. 最終結果如下2
?
1.1.?sql與api方式
對于數據操作,目前常用的倆中方案sql與api方式,api里面又分為linq方案與stream方案。。
?
一下是他們的比較原則上,以人類可讀性為優先。Sql的可讀性是最強的,單他的機器可讀性就是最差的。。。Api方式則相反,易于解析,犧牲了部分人類可讀性,來換取方便的機器解析。。
?
Sql的解析比較困難,不太適合直接作為dsl來使用。。當然如果數據源是數據庫的話,已經實現了sql的解析了,就可以使用sql作為dsl來使用了。。如果是其他的數據源比如list,就自己實現解析sql來查詢list,就比較麻煩了。。
?
1.2.?Linq方案與stream方案的選擇,
linq是stream的特列。專門化的一種dsl,可讀性更好,類似sql,而sql幾乎作為實際操作的一種標準dsl,符合標準比較好,容易學習。。絕大部分場合下,應該使用linq方式。。
?
部分常見的數據結構,可以特化stream api來用,stream api有著更加靈活和簡便的操作可以對特定操作。
?
作者::??★(attilax)>>>???綽號:老哇的爪子?(?全名::Attilax?Akbar?Al?Rapanui?阿提拉克斯?阿克巴?阿爾?拉帕努伊?)?漢字名:艾龍,??EMAIL:1466519819@qq.com
轉載請注明來源:?http://www.cnblogs.com/attilax/
?
?
1.3.?前綴表達式 vs 中綴表達式
Linq的實現模式有倆中,一種是api 前綴表達式模式,此種模式容易解析,單可讀性稍微差點。 ?Api中綴表達式,容易解析,可讀性強,但是,此類模式工作量龐大,一般使用機器生成,會帶來同步維護性問題,放棄。。
?
?
1.4.?要不要字符串分隔符
Sql使用單偏好作為字符串分隔符,其他編程語言使用雙引號,但是帶來連解麻煩的問題。
考慮到可讀性,以及機器解析的需要,反正以及分割的很小單位表達式了,容易解析的,就無需字符串分隔符了。。
?
1.5.?盡可能的兼容sql標準
?
1.6.?多數據源的支持
內存數據,string,list ,cache,nosql,文件,excel,數據庫等均可以利用linq來查詢與操作
?
?
1.7.?結論
所以折中考慮下,人類可讀性優先考慮,但是開發簡單性也要保證。。最終的比較好的方案就是在大操作上 from where等使用api函數模式,但里面的條件表達式等使用sql模式的文本中綴表達式模式,方便機器解析。。
?
?
?
1.8.?活動發起計劃:
兄弟們,我們聯合起來,搞個linq呀,我們的目標:
---多數據源的支持:內存數據,string,list ,cache,nosql,文件,excel,數據庫等均可以利用linq來查詢與操作
?
實現思路:先把linq里面的表達式簡單詞法分析,轉換為全部的api函數式前綴表達式結構。構建ast,然后執行語法解析。。即可。。
?
1.9.?最終結果如下
List list=ListUtil.addMapFromStr(“name:李明,age:11”).addMapFromStr(“name:劉利,age:17”).toList();
List<Map> result_list= select(“name,age”).from(list).where(“name=李明”).and(“age>12”).orderby(“name,age desc”);
?
實現思路:先把linq里面的表達式簡單詞法分析,轉換為全部的api函數式前綴表達式結構。構建ast,然后執行語法解析。。即可。。
?
轉載于:https://www.cnblogs.com/attilax/p/5521887.html
總結
以上是生活随笔為你收集整理的Atitit.数据操作dsl 的设计 ---linq 方案的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: lucas定理 FOJ 2020 组合
- 下一篇: linux timeline