據(jù)以往的經(jīng)驗(yàn)portlet通常分為以下幾種：
1、在門戶中實(shí)現(xiàn)“快捷方式”的portlet，這種portlet通常僅僅顯示另外一個(gè)應(yīng)用的幾個(gè)功能聯(lián)接，允許用戶通過這些聯(lián)接快速訪問其他應(yīng)用。當(dāng)然，最好是能夠單點(diǎn)登錄到這個(gè)應(yīng)用的。
2、實(shí)現(xiàn)了展示集成的portlet，這種portlet通常顯示來自某個(gè)應(yīng)用的一組特定數(shù)據(jù)。假如這個(gè)應(yīng)用是web application，它通常還能允許用戶點(diǎn)擊某條數(shù)據(jù)，單點(diǎn)登錄到該應(yīng)用，然后對(duì)數(shù)據(jù)進(jìn)行操作。
3、實(shí)現(xiàn)了一定業(yè)務(wù)功能的portlet，這種portlet不僅僅可以顯示信息，還可以直接在portlet里面對(duì)數(shù)據(jù)進(jìn)行部分簡單的操作。復(fù)雜的操作似乎不適合在portal服務(wù)中處理，特別是在界面復(fù)雜的情況下。

 

以前的開發(fā)模式：
第一種很簡單，不必多說了。第二種和第三種里面，我們通常寫一個(gè)dao和一個(gè)portlet，portlet作為控制器和邏輯實(shí)現(xiàn)者，而dao實(shí)現(xiàn)數(shù)據(jù)訪問。這樣做，挺簡單的，但彈性比較差。我們分別以第二種、第三種portlet為例來說明
假如是第二種porltet，這個(gè)dao通常來自一個(gè)application中現(xiàn)存的一個(gè)dao，必須要把這個(gè)dao以及所有相關(guān)的類拷貝到portlet項(xiàng)目中，一旦application 發(fā)生變化，那么你要重新拷貝一份，而且你的portlet也會(huì)有較大的修改，因?yàn)闃I(yè)務(wù)邏輯在portlet中實(shí)現(xiàn)的。
假如是第三種portlet，隨著需求的演化，它很有可能發(fā)展為一個(gè)獨(dú)立的應(yīng)用。當(dāng)它發(fā)展到這個(gè)程度的時(shí)候，你的控制器和業(yè)務(wù)邏輯就必須要重寫了。

 

因此，我們現(xiàn)在準(zhǔn)備改進(jìn)portlet的開發(fā)模式。在新的模式中，portlet所用的數(shù)據(jù)訪問對(duì)象(dao)和業(yè)務(wù)邏輯服務(wù)對(duì)象(service)均來自一個(gè)獨(dú)立的web application中。當(dāng)然portlet不再直接訪問dao，也不會(huì)直接訪問service。portlet是一個(gè)非常簡單的控制器，當(dāng)它實(shí)現(xiàn)邏輯的時(shí)候，它會(huì)調(diào)用一個(gè)agent，這個(gè)agent幫它訪問處于另一個(gè)web application中的服務(wù)。這樣一來邏輯的實(shí)現(xiàn)就更加集中了，你不再有機(jī)會(huì)因?yàn)橐粋€(gè)同樣的需求變更而修改兩處代碼。另外，從一個(gè)簡單的portlet項(xiàng)目發(fā)展到一個(gè)強(qiáng)大的web application也成了自然而然的事情。在獨(dú)立的應(yīng)用中，service 需要經(jīng)過一些簡單地包裝，以便portlet可以通過agent遠(yuǎn)程地訪問。agent和remoteservice的實(shí)現(xiàn)都非常簡單，基本結(jié)構(gòu)是固定的，具體的邏輯可以通過delegate的方式非常方便地生成實(shí)現(xiàn)代碼。agent和remoteservice通過hessian協(xié)議交互。