Java Portlet 的优点和缺点？
我有一个项目，我的客户要求我使用 portlet 1.0 规范和 Websphere Portal Server 6.0。 我以前没有使用过 portlet，但我听到的关于它们的批评总是很糟糕。 除了使用它们的明显原因之外，还有哪些原因？ 如果没有理由，我可以用什么论据来避免它们？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
作为一个曾从事过开发 Java portlet 的多项工作（包括我目前的工作）的人，我建议不要使用它们。
问题是：
如果您只想使用所选门户的现有功能，那么请使用门户。
如果您使用 portlet 只是为了构建一个小型、轻型、主要只读的基于 Web 的仪表板，您可以在其中快速查看不同的信息，那么这很好。
但是，如果您（或更可能是组织结构图上的更高层的人）认为 portlet 是一种将一堆不同的 Web 应用程序放在一个页面上并使其“正常工作”的方法，那么您将走向一个充满伤害的世界。 Portlet 是高度受限、独立的功能岛，而不是页面上小方块中的 Web 应用程序。
我的每一项基于 portlet 的工作都犯过这个错误，而且隧道尽头没有光明。 作为一名 Portlet 开发人员，这里列出了您习惯于在常规 Web 应用程序中执行但在 Portlet 中无法可靠执行的一小部分操作：
Portlet 感觉好像它们是为 90 年代中后期（AJAX 之前）的 Web 开发状态而设计的。 但它们不适合当今的 Web 开发环境（AJAX、单页富 Web 应用程序等），这些环境假设您可以完全控制请求/响应周期。
As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.
Here's the problem:
If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.
If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.
But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.
Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:
Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.
我在 portlet 方面遇到的问题让我想起了与 EJB 相同的问题——portlet
我建议类似 Google Gadgets 作为 Hibernate 到 portlet 的 EJB -
The problems I have with portlets remind me of the same problems as EJBs-
I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -
Portlet 对企业很有吸引力，因为它承诺灵活性，允许客户调整和重新排列页面上的组件，如果您主要提供内容，那么它们是实现这一目标的有效方法。
在我看来，门户网站非常适合聚合纯内容、功能独立或简单相关的 portlet（例如，当您从一个 portlet 的列表中选择一项时，您会更新另一个 portlet 以显示详细信息）。
Portlet 还可以实现重用，因为您可以相当简单地将它们配置到多个页面/位置。
当您尝试通过多个步骤和交互来分解复杂的业务功能时，就会出现问题。 在这种情况下，确定 Portlet 的粒度与其说是一门科学，不如说是一门艺术，并且需要仔细考虑 Portlet 之间的交互。
您还需要考虑 UI 的灵活性。 如果您有一组 Portlet 构建块，您的企业需要清楚他们可以重新排列这些块，但在 Portlet 之间移动项目需要重写。 例如，将提交按钮从一个 portlet 移至页面底部并非易事。
总而言之，我想这取决于您想要做什么以及您期望组件的重用程度。 通过创建 IT 构建到 servlet 中的技术组件来管理重用可能会更简单，或者 portlet 可能非常适合您的业务。 没有正确的答案，你只需要仔细考虑你想要实现的目标。 如果您确实决定使用 portlet，则需要接受整个生命周期，并避免任何绕过它们的诱惑，您很快就会发现自己处于一个糟糕的境地，因为 portlet 的所有开销和限制，而无法实现其优势。
Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.
In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details).
Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.
Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.
You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.
So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.