《四》玩花樣
從四人幫整理的設計花式開始，花式被認為是一種可重複利用的，由經驗得來的比較好解決常見問題的方法。j2ee應用的花式很多，也因為它麻煩最多，在各個層上都有，其作用也五花八門，清晰化構架，提高系統效能等等，但它們基本不是去解決某個特定邏輯問題，而是帶著強烈的結構花式的味道。sun推薦的core j2ee pattern套路成了乙個花式系統，這些花式的產生，基於某些特定的原則和考慮，而一些原則和考慮也是因為ejb的不足而引起。下面我舉一兩個簡單的例子說明。
oracle的raghu kodali的演講:ejb2.1.vs.ejb3效能比較，很明顯地在效能方面強調了ejb3的好處。我不想再重複他的觀點，只是從他的演講引出ejb 開發的老朋友花式。效能比較當然是響應時間和吞吐量，注意到他測試的例子有兩個花式，dto和session facade。我也從dto講起。
很明顯，dto是第乙個在ejb3中被滅的花式，原因很簡單，ejb3的entity可以被線性話，這個在輕量級容器中已經被討論過，在hibernate in action一書裡，dto被視為是多此一舉的東西，因為可以把乙個線性話的pojo看作dto來減少round trip。(在此書中的dto討論中，我們再次看到有些概念的空洞和片面。)在
raghu比較用dto和不用dto的ejb3的結果中，我們看到，在250個模擬使用者開始，ejb3開始顯示微弱的效能的優勢，曲線暗示著負載越多，效能越好。所以我在他的結論上加一句，ejb3的entity不但效能更好點，而且不用重複**。
在使用session facade的測試中，我很驚訝地看到不管是交易率還是平均響應時間，從25個使用者開始ejb3就有明顯的優勢。但是，我馬上就發現這些效能的提公升基本是基於乙個大換血的持久層，如果ejb3用同乙個花式來和ejb2.1比拼，其優勢完全靠乙個更全新的透明持久方案，這也暴露了原來cmp和所用的cmr的弊端，它們不但效能差而且限制多，拿cmr來講，只能用雙向關係。
其他的花式例如dao,bd等等在ejb3仍然是有意義的，也是輕容器經常會用到的。在輕容器中我們可能談得更多的是交易相關的設計方案。我說他們是方案，是因為花式認證需要在社團裡通過三個以上的系統解決問題的考核，即rule of three。而這些方案最初只在輕容器中出現，我想在不久的將來，他們可能是ejb開發者的口頭禪:
entity manager per request;
entity manager-per-user-session anti-pattern.............
EJB3，我們究竟得到了什麼 （1）
一 序言 在大多數情況下，j2ee是吃力不討好的東西。它似乎永遠為複雜的應用做準備，從來沒有花多少心思在小型的，不那麼複雜的應用上，以致開發這些不那麼複雜的系統，成為了複雜的任務。什麼是複雜的系統呢？工作在分布環境上，有多個不同型別的後台資料庫，有非同步的訊息處理和複雜工作流的系統.確實，j2ee使...
失去，得到，我們得到了什麼
今天早晨坐動車 d字頭的快速列車 從鄭州到南京。在平穩的列車上，我迷迷糊糊的睡著。等到醒來已經過了商丘。眼望窗外的風景，雖是冬天了，倒還有些農田綠綠的。在大片農田間散落著零零星星的農舍。多半看上去都是非常破舊的。遠遠看到幾間聚集在一起的農舍著實的很破舊，甚至還有一間房頂都塌落了一半。在農舍的小院中，...
我們丟掉了什麼？又得到了什麼？
你，還記得你的初心嗎？又或者說，你已經迷失了呢?不是雞湯，只講切身體會的感悟！首先從我剃掉我的一頭長髮說起吧。一開始為了彈結他，留起了一頭長髮，到後面變成的中分，我都沒有想過有一天會把它剃掉，沒有所謂的遊戲和賭注，是因為上乙個月裡自身的情感和目標之間有一些衝突，後來發生了一些事情，也就釋然了，想讓自...