Liferay是否值得选择？优点、缺点和问题是什么？

Question

我们正在评估几种解决方案来构建一个新的网站。其中有几个方面，包括用户管理、内容管理、活动、社区和财务交易。

我们打算使用 Joomla + Vaadin + CAS（等）进行自主搭建框架，但我想知道是否应该采用 Liferay 门户，一站式解决所有问题。

我已经寻找了一些推荐，但没有找到太多信息。感谢任何已使用过 Liferay（或选择不使用）并分享它解决了哪些技术难题（或未能解决）以及可能会创造出哪些问题的人提供帮助。

谢谢！

- Alexx

---

Joomla + Vaadin？Joomla 是 PHP，Vaadin 是 Java - 你想要在一个应用程序中同时使用 PHP 和 Java 吗？那就太不合理了。 - mvmn

我工作的公司建立了几个不同的 liferay 项目，彼此独立。目前，另一个小组正在将一个基于 liferay 的网页从外部托管迁移到内部托管。他们告诉我他们面临许多问题：使用的 portlets/库的不同版本、尝试更改数据库（据我所知从 mysql 到 oracle）、在 liferay 的 6.0、6.1 和 6.2 版本之间的破坏性变化以及 EE 版本与 CE 版本之间不同的错误修复状态。所有这些... - surfmuggle

让我想知道 liferay 是否适合作为企业网站的基础，除非您的页面真的很大（比如说> 300个不同的页面），并且每个应用程序都被整合到一个单独的 liferay 实例中。 我想听听您的意见以及在更改版本和版本（从 CE 到 EE）时遇到的任何问题。 - surfmuggle

更多信息可以在这里找到Java企业门户策略的替代方案。 - surfmuggle

Answer 1

免责声明：我现在在 Liferay 工作；然而，在我加入这里之前，我就已经回答了这个问题。此外，Liferay 在这些年中有一些转变。尽管如此，我认为答案的核心仍然适用。 我的公司我曾经工作过的公司是 Liferay 的合作伙伴，所以我有很多经验。但是，也许你要谨慎考虑我的观点 :)

我们使用过各种 Java 门户工具，事实上：作为企业门户，据我所知，Liferay 是市场上最好的。它功能丰富，Bug 很少，代码编写得很好，社区非常乐于助人，而且灵活、可定制，适用于广泛的需求。

尽管如此，Liferay 是一个门户工具，因此它在以内容为中心的平台方面表现出色。如果您管理大量内容（如新闻、文章、博客、Wiki 和论坛），那么我会毫不犹豫地推荐 Liferay 作为您的平台。否则，我建议更好地考虑其他选择，例如 ERP。

无论如何，我看到 Liferay 在各个地方被用作通用开发平台，结果还可以。当使用 Liferay 时，您将获得显着的生产力提升。您不需要考虑用户、权限、内容管理等问题...Liferay 甚至处理复杂的低级问题，例如集群和分片。而 Liferay Service Builder 是我见过的最好的 Java 脚手架工具之一。当我想到它时，我觉得 Liferay，凭借其各种开箱即用的应用程序和 Service Builder，就像是 Java 的 Ruby on Rails/Django。

另一方面，Liferay非常庞大，这可能会成为一个问题。您可能会在平台上得到许多未使用的内容杂乱无章。您将不得不学习一个广泛的应用程序，并且需要花费大量时间和精力。 (我会说自从我最初发布此答案以来，Liferay的文档已经有了很大改善。) 由于Liferay解决了各种问题，因此其代码库很大。在许多应用程序中，这种复杂性是可以避免的，如果没有大部分。

此外，如果您的应用程序没有使用大量内容，则Liferay可以提供各种有用的工具，但它不会是使用Liferay的自然环境。你也将被锁定在Liferay平台上，这可能限制了你的选择。您可能想要分析Liferay工具，但我不知道它是否是一个好平台。

总之，我会这样说：

• 如果您想使用基于Java的门户网站或构建广泛的复杂门户网站，我会毫无保留地推荐Liferay;
• 如果您想创建管理大量内容的应用程序，Liferay是一个极好的平台，并且我认为它可能是最佳选择;
• 如果您的应用程序很大，但不集中于内容，我不建议使用Liferay，但它可能会很有用;
• 如果您的应用程序没有管理大量内容并且可能很小，则Liferay可能会增加比它值得的更多的复杂性。

- brandizzi

---

我完全同意你所说的每一点。对于我们的应用程序而言，它更注重行动和数据，而不是内容，并且它也比较小。平台锁定也是一个问题，但如果我们有更多门户方面的需求，我们肯定会选择Liferay。 - cdeszaq

它的代码编写得很好。请看com.liferay.portlet.journal.service.JournalArticleLocalServiceUtil.addArticle(...)。它需要38个参数！！！ - FeinesFabi

@FeinesFabi，这确实是很多参数！但是有理由：此函数还通过SOAP和REST Web服务调用，这些服务仅接收原始类型。在JavaScript中，这些参数通过对象传递，这样更清晰明了。更重要的是，该方法应该是瞬态的：它会持久化许多行，如果对象持久化失败，则应回滚所有内容。许多参数是解决这些和其他要求的方案。虽然有关如何改进它的争论，但这不是轻率的、临时的设计。 - brandizzi

我明白了，感谢您的解释。但是我已经远远超过对Liferay方式的质疑了。有很多时候，你需要在服务z的方法y中使用参数x，但你找不到任何相关文档，即使在网上搜寻了几个小时也是如此。无论如何，我的客户（德国一家相当大的汽车制造商）开始意识到，在Liferay中实现需求的成本太高了，并正在转向其他系统。 - FeinesFabi

@threeFourOneSixOneThree 我承认我不知道其他门户网站的情况。我已经退出了这个项目，现在正在使用Grails和AngularJs进行工作。这是一个很好的转变 - 事情终于又有趣了。 - FeinesFabi

我已经使用 LR 6.2 超过六个月了，但我一点也不推荐它。它的文档十分缺乏，并且源代码中没有任何注释。它还存在漏洞，常见的用户界面设计非常糟糕，即使是在虚拟机或 FTL 模板上完成简单的任务，也往往需要半页代码才能完成，因为 LR 没有提供访问常见事物的合理方法。Theme AUI CSS 非常具有侵入性（而未经样式处理的管理界面没有任何样式）。使用 Maven 进行主题部署也相当缓慢，由于 LR 的漏洞经常随机失败。 - kasakka

Answer 2

我们决定不选择Liferay主要是因为我们不需要门户服务器，只需用它来处理安全事项。由于我们使用活动目录服务器来维护用户信息和权限，所以我们决定构建一个Spring MVC应用程序，并使用Spring Security与活动目录集成。

最终决定不使用Liferay，因为我们不想在不需要的情况下使用所有额外的portlet容器开销，同时也希望完全控制/灵活性以确切地将所有内容串联在一起。

- cdeszaq

---

我不明白为什么这被选为最佳答案。实际上问题是是否值得使用 Liferay 作为门户网站，但你发表了负面意见，尽管你并没有使用它的门户功能。请问您需要翻译哪些内容？ - denu

@denu - Liferay是一个portlet容器，在我们的情况下，由于我们没有开发portlet，它只是被用于其他工具更好的“附加组件”。OP要求提供关于它做得好和不好的证明和一般信息。由于OP根本没有提到拥有门户网站，我不确定你从哪里得到这个信息。虽然我同意我的答案可能不是最好的。 - cdeszaq