2011-09-26 31 views
39

Chúng tôi đang đánh giá một số giải pháp cho một điều web mới mà chúng tôi đang tìm cách xây dựng. Có một số khía cạnh, bao gồm quản lý người dùng, quản lý nội dung, chiến dịch, cộng đồng và giao dịch tài chính.To Go or Not To Go with Liferay? Cái gì tốt, xấu, và xấu xí?

Chúng tôi đang tìm cách tự cuộn khuôn khổ, sử dụng Joomla + Vaadin + CAS (để đặt tên một vài) cho DIY, nhưng tôi tự hỏi liệu chúng ta có nên đơn giản áp dụng cổng thông tin Liferay để mua sắm một lần không?

Tôi đã tìm kiếm lời chứng thực và chưa đưa ra nhiều. Tôi đánh giá cao bất cứ ai đã sử dụng Liferay (hoặc được chọn không) sẽ chia sẻ những rào cản kỹ thuật nào giải quyết (hoặc không) và tiềm năng những gì người khác có thể tạo ra.

Cảm ơn bạn!

+1

Joomla + Vaadin? Joomla là PHP, Vaading là Java - bạn muốn có cả PHP và Java cho một ứng dụng? Đó chỉ là không hợp lý. – mvmn

+0

Công ty tôi làm việc tại đã thiết lập một số dự án khác nhau của Liferay độc lập với nhau. Hiện tại, một nhóm khác đang làm việc để di chuyển một trang web dựa trên liferay từ bên ngoài vào lưu trữ trong nhà. Họ nói với tôi rằng họ đang đối mặt với nhiều vấn đề; các phiên bản khác nhau ra khỏi các portlet/thư viện đã sử dụng, nỗ lực thay đổi cơ sở dữ liệu (afaik từ mysql thành oracle), phá vỡ các thay đổi giữa phiên bản 6.0, 6.1 và 6.2 trong trạng thái sửa lỗi khác nhau trên phiên bản EE so với phiên bản CE. Tất cả điều này ... – surfmuggle

+0

... cho phép tôi tự hỏi liệu liferray có phù hợp làm cơ sở cho các trang web tổng hợp hay không, trừ khi trang của bạn thực sự lớn (chúng ta hãy nói> 300 trang khác nhau) và mọi ứng dụng được kết hợp thành một phiên bản duy nhất. Tôi muốn nghe ý kiến ​​của bạn và bất kỳ rắc rối nào bạn phải đối mặt khi thay đổi các phiên bản và ấn bản (từ CE sang EE). – surfmuggle

Trả lời

17

Chúng tôi quyết định không đi với Liferay chủ yếu bởi vì chúng tôi không cần một máy chủ cổng thông tin và sẽ chỉ được sử dụng nó cho những thứ an ninh. Vì chúng ta đang chạy trên một máy chủ Active Directory để duy trì thông tin người dùng và các điều khoản, chúng tôi quyết định chỉ xây dựng một ứng dụng Spring MVC và sử dụng Spring Security để gắn vào Active Directory.

Cuối cùng, quyết định được thực hiện thành không sử dụng Liferay vì chúng tôi không muốn tất cả các chi phí bổ sung của thùng chứa portlet khi chúng tôi không cần tất cả những thứ bổ sung và cũng muốn duy trì toàn quyền kiểm soát/tính linh hoạt trên chính xác cách mọi thứ được xâu chuỗi lại với nhau.

+11

Tôi không hiểu tại sao nó đã được chọn là câu trả lời hay nhất. Câu hỏi thực sự là nó có giá trị sử dụng Liferay như một cổng thông tin hay không nhưng bạn đã đưa ra ý kiến ​​tiêu cực về nó mặc dù bạn không cần phải sử dụng chức năng cổng thông tin của nó. – denu

+0

@denu - Liferay _is_ một thùng chứa _portlet_ và trong trường hợp của chúng tôi, vì chúng tôi không phát triển các portlet, nó chỉ được sử dụng cho các "tiện ích bổ sung" mà các công cụ khác đã làm tốt hơn. OP yêu cầu lời chứng thực và thông tin chung về những gì nó đã làm tốt và những gì nó đã không làm tốt. Vì OP không nói bất cứ điều gì về việc có một cổng _at all_, tôi không chắc bạn đang lấy nó từ đâu. Mặc dù tôi đồng ý rằng câu trả lời của tôi có lẽ không phải là tốt nhất. – cdeszaq

55

Tuyên bố từ chối: Tôi làm việc cho Liferay ngay bây giờ; tuy nhiên, câu trả lời đã được đăng lâu trước khi tôi bắt đầu làm việc ở đây.

Công ty của tôi Công ty tôi làm việc cho là đối tác của Liferay Inc. vì vậy tôi có nhiều kinh nghiệm về nó. Ngoài ra, có thể bạn muốn lấy ý kiến ​​của tôi với một hạt muối :)

Chúng tôi đã sử dụng các công cụ cổng thông tin Java khác nhau và sự thật là: là cổng thông tin doanh nghiệp, Liferay là sản phẩm tốt nhất trên thị trường AFAIK. Nó có chức năng phong phú, có ít lỗi, mã của nó được viết tốt, cộng đồng rất hữu ích và nó linh hoạt và có thể tùy chỉnh, rất hữu ích cho một loạt các nhu yếu phẩm.

Tuy nhiên, Liferay là một công cụ cổng thông tin, do đó, nó vượt trội như một nền tảng tập trung vào nội dung. Nếu bạn sẽ quản lý nhiều nội dung (như tin tức, bài viết, blog, wiki, diễn đàn ...), thì tôi vui lòng giới thiệu Liferay làm nền tảng của bạn. Trong các trường hợp khác, tôi sẽ đề nghị xem xét tốt hơn. Bạn có thể sử dụng một cái gì đó giống như một ERP, ví dụ.

Dù sao, tôi đã thấy Liferay được sử dụng như một nền tảng phát triển chung ở những nơi khác nhau và kết quả là hợp lý. Trong thực tế, người ta nhận được một cải tiến lớn về năng suất khi sử dụng Liferay. Bạn không cần phải suy nghĩ về người dùng, quyền hạn, quản lý nội dung ... Ngay cả các vấn đề cấp thấp phức tạp như phân cụm và sharding có thể được giao cho Liferay. Và Liferay Service Builder là một trong những công cụ giàn giáo tốt nhất cho Java mà tôi từng thấy. Khi tôi nghĩ về nó, tôi cảm thấy rằng Liferay, với các ứng dụng vượt trội của nó và Service Builder của nó, giống như một Ruby on Rails/Django cho Java.

OTOH, Liferay lớn và có thể là vấn đề. Bạn có thể nhận được rất nhiều công cụ không sử dụng làm lộn xộn nền tảng của bạn. Bạn sẽ phải nghiên cứu một ứng dụng rất lớn và nó sẽ đòi hỏi nhiều thời gian và công sức từ bạn. Thật không may, tài liệu Liferay là người nghèo, để làm cho mọi thứ tồi tệ hơn. Vì Liferay giải quyết được nhiều vấn đề, nên codebase của nó lớn. Sự phức tạp này có thể được phân phối trong nhiều, nếu không phải là hầu hết các ứng dụng.

Ngoài ra, nếu ứng dụng của bạn không sử dụng nhiều nội dung, Liferay có thể cung cấp nhiều công cụ hữu ích khác nhau, nhưng nó sẽ không phải là môi trường tự nhiên để sử dụng Liferay. Bạn cũng sẽ bị khóa trong nền tảng Liferay, điều này có thể hạn chế lựa chọn của bạn. Bạn có thể muốn phân tích các công cụ Liferay nhưng tôi không biết nó có phải là một nền tảng tốt hay không.

Tóm lại, tôi sẽ nói:

  • Nếu bạn muốn sử dụng một cổng thông tin dựa trên Java, hoặc để xây dựng một rộng, cổng thông tin phức tạp, tôi khuyên bạn nên Liferay không hạn chế;
  • Nếu bạn muốn tạo một ứng dụng quản lý nhiều nội dung, Liferay là một nền tảng tốt để làm điều đó và tôi nghĩ rằng đó có thể là lựa chọn tốt nhất;
  • Nếu ứng dụng của bạn lớn nhưng không tập trung vào nội dung, tôi sẽ không khuyến nghị Liferay nhưng nó có thể hữu ích;
  • Nếu ứng dụng của bạn không quản lý nhiều nội dung và có khả năng nhỏ, Liferay có thể sẽ thêm độ phức tạp hơn giá trị.
+3

Tôi đồng ý 100% với mọi thứ bạn đã nói. Đối với ứng dụng của chúng tôi, nó tập trung vào nhiều hành động hơn và định hướng dữ liệu hơn là định hướng nội dung và nó cũng khá nhỏ. Khóa nền tảng cũng là một mối quan tâm, nhưng nếu chúng tôi có nhiều nhu cầu hướng cổng thông tin hơn, chúng tôi chắc chắn đã chọn Liferay. – cdeszaq

+3

> ... mã của nó được viết tốt ... Hãy xem com.liferay.portlet.journal.service.JournalArticleLocalServiceUtil.addArticle (...). Phải mất 38 thông số !!! – FeinesFabi

+2

@FeinesFabi đó là rất nhiều tham số, chắc chắn! Nhưng có nhiều lý do cho điều đó: chức năng này cũng được gọi thông qua SOAP * và * REST webservices chỉ nhận các kiểu nguyên thủy. Trong JavaScript, các tham số này được truyền qua một đối tượng, nó rõ ràng hơn ở đó. Quan trọng hơn, phương pháp này nên thoáng qua: nó tồn tại nhiều hàng và nếu một đối tượng tồn tại không thành công, nó sẽ khôi phục mọi thứ. Nhiều thông số là giải pháp được tìm thấy để đáp ứng các yêu cầu này và các yêu cầu khác. Có cuộc tranh luận về làm thế nào để cải thiện nó, nhưng nó không phải là ánh sáng đầu, thiết kế đặc biệt. – brandizzi

Các vấn đề liên quan