javadsl

A. java query dsl 表連接處理 為什麼sql語句中帶with

WITH 通常與AS連用，也叫做子查詢部分。用法：
1). 可用來定義一個SQL片斷，該片斷會被整個SQL語句所用到。
2). 為了讓SQL語句的可讀性更高
3). 也有可能是在UNION ALL的不同部分，作為提供數據的部分。特別對於UNION ALL比較有
用。因為UNION ALL的每個部分可能相同，但是如果每個部分都去執行一肆滲遍的話，則成本
太高，所以可以使用WITH AS短語，則只要執行一遍即可。
例如：下面兩種表達的是唯雹盯同一種意思：指和
①with alias as (select * from pra)
②select * from pra;

以上部分都是抄來的，自己實際使用時，倒是沒注意到with。

B. 什麼是DSM

DSM：Domain-Specific Modeling
板橋里人 http://www.jdon.com 2006/5/1（轉載請保留）

當DSL（Domain-Specific Languages）誕生時，不少人比較激動，歡呼一個新的語言時代到臨。其實，這不是計算機領域的新語言，而是一種新的建模語言。

DSL是一種專門供領域建模專家（也就是系統分析師）使用的語言，這些領域專家不同於程序高手，他們有一套自己認知世界和表達世界的思維和方式（如UML），因此，他們不感興趣於軟體設計細節，希望軟體能夠按照他們分析設計的結果去運行和執行就可以了。

其實，現如今在Java和.NET分治天下軟體語言之時，不可能再有對和Java等同樣層次的新語言的新需求， 因為大家都已經經歷過優美動人的語言故事，新語言陷阱是每個人理性的認識。因此，聰明的專家發現，DSL特徵不是發明新輪子，而是提供一種面向領域建模方便的工具語言，類似UML，但UML不能再勝任這樣的工作（見UML和Java的阻抗），MDA有待進一步完善提高，建模專家需要的是DSM（Domain-Specific Modeling）。

提高開發生產效率

按照軟體生產效率研究（Software Proctivity Research）, Java的平均生產率僅比BASIC高20%, C++不會好過Java，當今Java和.NET語言紛爭帶給程序員很多選擇的痛苦，我們把更多注意力關注在對象、組件和框架（objects, components, and frameworks）等概念上，但是開發效率並沒有比20年前有顯著增長，從匯編語言到BASIC是400%的增長，在當前21世紀，我們應該怎樣完成這樣的跳躍式發展？

UML能否勝任？

象UML這樣傳統的建模語言並不能提高軟體生產率，你需要在兩處維護信息系統：語言代碼和UML模型，為保持一致來回奔命，我們知道，java/C++/BASIC都將被編譯器編譯成匯編語言，可是有人看到過這樣情形：開發者手工更改編譯器並且試圖使C++代碼和匯編代碼保持一致？可是這種現象會發生在UML模型和語言代碼之間。

當然，UML有其優點：作為能夠迅速被讀懂的虛擬符號，UML世界現在吵吵嚷嚷，一半人發現UML並不能表達他們在建模時需要的一些概念，因此要求將入一些新的東西進入UML核心標准；可是還有另外一些人則認為UML太復雜，應該從UML核心元素中減去一些元素。當UML試圖適合所有的人時，它就不能大力提高其抽象層次了。

這是目前基於UML的大多數MDA工具發生尷尬現象。MDA工具製造商發現它們僅僅能夠比手工編碼提高生產效率(study)35%，遠沒有我們希望的400%革命性跳躍。

什麼是DSM？

只有提高抽象層次，將軟體直接面向建模專家或系統分析師，然後運用自動化代碼生成技術，這樣才能高質量大幅度快速開發出軟體系統，在OOPSLA（領先的軟體工程會議），大家認為DSM可能是一種解決方案。Bill Gates 和 Grady Booch也發表過同樣觀點。

DSM意味Domain-Specific Modeling領域定義建模，通過使用領域概念直接指定解決方案，DSM提高了超越程序代碼之上的抽象層次，最終軟體產品將從高層次的設計中直接自動產生，這樣一個自動過程是可以實現的，因為 語言和代碼產生器可以滿足某一個公司或領域的需求，建模專家使用定義這個自動機器，而程序員只管使用即可。

實踐經驗已經證明：DSM比現有方式（包括基於UML的MDA）效率提高5-10倍，正如Booch說的那樣： 」當建模概念可以直接映射到領域Domain，而不是計算機具體技術概念時，MDA的價值已經完成「，這句話的意思是： MDA已經證明我們可以直接從領域專家Domain觀點直接建模，而不必拘束於具體的計算機技術概念，或者說：直接由有經驗的系統分析師/建模專家分析設計進而生產出軟體系統已經被MDA證明是可行的了，MDA的價值也就在於此，
Booch等人寄希望於使用DSM替代MDA。

由建模專家定義有關領域和組件的代碼產生器，這樣做的結果要好於大多數開發者手工開發。從MDA教訓來看，大家認識到：不可能有「一種尺寸適合所有身材」的代碼產生方案，不必象MDA那樣疲於往來返工，DSM所做的正如將代碼編譯成匯編語言的編譯器所做的。

DSM工作原理

首先，每個行業都有一些經驗豐富行業專家，俗成系統分析師，他們對業務系統非常熟悉，但是不太了解軟體技術，由這些專家定義一個包含域概念和規則的域定義語言（domain-specific language），並且定義這些域概念和規則映射到代碼產生器的映射；實際上這些建模專家所要表達的就是：我們的需求應該看上去是怎樣？我是怎麼寫代碼的。

然後，其他開發者就使用建模語言根據前面定義的規則製作模型，最後，代碼將自動產生，因為建模專家參與了定義代碼生產器，這樣最後產生的代碼質量要高於正常程序員手工完成的代碼質量。更重要的是，製作模型將比手工寫代碼更快。

與MDA區別

DSM與MDA主要區別是：MDA工具商自己定義代碼產生器，這些代碼產生器第一次看非常好，但是以後就變樣走味了，難以適應需求的變化。.

DSM中，由你控制DSL和代碼產生器，這些工具可以被調整以適應你自己的系統，作為開發者，你只需要定義DSL和實現自己的代碼產生器，所有這一切都是由你來定義控制，正所謂定製性強。

DSL案例

TSS上最近的文章「Improving Developer Proctivity with Lightweight Domain Specific Modeling」演示了如何使用DSM實現輕量建模的過程，共分五步：

ArgoUML 能夠用作定義DSL模型，開發人員能夠設計DSL模型適合問題域。

將 ArgoUML模型轉為Eclipse模型格式的Ecore.

使用Eclipse的插件JET模板定義代碼如何產生。

Ecore模型輸入到模板定義中，然後再定義Ecore模型中的模型元素和帶有Merlin的JET模板之間映射。

最後結果是產生最終代碼。