portlet的分类与开发

来源:百度文库 编辑:神马文学网 时间:2024/04/27 15:03:11
据以往的经验portlet通常分为以下几种:
1、在门户中实现“快捷方式”的portlet,这种portlet通常仅仅显示另外一个应用的几个功能联接,允许用户通过这些联接快速访问其他应用。当然,最好是能够单点登录到这个应用的。
2、实现了展示集成的portlet,这种portlet通常显示来自某个应用的一组特定数据。假如这个应用是web application,它通常还能允许用户点击某条数据,单点登录到该应用,然后对数据进行操作。
3、实现了一定业务功能的portlet,这种portlet不仅仅可以显示信息,还可以直接在portlet里面对数据进行部分简单的操作。复杂的操作似乎不适合在portal服务中处理,特别是在界面复杂的情况下。
以前的开发模式:
第一种很简单,不必多说了。第二种和第三种里面,我们通常写一个dao和一个portlet,portlet作为控制器和逻辑实现者,而dao实现数据访问。这样做,挺简单的,但弹性比较差。我们分别以第二种、第三种portlet为例来说明
假如是第二种porltet,这个dao通常来自一个application中现存的一个dao,必须要把这个dao以及所有相关的类拷贝到portlet项目中,一旦application 发生变化,那么你要重新拷贝一份,而且你的portlet也会有较大的修改,因为业务逻辑在portlet中实现的。
假如是第三种portlet,随着需求的演化,它很有可能发展为一个独立的应用。当它发展到这个程度的时候,你的控制器和业务逻辑就必须要重写了。
因此,我们现在准备改进portlet的开发模式。在新的模式中,portlet所用的数据访问对象(dao)和业务逻辑服务对象(service)均来自一个独立的web application中。当然portlet不再直接访问dao,也不会直接访问service。portlet是一个非常简单的控制器,当它实现逻辑的时候,它会调用一个agent,这个agent帮它访问处于另一个web application中的服务。这样一来逻辑的实现就更加集中了,你不再有机会因为一个同样的需求变更而修改两处代码。另外,从一个简单的portlet项目发展到一个强大的web application也成了自然而然的事情。在独立的应用中,service 需要经过一些简单地包装,以便portlet可以通过agent远程地访问。agent和remoteservice的实现都非常简单,基本结构是固定的,具体的逻辑可以通过delegate的方式非常方便地生成实现代码。agent和remoteservice通过hessian协议交互。