Chọn một Khung Web Java bây giờ? [đóng cửa]

chúng tôi đang trong giai đoạn lập kế hoạch di chuyển một trang web lớn được xây dựng trên khung mvc được phát triển tùy chỉnh sang khung web dựa trên java, cung cấp hỗ trợ tích hợp cho ajax, nội dung đa phương tiện, mashup, bố cục dựa trên mẫu, xác thực, tối đa html / tách mã java. Grails trông giống như một lựa chọn tốt, tuy nhiên, chúng tôi không muốn sử dụng ngôn ngữ kịch bản. Chúng tôi muốn tiếp tục sử dụng java. Bố cục dựa trên mẫu là mối quan tâm chính vì chúng tôi dự định sử dụng ứng dụng web này với nhiều trang web có chức năng tương tự nhưng giao diện hoàn toàn khác nhau.

Là giải pháp dựa trên cổng thông tin phù hợp với vấn đề này?

Bất kỳ hiểu biết nào về việc sử dụng "Spring Roo" hoặc "Play" sẽ rất hữu ích.

Tôi đã tìm thấy những bài viết tương tự như thế này , nhưng nó đã hơn một năm tuổi. Mọi thứ chắc chắn đã thay đổi trong thời gian trung bình!

EDIT 1: Cảm ơn câu trả lời tuyệt vời! Trang web này đang trở thành nguồn duy nhất tốt nhất cho thông tin lập trình viên. Tuy nhiên, tôi đã mong đợi thêm thông tin về việc sử dụng bộ đôi cổng thông tin-cms. Jahia trông hàng hóa. Bất cứ điều gì tương tự?

Là giải pháp dựa trên cổng thông tin phù hợp với vấn đề này?

Cá nhân, tôi sẽ tránh xa các giải pháp Portal béo lớn (chúng thường là những kẻ giết người năng suất). Tôi đã nghe những điều tốt về Gatein nhưng tôi không có kinh nghiệm thực sự với nó.

Bất kỳ hiểu biết nào về việc sử dụng "Spring Roo" hoặc "Play" sẽ rất hữu ích.

Về Spring Roo, tôi đã đọc những câu trả lời trước như Spring roo Vs (Wicket và Spring) và những thứ khác qua Internet nhưng tôi vẫn không bị thuyết phục (có thể tôi không hiểu), tôi không chắc về sự trưởng thành của nó và, quan trọng hơn, tôi thực sự tự hỏi SpringSource đang làm gì với Grails và Roo (không, Grails vs Roo - tại sao SpringSource lại thúc đẩy hai công nghệ rất giống nhau? không thuyết phục tôi rằng cả hai sẽ tồn tại).

Tôi không thể nói nhiều về Play. Tôi đã xem bản demo như mọi người nhưng tôi muốn đọc phản hồi thực tế. Cho đến lúc đó, tôi sẽ đợi.

Tôi đã tìm thấy bài viết tương tự (...). Mọi thứ chắc chắn đã thay đổi trong thời gian trung bình!

Có và không :) Nhưng chúng ta hãy nhập vào khung trình bày địa ngục: không có câu trả lời duy nhất cho câu hỏi của bạn (như một năm trước), có hàng tá khung xung quanh đó và không có người chiến thắng rõ ràng. Chỉ cần trích dẫn một vài:

• JSF: Rất nhiều người hoài nghi về khung dựa trên thành phần này, bao gồm cả tôi vì vậy tôi không phải là người tốt nhất để nói về nó nhưng ...
• JSF 2 (+ CDI / Weld): Những người hoài nghi về JSF được khuyến khích ( bởi Gavin King ) để "xem xét lại lần thứ hai". Thật vậy, tôi nghĩ rằng JSF 2 là một cải tiến lớn, đặc biệt là với CDI, nhưng ... nó vẫn còn khá mới (hiểu, nó thiếu sự trở lại). Nếu bạn muốn nắm lấy Java EE 6, hãy xem thử.
• Wicket: Một khung dựa trên thành phần khác đang được chú ý nhiều hơn. Tôi nghe hầu hết những điều tốt về nó: đơn giản hơn so với JSF, thiết kế đẹp, khả năng kiểm tra cao, thân thiện với nhà thiết kế HTML, v.v. Bạn có thể thích nó.
• Tapestry: Chỉ không (xem Tại sao bạn ngừng sử dụng Tapestry? )
• Struts 2, Spring MVC, Sọc: Khung dựa trên hành động. Tất cả đều ổn và sẽ đáp ứng nhu cầu của bạn (cá nhân, tôi thích Sọc và quy ước của nó về cách tiếp cận cấu hình, xem Sọc so với Struts2 để có ý tưởng về nó).
• GWT, Flex, Grails: Đây có thể không phải là thứ bạn đang tìm kiếm. Tôi thực sự không thể nói về (các phiên bản gần đây) của Flex và GWT nhưng tôi biết rằng Grails có một số người hâm mộ .

Trên thực tế, tôi khuyên bạn nên xem qua các bài thuyết trình của Matt Raible , anh ấy thực sự đã làm rất tốt khi so sánh các khung web, cho thấy điểm mạnh và điểm yếu của họ, thu thập dữ kiện và số, hiển thị xu hướng ... Tôi khuyên bạn nên:

• So sánh JSF, Spring MVC, Sọc, Struts 2, Tapestry và Wicket (vẫn không bị lỗi thời)
• Các khung web của tương lai: Flex, GWT, Rails và Grails (chỉ để có được một hương vị thay thế)
• So sánh các khung web Kick-Ass (cái này là gần đây nhất)

Thực sự, hãy xem các bài thuyết trình này, chúng sẽ giúp bạn tìm ra một khung phù hợp (không có câu trả lời duy nhất nhưng bạn có thể hạn chế lựa chọn bằng cách loại bỏ) và có thể thay đổi quan điểm của bạn.

Tôi đã sử dụng Spring 3 và Jquery một thời gian nhưng đã nghe về Play và cho nó một shot. Tôi thực sự thích nó, Play là một sự phù hợp tuyệt vời giữa một cái gì đó như PHP và các khung công tác Java nặng nề như Spring.

Những điều tôi thích nhất khi chơi là:

• Rất dễ dàng để có được một ứng dụng chơi trên mặt đất, bạn phải đi khá xa với mã hóa và cấu hình để có được một ứng dụng thô sơ đơn giản trên màn hình với Spring (mặc dù Spring 3 đã làm cho nó dễ dàng hơn rất nhiều).
• Spring Security là tuyệt vời nhưng nó đi kèm với chi phí phức tạp. Mô-đun bảo mật của Play rất đơn giản và đáp ứng nhu cầu của 90% ứng dụng ngoài kia.
• Bạn có thể thực hiện thay đổi mã và nhấn refresh trong trình duyệt để xem thay đổi như với PHP thay vì phải thực hiện toàn bộ việc triển khai lại với các khung công tác dựa trên Servlet.
• Thông báo lỗi được hiển thị độc đáo và không quá khó hiểu trong hầu hết thời gian. Chơi vẫn cần phải xử lý lỗi của họ
• Có một cơ chế plugin cho Play khá đơn giản.
• Sự kiên trì của đối tượng được thực hiện rất độc đáo ở chỗ một cơ sở dữ liệu trong bộ nhớ và JPA đi kèm với khung công tác nên không có cấu hình của các công cụ kiên trì đối tượng bên ngoài. Chuyển từ cơ sở dữ liệu trong bộ nhớ sang RDBMS thực tế là một thay đổi một dòng trong tệp cấu hình.
• Việc thiết lập MVC được thực hiện rất tốt. Lớp Model mà bạn mở rộng để tạo các đối tượng miền của bạn tích hợp với trình quản lý thực thể JPA. Họ không chỉ là POJO.
• Ánh xạ URL tới bộ điều khiển rất đơn giản và linh hoạt và tất cả trong một tệp "tuyến đường".
• Bất cứ khi nào bạn tạo dự án, Play sẽ xử lý tất cả các phụ thuộc jar và Play có tiện ích cho nhật thực (hoặc bất kỳ IDE nào bạn thích) để dự án nhập trực tiếp vào IDE yêu thích của bạn.

Những điều tôi không thích về Play

• Các tài liệu không phải là tất cả các cách đó, rất nhiều tính năng không có giấy tờ vẫn còn tồn tại.
• Khung là máy chủ để bạn phải dành một cổng cho mỗi ứng dụng. Tôi nghĩ ai đó đang làm việc trên một plugin máy chủ ảo nhưng tôi chưa thấy nó hoạt động.
• Nó còn trẻ, dự án rất tuyệt vời và công nghệ thì tuyệt vời nhưng nó thực sự cần thêm một số nhà phát triển. Tôi rất muốn dành một chút thời gian cho nó, chúng ta sẽ thấy.

Lựa chọn hàng đầu đối với tôi là Wicket . Xóa tách mã đánh dấu và mã java. Rất dễ dàng để viết và sử dụng các thành phần. Sử dụng Ajax đơn giản, khả năng kiểm tra. Bạn có thể gỡ lỗi ngay vào các trang / thành phần của mình và không nhận được thông báo lỗi khó hiểu từ việc triển khai JSF của bạn;)

Ngoài ra còn có một so sánh tốt <-> JSF về hiệu suất

Ba lựa chọn hàng đầu đối với tôi là (theo bảng chữ cái):

• JSF
• Mùa xuân MVC
• Struts 2

Họ:

• có hỗ trợ ajax tốt
• cho phép bạn tạo các trang web thực tế, không phải các ứng dụng (như GWT)
• ổn định, tài liệu tốt, sử dụng rộng rãi
• MVC
• Java thuần
• tích hợp dễ dàng với Spring là phần mềm trung gian

Chơi gần giống với ROR, phiên bản ROR trong java

Ngược lại với các câu trả lời khác, tôi muốn nêu rõ những nhược điểm (IMHO) của các khung web phổ biến:

JSF2 - Đã phát hành và đã có tuổi. Vẫn chỉ có một vài tin tức / bài viết / bài đăng blog / kinh nghiệm ra. Tôi hoài nghi. Vẫn đang chờ phiên bản chính tiếp theo của Richfaces / Icefaces hỗ trợ đầy đủ jsf 2 - hiện tại chỉ có thể tải xuống các bản dựng alpha.

Struts 2 - Có vẻ chỉ là một điều tốt nếu bạn vẫn dựa vào thanh chống và muốn cấu trúc lại hầu hết mã của bạn. Mặt khác: Đừng.

GWT - Tôi không thích cách tiếp cận một trang và java-> javascript. Tôi không chắc chắn nếu một phiên - nhiều lượt xem / cửa sổ có thể dễ dàng đạt được. Đối với tôi, khung này nên được sử dụng cho các ứng dụng internet phong phú một cửa sổ dành cho người dùng lớn.

Wicket - Cách tiếp cận đẹp, nhưng hơi dài dòng và quá ít tài liệu có sẵn (ngoại trừ wicket tốt trong sách hành động, nhưng điều này chỉ bao gồm 1.3). Ngoài ra, đối với tôi nó thiếu các dự án lớn được xây dựng trên nó. Và hiện tại tôi không thể nhìn thấy con đường của wicket đang đi đâu hoặc nếu nó đã bị đẩy vào ngõ cụt.

Spring MVC - Chưa thử cái này, nhưng bạn phải bao gồm nhiều lọ (spring mess) trong classpath của bạn để làm việc với khung này đúng cách. Và nó dựa vào JSP (trong hầu hết các dự án), mà tôi cho là đã chết. Và bạn chỉ nhận được một khung MVC thuần túy - tất cả những thứ khác (ajax và những thứ khác) phải được triển khai / tích hợp.

Sọc - Một khung MVC được thiết kế nhỏ và đẹp, nhưng quá ít tài liệu, quá ít cam kết / ủy quyền, quá ít bản phát hành, quá ít hỗ trợ ngành, quá ít hoạt động danh sách gửi thư.

Tôi cũng tò mò nếu tôi bỏ lỡ một khung chính ngoài đó (tôi cố tình bỏ Tapestry) có thể là một lựa chọn cho bạn (và cả cho tôi nữa).

Tôi đã có thành công lớn với JAX-RS . Đây là Khung công tác Web Java duy nhất có một số loại đặc tả JSR và nhiều triển khai khác với thông số kỹ thuật của servlet và portlet (mặc dù điều này có thể là một điều xấu).

Một điều tệ và tốt về Java là bạn có thể chọn và khớp các khung công tác (python cũng có tính năng / vấn đề này). Thật tuyệt vì bạn không phải bỏ tất cả trứng vào một giỏ.

Dưới đây là một công thức ngăn xếp ứng dụng web Java chung:

Javascript / Flash + Xử lý yêu cầu / phản hồi + Tiêm phụ thuộc + Kiên trì

Javascript: JQuery, Nguyên mẫu, Dojo

Yêu cầu / Trả lời: Spring MVC, Sọc và JAX-RS yêu thích của tôi (Jersey, Apache CXF)

Phụ thuộc tiêm: Mùa xuân, Guice

Tính bền bỉ: JPA (Hibernate, lưu trữ ứng dụng Google), Hibernate, JDO và hơn thế nữa.

Tôi cũng đã thành công lớn trong việc sử dụng AspectJ để làm cho Java "hút ít hơn". Bằng cách sử dụng các hỗn hợp ITD của @Configurable và AspectJ, bạn có thể nhận được Rails giống như các đối tượng Miền (đây không phải là những gì mà Roo làm nhưng bạn không cần phải làm điều này).

Tôi đã tìm thấy các sọc thực sự hiệu quả và nhẹ đáng ngạc nhiên .... nó nhằm mục đích nhẹ hơn các thanh chống . Tôi đã nghe từ những người bạn là nhà phát triển web toàn thời gian mà JSF không đáng bận tâm, mặc dù tôi không có kinh nghiệm trực tiếp và không thể sao lưu điều đó bằng các ví dụ (!).

Hãy xem RESThub , tuân theo các nguyên tắc tương tự như Chơi! nhưng được triển khai bằng cách sử dụng lại một số khung / công cụ cấp doanh nghiệp như Maven 3 / Spring 3 / Jersey / jQuery.

RESThub rất đột phá so với các khung công tác khác vì nó là một bộ công cụ ngăn xếp đầy đủ, nhưng không có bất kỳ framworks dựa trên máy chủ MVC hoặc servlet nào. Thay vào đó, nó sử dụng GUI dựa trên giao diện người dùng jQuery sử dụng các dịch vụ web JAX-RS (REST) ​​và hệ thống tạo khuôn mẫu Javascript dựa trên các nhúng nhúng.

Máy chủ không trạng thái và chúng tôi sử dụng HTML5 sessionStorage để giữ phiên ở phía máy khách. Cách tiếp cận này là thiết kế cho RIA và khả năng mở rộng.

Một số ứng dụng demo được cung cấp (ngay cả khi đang được xây dựng).

JSF là một framewrok tốt đẹp, nhưng JSF 1.2 thiếu tầm nhìn trong nhiều năm để phát hành. JSF 2.0 có vẻ đầy hứa hẹn và có nhiều thứ mới được thêm vào như JSF 1.2 như hỗ trợ ajax, facelets, Hỗ trợ chú thích và các quy ước mặc định (ít XML), xây dựng thành phần dễ dàng hơn 1.2.

Nó cũng tích hợp tốt với Spring, nếu bạn quan tâm đến hỗ trợ DI.

Tôi sẽ thứ hai khuyến nghị mùa xuân. Tôi không phải là một fan hâm mộ lớn của GWT, tôi không nghĩ rằng trình biên dịch mã Java -> Javascript vẫn còn đó. Tôi đang làm việc trên một ứng dụng AJAX sử dụng mùa xuân trên máy chủ và jQuery trên máy khách. Mặc dù về mặt kỹ thuật không hỗ trợ "ngoài luồng" cho jQuery, việc triển khai AjaxView MVC mùa xuân rất đơn giản và mất khoảng 25 dòng mã.

Có lẽ hơi muộn để trình diễn, nhưng tôi phải nhắc đến Vaadin . Lập trình được thực hiện riêng trong Java, với cách tiếp cận dựa trên thành phần. Giao tiếp giữa máy khách và máy chủ liên quan nhiều đến tương tác người dùng hơn là truyền dữ liệu, tất cả logic nghiệp vụ nằm trên máy chủ.

Mở rộng GWT + Mùa xuân

Tôi nghĩ những gì bạn đang tìm kiếm là một cái gì đó gần gũi với Jahia. Nó hỗ trợ GWT, Mashup, Media Content, v.v.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Temsheet http://www.jahia.net/doads/jahia/jahia6.0.0/readme/index.html

PHẦN MỀM BACKBASE PORTAL

Vài năm trước đã sử dụng phần mềm cổng thông tin " Backbase ", điều này không được hoàn thiện cho lắm. Nhưng là tốt và dễ dàng để phát triển.

Hãy nhìn vào ItsNat

ItsNat về cơ bản là một trình duyệt Java W3C trên máy chủ, đơn giản đến mức đáng kinh ngạc (DHTML trong máy chủ), thúc đẩy các ứng dụng Giao diện trang đơn chuyên sâu AJAX

Thứ gì đó xứng đáng hơn một viên đạn là các khung RIA dựa trên người chơi. Ví dụ. Adobe Flex + Java (Tất nhiên điều này có thể xoay quanh phần nào "trang web" của bạn có thực sự là "trang web" hay giống như một "ứng dụng" hay không, bạn sẽ không làm một trang blog trong Flex.)

ajax,

Theo nghĩa AJAX-as-a-buzzword, Flex thường sử dụng AMF (một giao thức nhị phân hiệu quả hơn các giao thức được sử dụng bởi các ứng dụng AJAX), mặc dù bạn cũng có thể thực hiện nghiêm túc các công cụ AJAX với Flex. Vì vậy, Flex hỗ trợ AJAX, nhưng cũng hỗ trợ "tốt hơn AJAX".

nội dung đa phương tiện, mashup,

Là Flex chạy trên nền tảng 'máy ảo' Flash, tôi nghĩ rằng cần phải thêm một chút.

mẫu dựa trên bố cục,

Không chắc chắn những gì đang nhận được chính xác, nhưng nó có vẻ như Flex mxml.

Thẩm định,

Tất nhiên được hỗ trợ, mặc dù bạn có thể quyết định thực hiện một số công cụ tùy chỉnh nếu bạn muốn nhận được ưa thích. (Không phải là bạn phải làm.) Điều tốt đẹp là bạn có thể trở nên tinh vi như bạn muốn - hoặc không.

tách mã html / java tối đa

Bạn không thể tách biệt hơn bằng cách sử dụng phương pháp phát triển 'máy ảo' như Flex / Silverlight / JavaFX. Điều này không chỉ cho phép bạn tách mã trình bày khỏi lớp truy cập dữ liệu và logic phía máy chủ của bạn - nó đảm bảo rằng chúng được tách riêng. 'Ảo hóa' môi trường phát triển của bạn giúp bạn có khả năng tương thích trình duyệt chéo, nền tảng mục tiêu nhất quán, không phải lo lắng về các trình duyệt mới hoặc các bản phát hành trình duyệt mới phá vỡ ứng dụng của bạn, các khả năng gỡ lỗi giống như java và một sản phẩm cuối chuyên nghiệp / ấn tượng hơn .