Domain Pollution Resolution

域污染解除

0. Domain 名詞解釋

首先說明一下 Domain 在本文中的意思。

<<Domain Driven Design>> 一書，令 Domain 這個詞很火。引起了廣泛爭論：哪些Logic 應該放在 Business Service Layer, 哪些應該放在 Domain Object里面。這類爭論紛紛揚揚，最后通常都上升到哲學高度，世界觀高度，認知心理學高度。如果不幸發展到極端情況，雙方很可能開始相互質疑對方的智商和對世界的基本理解能力。

這個層次的Domain 紛爭，不是本文所關心的話題。

我一向認為，設計能夠滿足如下的條件，就可以稱為是一個好的設計：能夠使用多態性，代替Hard-Coded if else switch 等邏輯分支；新需求來的時候，不需要在舊代碼里面添加if else switch等邏輯分支，而只需要加入一個新的Class；盡量避免 Package, Class 級別的交叉引用。

 

本文所關心的Domain 是一個更高的層次，類似于DSL, Domain Specific Language 里面的Domain的意思。

本文主要討論如下議題：

 

HTML是否只應該用來表示結構？

HTML是否應該包含邏輯？

HTML是否應該包含服務器端腳本邏輯？比如，JSP, Velocity, Freemarker.

HTML是否應該包含瀏覽器端腳本邏輯？比如，Java Script.

 

Java 代碼中是否應該輸出HTML標簽？比如，Taglib, Tapestry Page Component, etc?

Java 代碼中是否應該使用框架特殊的HTML View Model? 比如，XMLC, Wicket, Echo, etc.

 

HTTP Web Server本來的設計宗旨是無狀態，支持大用戶量，多連接。目前的server side的page flow, web flow, continuation, 力圖使得HTTP Web Server保持用戶的流程狀態。這種做法是否應該推薦？

 

SQL是一種可讀性很好，應用廣泛的一種DSL。如何動態拼裝SQL，一直是一個難以解決的問題。

是否應該在Java 代碼中嵌入SQL?

是否應該在Java 代碼中使用 Criteria API?

是否應該在SQL Template中加入動態語言腳本邏輯？比如 iBatis 使用XML if otherwise,  OR Bridge中使用velocity?

HQL, OQL在SQL中引入了OO語言的特性，似乎操作的是對象數據庫，而不是關系數據庫。這種做法是否應該推薦？

 

Hibernate 動態期間篡改用戶代碼的做法，是否應該推薦？

JDO靜態期間篡改擁護代碼的做法，是否應該推薦？

 

Dynamic Proxy, CGLib等動態篡改用戶代碼的做法，是否應該推薦？

Reflection繞開了 Java 的類型檢查機制，是否應該推薦？

Thread Local是一種隱式契約，相當于繞開了顯式契約（方法簽名method signature），這種做法是否應該推薦？

 

這些屬于開發模式、代碼風格方面的問題，正如所謂Code Smell的感覺一樣，也避免不了主觀的成分。所以，下面的陳述并非論斷，而只是“在我看來”。

1. HTML Template Layer

HTML應該盡量只用來表示結構，排除所有邏輯。

JSP, Velocity, Freemarker等服務器端腳本邏輯，屬于Java Code或者Script Code對HTML的污染。

不僅應該排除JSP, Velocity, Freemarker等服務器端腳本邏輯，而且應該排除瀏覽器端腳本邏輯，比如Java Script.

當然，這里不是說，不用Java Script，而是說，不要把Java Script放在HTML里面。把Java Script放在一個單獨的.js文件里面，在HTML中引入，并使用CSS把HTML Element 和 Java Script Event Handler 聯系起來。

這方面的資料有：

Unobtrusive Javascript
http://www.onlinetools.org/articles/unobtrusivejavascript/

http://www.kryogenix.org/code/browser/aqlists/

http://www.bobbyvandersluis.com/articles/goodpractices.php

如何排除HTML中的Server Side Logic呢？

Ajax!

Ajax fans一定反應迅速，給出答案。

沒錯。Ajax可以做到。Ajax的主要問題在于使用和掌握難度。

除了Ajax呢？

有幾個選擇，XMLC, Jivan, fastm, Wicket, Echo等。(and Tapestry?)

 

 fastm是我做的一個模板層，具體內容可以在此下載。

https://fastm.dev.java.net/files/documents/1911/25042/fastm1.0c.zip

 

fastm采用 XML Comment 作為文檔結構標記。注意，是結構標記，而不是邏輯標記。不含有for if else。

可見，fastm并不是毫無污染，只是沒有邏輯污染。fastm只在HTML中添加了自定義的結構標簽，也勉強算沒有違背HTML只用來表示結構的原意。

Ajax, XMLC, Jivan 的HTML很干凈，而且對HTML 結構的控制能力很強，能夠用代碼動態控制布局。fastm也能夠動態控制布局。Site mesh, tiles taglib, jsp, velocity, freemarker等做不到。

fastm 里面的例子中，包括一個分頁的例子，和一個動態組裝SQL的例子

2. Java Web Layer

Taglib, Tapestry Page Component, Echo, Wicket等在Java 代碼中輸出HTML標簽，這也是一種，而且要求在Java 代碼中使用框架特殊的HTML View Model，比如Table, List, Label, Formbean 等View Object。使用了這些框架，Java 代碼的編譯就需要依賴于這些框架了。

這相當于HTML標簽對Java 代碼的污染。

JSP, Velocity, Freemarker都不存在這種情況。Java 代碼只是提供POJO，然后 HTML里面的Server Side Script使用這些POJO．

fastm不支持邏輯，所以這個方面弱一些。fastm要求Java Code把if, else 等邏輯分支變成一個Map 結構。由于Map屬于java的基本類，所以，fastm也不需要在Java code中使用任何特殊的框架相關的view model。

3. Web Layer - Stateless or Stateful

與其在服務器端支持 page flow, web flow, continuation，那不如在瀏覽器端支持狀態。這種場合下，我覺得，正是使用Ajax的最佳場所。

我傾向于這樣的設計，服務器端盡量無狀態，如果確實需要狀態，那么盡量在瀏覽器段保持狀態。

lightweb是我做的一個Web框架。

https://lightweb.dev.java.net/files/documents/4371/25044/lightweb0.9b.zip

 

主要的特點是，URL-Centric, 鼓勵無狀態的Service Oriented設計。支持三種Service模型，

Action (like WebWork Action),

Controller (like Spring MVC Controller),

Channel (like Struts Action Dispatcher),

 

lightweb支持多級模塊尋找，使用幾條匹配規則，代替龐大的Site Map 配置文件。

lightweb查找View的時候，不是根據Site Map 文件里面的那種小型狀態機的配置（success -> showIt.jsp;  fail-> this page）, 而是直接資源定位。lightweb繼承了fastm的觀點，把template看作資源，而不是一段運行腳本。

 

Lightweb設計為IoC友好。在各個環節都暴露出插件接口。程序員可以自己選擇IoC策略?？梢圆捎靡话愕淖龇?，用一個IoC container集中管理，比如，Spring IoC, Pico, Nano等；也可以分散到各子模塊，進行管理；也可以分散到每個Action Validator里面管理。

 

4. ORM Layer

Hibernate 動態期間篡改用戶代碼，JDO靜態期間篡改用戶代碼。

令我想起黑客，木馬，夾帶，偷梁換柱等。這屬于語義上的Pollution。就是說，從原有的Source看起來，Domain Object并沒有那樣的行為，運行起來卻有那樣的行為。

iBatis采用reflection，確實干凈。但是，性能、功能上又不夠強大。某些功能的實現，確實需要代碼生成。

lightor是我做的一個ORM框架。

https://lightor.dev.java.net/files/documents/4370/25043/lightor0.5a.zip

 

lightor也需要代碼生成。區別在于，lightor不修改任何代碼，只是產生新的Mapper代碼。Domain Object運行的時候，還是你原來的Domain Object。這就避免了語義的污染。

lightor生成的Mapper代碼，可以編譯期類型檢查，可以閱讀，跟蹤，調試。這些生成的代碼，也都遵循本文的原則。Java 代碼里面不含有SQL片斷，SQL都存在于單獨的資源文件中。

（另外，不采用CGLib，也是為了實現的簡單）

lightor直接使用Native SQL。Lightor的目的不是屏蔽關系數據庫，而是恰好相反。lightor的目的是，幫助程序員更清楚地認識關系數據庫，SQL，JDBC。lightor和JDBC不沖突，可以一起使用。

lightor努力的第一個主要方向就是效率。大數據量查詢和處理的效率。

據我所知，目前只有lightor才支持大數據量批量處理，因為只有lightor不惜降低ORM的身份和封裝層次，能夠接受ResultSet作為參數。

lightor的緩存策略比Hibernate更前進了一步，把query cache 和 ID Cache集成在一起。以便得到更好的控制。并且，把緩存API暴露給程序員，以便智能的控制某個特定的緩存。

5. SQL

HQL, OQL在SQL中引入了OO語言的特性，似乎操作的是對象數據庫，而不是關系數據庫。

我感覺，這是一種語法層次上的Domain Pollution。OO語法對SQL語法的污染。

正如感覺LinkQ是數據庫查詢語法對OO語法的污染。

Java 代碼中使用 Criteria API，也屬于數據庫查詢領域對OO領域的污染。

 

SQL是一種可讀性很好，應用廣泛的一種DSL。

我的看法是，盡量把完整的SQL放到單獨的資源文件中，可以直接Copy到SQL Client就可以運行。特殊優化過的Native SQL，也是同樣的地位。

HQL, OQL阻礙了用戶對SQL進行特殊優化。

 

如何動態拼裝SQL，一直是一個難以解決的問題。

直接在Java 代碼中嵌入SQL，肯定不行。前面說了，Java里面最好不要有SQL片斷，最好放到另外的資源文件中。

在Java 代碼中使用 Criteria API? 前面也否定了。

在SQL Template中加入動態語言腳本邏輯？比如 iBatis 使用XML if otherwise,  OR Bridge中使用velocity?

這種方法還是不錯。不過仍然在SQL里面引入了腳本邏輯。

我也沒有好的做法。我采用fastm來處理。在SQL里面引入結構標記。這也相當于污染。因為SQL和HTML不同。SQL不是描述結構的，而是一門DSL。

這種做法的一個好處是，整段SQL還是可以Copy到SQL Client里面，稍微修改一番，就可以直接運行。

6. A Demo Forum

farum是我做的一個簡單的forum demo. 使用了fastm, lightor, lightweb, 也盡量體現我前面提出的原則。

https://farum.dev.java.net/files/documents/4372/25045/farum0.5a.zip

 

我覺得，使用一門語言，應該盡量發揮它的特長，而不是針對它的短處，修修補補。

Java作為靜態類型編譯語言的好處，就是編譯期類型檢查。那么如何發揮這個優勢？前面說的Mapper源代碼生成，就是一種嘗試。

另外，其它的類似的膠水粘合部分，比如，IoC, Validation等，都可以進行這方面的嘗試。目前，farum就是采用這樣的做法，自己寫的Validator Source進行validation, value setting, service implementation injection等工作。

farum沒有使用Dynamic Proxy, CGLib等動態篡改用戶代碼的做法。

盡量不使用Reflection，因為Reflection繞開了 Java 的類型檢查機制。與其使用reflection，真不如使用動態腳本語言。

當然，reflection是非常難以避免的。farum也少許使用了reflection。

Thread Local是一種隱式契約，相當于繞開了顯式契約（方法簽名method signature）。WebWork的一些用法，Spring Framework的Open Session In View，等都是采用了Thread Local。

farum沒有采用Thread Local，而是采用了另一種方法實現了Open Session In view。而且如果緩存命中，甚至不需要從connection pool中獲取Connection。

總結

<<Web開發構想>>一文中，我提出了，理想中的Web開發架構是這樣的：

開發速度快，運行速度快，結構清晰優雅。

具體到每一層。

Web框架層主要追求 開發速度快。

O/R層主要追求 運行速度快。

頁面資源層和頁面模板層主要追求 結構清晰優雅。

 

下面就是我對這些理想的初步實現。

還遠遠達不到完美的程度，而只是朝這個方向努力。

 

Template Layer

fastm

https://fastm.dev.java.net/files/documents/1911/25042/fastm1.0c.zip

 

Web Layer

lightweb

https://lightweb.dev.java.net/files/documents/4371/25044/lightweb0.9b.zip

 

ORM Layer

lightor

https://lightor.dev.java.net/files/documents/4370/25043/lightor0.5a.zip

 

A forum demo using fastm + lightor + lightweb

farum

https://farum.dev.java.net/files/documents/4372/25045/farum0.5a.zip