Thinking in sky

     摘要: 人生像個舞臺，請良家少女離開。
同樣的，Freemarker和Velocity愛好者請跳過本篇。與棄用webwork而單用Spring MVC Controller接口的理由一樣，Freemarker本來是一樣好東西，還跨界支持jsp 的taglib，而且得到了WebWork的全力支持，但為了它的非標準化，用戶數量與IDE的缺乏，在View層我們還是使用了保守但人人會用，IDE友好的JSP2.0 配合JSTL。

對于B/S結構的企業應用軟件來說，基本的頁面不外兩種，一種是填Form的，一種是DataGrid 數據列表管理的，再配合一些css, js, ajax的效果，就是View層要關注的東西了。
  閱讀全文

     摘要: 目前的Web Application大多采用流行的基于B/S模式的三層架構開發，這里的三層架構指的就是Web層、業務層和數據訪問層。采用分層的開發方式有很多好處，下面只簡單地來說兩點：

　1：分層開發使不同的開發人員關注他們擅長的特定層面，有助于開發優質的系統。因為很少有程序員可以精通從JS，CSS，DHTML到struts再到 hibernate直至最后的數據庫設計這一整套開發流程所要使用到的所有技術。大家各司其職，全力關注自己擅長的層面，這要比一個人或一個小組負責某一模塊從頁面到最底層的開發方式要好的多。

　2：.分層分離了邏輯，使得系統結構層次明晰，系統變得靈活和易于維護。開發人員應該盡量使系統的各層之間保持相對獨立的松耦合狀態，這是實現分層的必要條件，也是構建良構系統的重要保證。

  閱讀全文

     摘要: Struts與Webwork的扇子請跳過本篇。

MVC不就是把M、V、C分開么？至唯物樸素的做法是兩個JSP一個負責View，一個負責Controller，再加一個負責Model的Java Bean，已經可以工作得很好，那時候一切都很簡單。
而現在為了一些不是本質的功能，冒出這么多非標準的Web框架，實在讓人一陣郁悶。像Ruby On Rails那樣簡捷開發，可用可不用，而且沒有太多的限制需要學習的，比如Webwork這型還可以考慮。但像Struts那樣越用框架越麻煩，或者像Tapestry那樣有嚴重自閉傾向，額上鑿著"高手專用玩具"的，用在團隊里就是不負責任的行為了。

  閱讀全文

     摘要: 因為Spring自帶的sample離我們的實際項目很遠，所以官方一點的model層模式展現就靠Appfuse了。

但Appfuse的model層總共有一個DAO接口、一個DAOImpl類、一個Service接口、一個ServiceImpl類、一個DataObject.....大概只有受慣了虐待的人才會欣然接受吧。
另外，Domain-Driven逢初一、十五也會被拿出來討論一遍。

其實無論什么模式，都不過是一種人為的劃分、抽象和封裝。只要在團隊里理解一致，自我感覺優雅就行了。
我的建議是，一開始DO和Manager一生一旦包演全場，DO作為純數據載體，而Manager類放置商業方法，用 getHibernateTemplate()直接訪問數據庫，不強制基于接口編程。當某天系統復雜到你直覺上需要將DAO層和Service層分開時，再分開就好了。
  閱讀全文

     摘要: 人人都愛Spring加Hibernate。
但Spring MVC+hibernate的Sample如Appfuse的代碼卻算不得最簡潔優美好讀，如果在自己的項目中繼續發揮我們最擅長的依樣畫葫蘆大法，美好愿望未必會實現。
所以，Pramatic精神不滅。這個系列就是探尋最適合自己的Spring+Hibernate模式。

I-配置文件簡化

我厭倦一切配置文件繁重的框架。
最好的情況是，框架提供極端靈活復雜的配置方式，但只在你需要的時候。

Spring提供了三種可能來簡化XML。隨著國內用戶水平的提高，這些基本的簡化技巧大家都已掌握。

  閱讀全文

     摘要: 在初始化一個類，生成一個實例的時候，newInstance()方法和new關鍵字除了一個是方 法，一個是關鍵字外，最主要有什么區別？它們的區別在于創建對象的方式不一樣，前者是使用類加載機制，后者是創建一個新類。那么為什么會有兩種創建對象方 式？這主要考慮到軟件的可伸縮、可擴展和可重用等軟件設計思想。   閱讀全文