Java Portlet的优点和缺点？

我有一个项目，我的客户要求我使用portlets 1.0规范和Websphere Portal Server 6.0。我以前没有使用过Portlet，但我听到的都是糟糕的评论。除了使用它们的明显原因外，还有什么原因？如果不是原因，我可以用什么理由来避免它们呢？

Portlet对企业很有吸引力，因为它承诺了灵活性，您可以允许客户调整和重新排列页面上的组件，如果您主要提供内容，那么它们是一种有效的方法

在我看来，门户非常适合聚合纯内容、功能独立或简单相关的portlet（例如，当您从一个portlet中的列表中选择一个项目时，您会更新另一个以显示详细信息）。 Portlet还可以实现重用，因为您可以非常简单地将它们配置到多个页面/位置

当您试图通过多个步骤和交互来分解复杂的业务功能时，问题就开始了。在这个场景中，确定portlet的粒度与其说是一门科学，不如说是一门艺术，需要仔细考虑portlet之间的交互

您还需要考虑UI的灵活性。如果您有一组portlet构建块，那么您的业务需要明确它们可以重新排列这些块，但是在portlet之间移动项需要重写。例如，将submit按钮从一个portlet移动到页面底部并非易事

---

总之，我想这取决于您正在尝试做什么，以及您对组件的重用程度。通过创建构建到servlet中的技术组件来管理重用可能更简单，或者Portlet非常适合您的业务。没有正确的答案，你只需要仔细考虑你想要达到的目标。如果您决定使用Portlet，那么您需要拥抱整个生命周期，并避免任何围绕Portlet工作的诱惑，您很快就会发现自己处于一个糟糕的境地，有着Portlet的所有开销和限制，却没有意识到其优势。

我在Portlet方面遇到的问题提醒我与EJB同样的问题-

• Portlet要求您编写只能在特殊服务器上托管和运行的特殊代码
• 每个portlet服务器供应商都有定制的扩展/配置/附加功能，因此更改服务器供应商并非易事
• Portlet似乎过于复杂，无法涵盖90%希望使用它的人不需要的功能

我建议使用类似于Hibernate的东西来访问portlet的EJB-

• Javascript框架——服务器端的内容可以用任何语言编写，托管在任何服务器上
• 简单易用
• 很多门户服务器都支持它，而且它在供应商之间更具可移植性，因为它没有那么复杂，而且它不是供应商可以实现（和扩展）的规范

---

作为一个从事过多份Java Portlet开发工作（包括我目前的工作）的人，我会说不要使用它们

问题是：

如果您只想使用所选门户的现有功能，请使用门户

如果您使用Portlet只是为了构建一个小型、轻巧、主要是基于web的只读仪表板，您可以在其中快速查看不同的信息，那么这很好

但是，如果你（或者更可能是组织结构图上更高层的人）认为Portlet是一种将一系列不同的web应用程序放在一个页面上并使其“正常工作”的方式，那么你将走向一个受伤的世界。Portlet是高度受限的、自包含的功能孤岛，而不是页面上小方块中的web应用程序

我的每一个基于portlet的工作都犯了这个错误，这条隧道的尽头没有光明。作为一名portlet开发人员，这里列出了一小部分您在常规web应用程序中经常做的事情，这些事情在portlet中是无法可靠完成的：

• 生成指向其他页面的URL。您需要一种特定于供应商的方法来实现这一点，因为Portlet API只允许您生成针对生成URL的Portlet的URL
• 读取并设置HTTP头或设置HTTP响应代码（因此没有重定向或HTTP缓存，因为您不拥有将放置portlet的页面）
• 必须为生成的页面中的所有标识符命名名称空间。这意味着HTML id属性和JavaScript函数名。由于名称空间必须在运行时确定以确保唯一性，因此不能让这些Javascript函数驻留在单独的浏览器可缓存文件中，它们必须位于portlet的响应体中

Portlet感觉就像是为web开发状态而设计的，就像90年代中后期（AJAX之前）一样。但它们不适合今天的web开发环境（AJAX、单页富web应用程序等），这些环境假定您完全控制请求/响应周期