不管怎样，我在各个地方都看到Liferay被用作通用开发平台，结果也在情理之中。使用 Liferay 可以显着提高工作效率。您无需考虑用户、权限、内容管理……Liferay 甚至可以处理复杂的低级问题，例如集群和分片。 Liferay Service Builder 是我见过的最好的 Java 脚手架工具之一。当我想到这一点时，我觉得 Liferay 及其各种开箱即用的应用程序及其 Service Builder，就像一个 Ruby on Rails/Django for Java。
Disclaimer: I work for Liferay now; however, I answered this question long before I started to work here. Also, Liferay has pivoted a bit in these years. Nonetheless, I believe the core of the answer still applies.
My companyThe company I worked for is a Liferay Inc. partner, so I have a lot of experience in it. Also, maybe you want to take my opinions with a grain of salt :)
We have used various Java portal tools, and the truth is: as a corporate portal, Liferay is the best one in the market, AFAIK. It is rich in functionality, has few bugs, its code is well written, the community is very helpful, and it is flexible and customizable, useful for a wide range of necessities.
Nonetheless, Liferay is a portal tool, so it excels as a content-centric platform. If you manage a lot of content (such as news, articles, blogs, wikis and forums), then I would happily recommend Liferay as your platform. In other cases, I would suggest a better consideration. You can use something like an ERP, for example.
Anyway, I have seen Liferay used as a general development platform in various places, and the result is reasonable. One gets a significant productivity boost when using Liferay. You do not need to think about users, permissions, content management... Liferay handles even complex, low-level issues such as clustering and sharding. And the Liferay Service Builder is one of the best scaffolding tools for Java I've seen. When I think about it, I feel that Liferay, with its various out-of-the-box applications and its Service Builder, is like a Ruby on Rails/Django for Java.
OTOH, Liferay is enormous, and it can be a problem. You may get a lot of unused stuff cluttering your platform. You will have to study a vast application, and it will demand much time and effort from you. Unfortunately, Liferay's documentation is poor, to make things worse.(I'd say Liferay's documentation improved a lot since I originally posted this answer.) Since Liferay does solve a wide range of problems, its codebase is big. This complexity can be dispensable in many, if not most, applications.
Also, if your application does not use a lot of content, Liferay can provide various helpful tools, but it will not be the natural environment for using Liferay. You will be locked in the Liferay platform, too, which can restrict your choices. You may want to analyze Liferay tools, but I do not know if it would be a good platform.
To summarize, I would say:
If you want to use a Java-based portal, or to build a broad, complex portal, I recommend Liferay without restrictions;
If you want to create an application that manages a lot of content, Liferay is an excellent platform to do it, and I think it may be the best choice;
If your application is big but not content-centric, I would not recommend Liferay, but it can be useful;
If your application does not manage a lot of content and is potentially small, Liferay probably will add more complexity than it is worth.
我们决定不选择 Liferay，主要是因为我们不需要门户服务器，只会将其用于安全目的。由于我们针对 Active Directory 服务器运行来维护用户信息和权限，因此我们决定构建一个 Spring MVC 应用程序并使用 Spring Security 来绑定到 Active Directory。
We decided not to go with Liferay primarily because we did not need a portal server and would only have been using it for security things. Since we were running against an Active Directory server for maintaining user info and permissions, we decided to just build out a Spring MVC application and use Spring Security to tie into Active Directory.
In the end, the decision was made to not use Liferay because we didn't want all of the extra overhead of a portlet container when we didn't need all of the extra stuff, and also wanted to maintain full control / flexibility over exactly how everything was strung together.
发布评论
评论（2）
免责声明：我现在在 Liferay 工作；然而，早在我开始在这里工作之前，我就回答了这个问题。此外，Liferay 这些年来也发生了一些转变。尽管如此，我相信答案的核心仍然适用。
我的公司我工作的公司是Liferay Inc.的合作伙伴，所以我在这方面有很多经验。另外，也许您想对我的观点持保留态度:)我们使用过各种 Java 门户工具，事实是：据我所知，作为企业门户，Liferay 是市场上最好的工具。它功能丰富，bug很少，代码写得很好，社区非常有帮助，而且它灵活且可定制，可满足广泛的需求。
尽管如此，Liferay 是一个门户工具，因此它非常适合作为一个以内容为中心的平台。如果您管理大量内容（例如新闻、文章、博客、维基和论坛），那么我很乐意推荐 Liferay 作为您的平台。在其他情况下，我会建议更好的考虑。例如，您可以使用 ERP 之类的东西。
不管怎样，我在各个地方都看到Liferay被用作通用开发平台，结果也在情理之中。使用 Liferay 可以显着提高工作效率。您无需考虑用户、权限、内容管理……Liferay 甚至可以处理复杂的低级问题，例如集群和分片。 Liferay Service Builder 是我见过的最好的 Java 脚手架工具之一。当我想到这一点时，我觉得 Liferay 及其各种开箱即用的应用程序及其 Service Builder，就像一个 Ruby on Rails/Django for Java。
OTOH，Liferay 非常庞大，这可能是一个问题。您的平台可能会出现大量未使用的内容。您将不得不研究大量的应用程序，这将需要您花费大量的时间和精力。
不幸的是，Liferay 的文档很差，这让事情变得更糟。（我想说，自从我最初发布这个答案以来，Liferay 的文档改进了很多。）因为 Liferay 确实解决了广泛的问题问题范围很大，代码库很大。这种复杂性在许多（如果不是大多数）应用程序中是可有可无的。另外，如果您的应用程序不使用大量内容，Liferay 可以提供各种有用的工具，但它不会是使用 Liferay 的自然环境。您也将被锁定在 Liferay 平台中，这可能会限制您的选择。你可能想分析Liferay工具，但我不知道它是否是一个好的平台。
总而言之，我想说：
Disclaimer: I work for Liferay now; however, I answered this question long before I started to work here. Also, Liferay has pivoted a bit in these years. Nonetheless, I believe the core of the answer still applies.
My companyThe company I worked for is a Liferay Inc. partner, so I have a lot of experience in it. Also, maybe you want to take my opinions with a grain of salt :)We have used various Java portal tools, and the truth is: as a corporate portal, Liferay is the best one in the market, AFAIK. It is rich in functionality, has few bugs, its code is well written, the community is very helpful, and it is flexible and customizable, useful for a wide range of necessities.
Nonetheless, Liferay is a portal tool, so it excels as a content-centric platform. If you manage a lot of content (such as news, articles, blogs, wikis and forums), then I would happily recommend Liferay as your platform. In other cases, I would suggest a better consideration. You can use something like an ERP, for example.
Anyway, I have seen Liferay used as a general development platform in various places, and the result is reasonable. One gets a significant productivity boost when using Liferay. You do not need to think about users, permissions, content management... Liferay handles even complex, low-level issues such as clustering and sharding. And the Liferay Service Builder is one of the best scaffolding tools for Java I've seen. When I think about it, I feel that Liferay, with its various out-of-the-box applications and its Service Builder, is like a Ruby on Rails/Django for Java.
OTOH, Liferay is enormous, and it can be a problem. You may get a lot of unused stuff cluttering your platform. You will have to study a vast application, and it will demand much time and effort from you.
Unfortunately, Liferay's documentation is poor, to make things worse.(I'd say Liferay's documentation improved a lot since I originally posted this answer.) Since Liferay does solve a wide range of problems, its codebase is big. This complexity can be dispensable in many, if not most, applications.Also, if your application does not use a lot of content, Liferay can provide various helpful tools, but it will not be the natural environment for using Liferay. You will be locked in the Liferay platform, too, which can restrict your choices. You may want to analyze Liferay tools, but I do not know if it would be a good platform.
To summarize, I would say:
我们决定不选择 Liferay，主要是因为我们不需要门户服务器，只会将其用于安全目的。由于我们针对 Active Directory 服务器运行来维护用户信息和权限，因此我们决定构建一个 Spring MVC 应用程序并使用 Spring Security 来绑定到 Active Directory。
最后，决定不使用 Liferay，因为当我们不需要所有额外的东西时，我们不希望 portlet 容器产生所有额外的开销，并且也想对一切如何串联在一起保持完全控制/灵活性。
We decided not to go with Liferay primarily because we did not need a portal server and would only have been using it for security things. Since we were running against an Active Directory server for maintaining user info and permissions, we decided to just build out a Spring MVC application and use Spring Security to tie into Active Directory.
In the end, the decision was made to not use Liferay because we didn't want all of the extra overhead of a portlet container when we didn't need all of the extra stuff, and also wanted to maintain full control / flexibility over exactly how everything was strung together.