Java EE 6 so với ngăn xếp Spring 3 [đã đóng]

Tôi đang bắt đầu một dự án mới bây giờ. Tôi phải chọn công nghệ. Tôi cần một cái gì đó nhẹ, vì vậy không có EJB hoặc Seam. Mặt khác, tôi cần JPA (Hibernate hoặc thay thế) và JSF với IceFaces.

Bạn có nghĩ rằng một ngăn xếp như vậy trên Spring 3 được triển khai trên Tomcat là một lựa chọn tốt? Hay một ứng dụng web Java EE 6 có thể tốt hơn? Tôi e rằng Java EE 6 là một công nghệ mới, chưa được ghi chép đầy đủ. Tomcat có vẻ dễ bảo trì hơn Glassfish 3.

Ý kiến ​​của bạn là gì? Bạn có bất kỳ kinh nghiệm?

Tôi cần một cái gì đó nhẹ, vì vậy không có EJB hoặc Seam.

Bạn có muốn giải thích điều gì khiến EJB trở nên nặng nề kể từ EJB3 không? Bạn có nhận ra rằng chúng ta không còn ở năm 2004 nữa không? Tôi thực sự muốn đọc định nghĩa của bạn về ánh sáng và các lập luận của bạn (và tôi sẽ rất vui khi cập nhật câu trả lời của mình vì tôi khá chắc rằng mình sẽ có một vài điều chắc chắn để nói).

Mặt khác, tôi cần JPA (Hibernate hoặc thay thế) và JSF với IceFaces.

Java EE 6 Web Profile bao gồm JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... sẽ là lựa chọn hoàn hảo cho việc này và bạn có thể sử dụng GlassFish v3 Web Profile để chạy một ứng dụng được xây dựng bằng Java EE 6 Web Profile .

Bạn có nghĩ rằng ngăn xếp như vậy trên Spring 3 được triển khai trên Tomcat là một lựa chọn tốt? Hay một ứng dụng web Java EE 6 có thể tốt hơn?

Chà, tôi thích ý tưởng chạy mã của mình trên một nền tảng không độc quyền (Java EE) hơn là trên một vùng chứa độc quyền (Spring). Và tôi nghĩ rằng Java EE 6 là đủ tốt (và đây là một cách nói uyển chuyển, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Lưu ý rằng tôi là một người hoài nghi JSF nhưng tôi đã xem xét kỹ lại và JSF 2.0 với CDI khác nhau đến mức tôi thậm chí không thể so sánh được. Và nếu bạn không nhìn vào CDI, hãy để tôi nói với bạn rằng nó rất tuyệt.

Tôi e rằng Java EE 6 là một công nghệ mới, chưa được ghi chép đầy đủ.

Java EE trông khá tốt được ghi lại cho tôi. Điều này nghe giống như yêu cầu miễn phí. Và, tin tôi hay không, tôi bắt đầu thấy Spring trở nên phức tạp trong khi Java EE trở nên dễ dàng hơn.

Tomcat có vẻ dễ bảo trì hơn Glassfish 3.

Bạn đã thử một cái gì đó? Bạn có gặp phải vấn đề cụ thể nào không? Một lần nữa, điều này nghe giống như yêu cầu miễn phí.

Tôi chưa sử dụng JavaEE6.

Tuy nhiên, tôi đã bị đánh bại bởi tất cả các phiên bản trước của JavaEE và EJB đến mức tôi sẽ không tin tưởng nó cho đến khi nó tự thiết lập là tiêu chuẩn thực tế, không chỉ là tiêu chuẩn de jure. Hiện tại, Spring vẫn là tiêu chuẩn trên thực tế.

Đánh lừa tôi một lần, xấu hổ về bạn. Lừa tôi hai lần, xấu hổ về tôi. Lừa tôi ba lần, EJB.

Một số sẽ cho rằng Spring là độc quyền. Tôi cho rằng việc triển khai các thông số kỹ thuật JavaEE của nhà cung cấp cũng chỉ là độc quyền, nếu không muốn nói là hơn thế.

Gần đây, tôi đã trải qua một cuộc chuyển đổi lớn là chuyển một loạt các Ứng dụng Java từ JBoss sang Weblogic. Tất cả các ứng dụng Spring / Hibernate được chuyển mà không có sửa đổi nào, vì chúng có sẵn tất cả các thư viện cần thiết. Tất cả các ứng dụng sử dụng JPA, EJB và JSF đều là một thảm họa khi chuyển. Sự khác biệt nhỏ trong cách diễn giải JPA, EJB và JSF giữa các máy chủ ứng dụng đã gây ra tất cả các loại lỗi khó chịu mà phải mất mãi mãi mới có thể sửa được. Ngay cả một cái gì đó đơn giản như đặt tên JNDI cũng hoàn toàn khác nhau giữa các AppServer.

Mùa xuân là một sự thực hiện. JavaEE là một thông số kỹ thuật. Đó là một sự khác biệt rất lớn. Tôi muốn sử dụng thông số kỹ thuật NẾU thông số kỹ thuật kín 100% và hoàn toàn không có chỗ lung tung theo cách các nhà cung cấp triển khai thông số kỹ thuật đó. Nhưng thông số JavaEE chưa bao giờ là như vậy. Có lẽ JavaEE6 kín gió hơn? Tôi không biết. Bạn càng có thể đóng gói nhiều hơn trong WAR của mình và bạn càng ít phụ thuộc vào các thư viện AppServer, thì ứng dụng của bạn sẽ càng linh hoạt hơn và đó là lý do tôi sử dụng Java chứ không phải Dot-NET.

Ngay cả khi thông số kỹ thuật không kín, sẽ rất tuyệt nếu có thể nâng cấp máy chủ ứng dụng mà không cần phải nâng cấp tất cả các ngăn xếp công nghệ của tôi trong tất cả các ứng dụng của tôi cùng với nó. Nếu tôi muốn nâng cấp từ JBoss 4.2 lên JBoss 7.0, tôi phải xem xét tác động của phiên bản JSF mới hơn đối với tất cả các ứng dụng của mình. Tôi không phải xem xét ảnh hưởng đến các ứng dụng Spring-MVC (hoặc Struts) của mình.

Nó không quan trọng. Java EE 6 đủ tốt và vì các cấu hình ở đó, nó không "nặng" - bạn sẽ chỉ sử dụng cấu hình web.

Riêng tôi, tôi thích mùa Xuân hơn. Nhưng tôi đang hết các lập luận hợp lý chống lại Java EE 6 :)

(Như tôi đã được nhắc nhở trong một nhận xét - bạn có thể muốn thử RichFaces , cũng như ICEfaces và / hoặc PrimeFaces - tùy thuộc vào những thành phần bạn cần).

Gần đây, một trong những nhiệm vụ khách hàng của tôi liên quan đến việc đánh giá ngăn xếp khuôn khổ tùy chỉnh Spring Stack Vs Vs a Java EE Standards. Sau một tháng đánh giá và tạo mẫu, tôi không chỉ vui mừng mà còn bị thổi bay bởi bộ tính năng Java EE 6. Đối với bất kỳ kiến ​​trúc dự án "doanh nghiệp" mới nào trong năm 2011 và về sau, tôi sẽ sử dụng Java EE 6 và các phần mở rộng tiềm năng như Seam 3 hoặc dự án phần mở rộng Apache JSR299 sắp tới. Kiến trúc Java EE 6 được sắp xếp hợp lý và kết hợp tốt nhất nhiều ý tưởng nguồn mở đã phát triển trong vài năm qua.

Hãy xem xét các tính năng sau: Quản lý sự kiện, Bối cảnh và DI, Bộ chặn, Trình trang trí, Thiết bị web RESTful, kiểm tra tích hợp với vùng chứa có thể nhúng, Bảo mật và nhiều tính năng khác.

Hầu hết các kết quả của tôi được xuất bản trong blog của tôi giải thích các khái niệm chính của Java EE 6 mà bạn có thể thấy hữu ích.

Tất nhiên, không có quy tắc cứng và nhanh cho việc chọn một khuôn khổ. Java EE 6 có thể được mở rộng cho các "trang web" đơn giản hơn không yêu cầu trạng thái phiên đàm thoại phong phú. Bạn cũng có thể chọn Grails hoặc Play! Khuôn khổ. Nhưng đối với các ứng dụng web đàm thoại, tôi không thể thấy lý lẽ tốt hơn tại sao Java EE 6 không phù hợp.

Bây giờ, sau một thời gian, tôi có kinh nghiệm với các ngăn xếp:

• Java EE 5 + Seam + GraniteDS + Flex
• Spring 3 + Vaadin (trên GWT)
• Spring 3 + JSF 2.0 (PrimeFaces)

Colclusions của tôi là:

• Spring 3 đơn giản hơn nhiều so với Seam (gần như Java EE 6) và chạy trên Tomcat và Jetty! (Cầu cảng cho sự phát triển với plugin maven là một điều khó hiểu).
• Tôi yêu Flex (tôi thực sự là một nhà phát triển Flex trong một thời gian dài nên tôi thiên vị) và nếu bạn cần giao diện phong phú và có thể mua FlashBuilder, hãy sử dụng cái này, nhưng hãy sử dụng phần phụ trợ Spring + GraniteDS hoặc BlazeDs này. Nếu bạn không thể mua FlashBuilder, đừng lãng phí thời gian của bạn.
• Vaadin thật tuyệt !. Quá trình phát triển đơn giản hơn Flex, nhưng bạn có thể tạo ứng dụng phong phú một cách dễ dàng mà không có sự lộn xộn của HTML. Bạn sẽ không viết một dòng JS singe. Bạn chỉ cần một số CSS (trong Flex bạn cũng cần nó). Vì vậy, nếu giao diện ứng dụng của bạn sẽ hoạt động giống như ứng dụng trên máy tính để bàn và bạn không thể (hoặc không muốn) sử dụng Flex - hãy sử dụng Vaadin. Cảnh báo! Vaadin có chi phí JS lớn cho trình duyệt.
• Nếu bạn tạo ứng dụng giống trang web đơn giản hơn, hãy sử dụng JSF2.0 (với phần phụ trợ mùa xuân như trên). Bạn sẽ cần phải chiến đấu với HTML (tôi ghét nó) và việc tạo giao diện phong phú sẽ khó hơn Vaadin (đặc biệt là bố cục). Bạn sẽ nhận được HTML nhẹ cho các trình duyệt / trình biên dịch chậm hơn. Tôi thích PrimeFaces - nó dễ dàng và được ghi chép đầy đủ. Vị trí thứ hai là IceFaces
• Nếu bạn tạo một trang web (KHÔNG PHẢI là ứng dụng web) nơi bạn cần đưa sự sống vào HTML (thay vì tạo ứng dụng doanh nghiệp phù hợp với trình duyệt), hãy sử dụng Wicket (nếu bạn thích dựa trên thành phần, thái độ kéo) hoặc SpringMVC (nếu bạn thích dựa trên mẫu , thúc đẩy thái độ) hoặc chỉ sử dụng Play! khuôn khổ. Hãy nhớ rằng việc tạo các thành phần dựa trên dữ liệu phong phú sẽ khó hơn nhiều nhưng bạn sẽ có quyền kiểm soát từng thẻ của html (nhà thiết kế HTML / Đồ họa của bạn sẽ thích nó)

Đọc Tương lai của Doanh nghiệp Java của Adam Bien ... Rõ ràng (Java EE có / không có Spring và Vice Versa) , bao gồm các nhận xét để có được cả hai mặt của đồng tiền. Tôi sẽ chọn Spring vì một số lý do và sau đây là một trong số đó (tái hiện một trong những nhận xét từ bài đăng)

'Tôi không chắc bạn đang nói về máy chủ Java EE 6 nào. Có chứng nhận Glassfish và TMAX JEUS. Sẽ mất khá nhiều thời gian (đọc: năm) cho đến khi các phiên bản tương thích với Java EE 6 của WebSphere, WebLogic, JBoss, v.v. được sản xuất và có thể được sử dụng cho ứng dụng thực. Spring 3 chỉ cần Java 1.5 và J2EE 1.4 để có thể dễ dàng sử dụng trong hầu hết các môi trường '

Ý kiến ​​của tôi dựa trên một cái gì đó mà những người khác không đề cập đến, cụ thể là mã tại nơi làm việc của tôi có xu hướng tồn tại trong nhiều thập kỷ (theo nghĩa đen), và do đó việc bảo trì là rất quan trọng đối với chúng tôi. Bảo trì mã riêng của chúng tôi và các thư viện chúng tôi sử dụng. Chúng tôi kiểm soát mã riêng của chúng tôi, nhưng vì lợi ích của chúng tôi là các thư viện chúng tôi sử dụng, được duy trì bởi những người khác trong những thập kỷ đề cập ở trên hoặc hơn.

Để ngắn gọn một câu chuyện dài, tôi đã kết luận rằng cách tốt nhất để đạt được điều này là sử dụng các triển khai mã nguồn mở của các thông số kỹ thuật của Sun đến tận JVM thô.

Trong số các triển khai mã nguồn mở, Apache Jakarta đã chứng tỏ khả năng duy trì các thư viện của họ và gần đây Sun đã làm rất nhiều việc trong việc tạo ra các triển khai chất lượng cao cho Glassfish v3. Trong mọi trường hợp, chúng tôi cũng có nguồn cho tất cả các mô-đun, vì vậy nếu vẫn thất bại, chúng tôi có thể tự bảo trì chúng.

Thông số kỹ thuật của mặt trời thường rất nghiêm ngặt có nghĩa là việc triển khai phù hợp với thông số kỹ thuật có thể được thay thế cho nhau một cách dễ dàng. Chỉ cần xem qua các thùng chứa servlet.

Trong trường hợp cụ thể này, tôi khuyên bạn nên xem qua JavaServer Faces đơn giản vì nó là một phần của Java EE 6 có nghĩa là nó sẽ có sẵn và duy trì trong một thời gian rất dài. Sau đó, chúng tôi đã chọn tăng cường với MyFaces Tomahawk vì nó cung cấp một số bổ sung hữu ích và đó là một dự án jakarta.

Không có gì sai với JBoss Seam hoặc những người khác. Nó chỉ là sự tập trung của họ ít hướng tới vấn đề bảo trì vốn rất quan trọng đối với chúng tôi.

Tôi có thể sử dụng Spring nếu bạn đã có nó, nhưng đối với dự án mới, vấn đề là gì? Tôi sẽ trực tiếp sử dụng Java EE 6 (ejb3, jsf2.0, v.v.)

Nếu khách hàng ổn với Flex, hãy tiếp tục. Sử dụng BlazeDS hoặc tương tự - không có mvc. Bạn có thể dành nhiều thời gian hơn cho phần đó (trao đổi dữ liệu giữa máy chủ và máy khách) nhưng bạn có toàn quyền kiểm soát ở cả hai phía.

Không sử dụng Vaadin, trừ khi bạn muốn hủy trình duyệt của mình. Thêm vào đó, bạn dành nhiều thời gian hơn để xử lý mã khi các trang của bạn trở nên phức tạp hơn. Ngoài ra, tư duy của bạn sẽ cần được thay đổi hoàn toàn và bất cứ điều gì bạn biết về phát triển giao diện người dùng tiêu chuẩn sẽ trở nên lãng phí. Lập luận rằng bạn không phải sử dụng HTML hoặc JS không có nhiều ý nghĩa. Bạn vẫn phải biết nó ngay cả khi bạn không sử dụng nó. Cuối cùng nó kết xuất với HTML và JS. Sau đó, cố gắng gỡ lỗi nó - đảm bảo bạn có vài ngày cho những thứ đơn giản. Thêm vào đó, tôi không thể tưởng tượng nhà phát triển web lại không biết html / js.

Tôi chỉ không hiểu tại sao mọi người đang thử tất cả những điều trừu tượng đó thay vì sử dụng Java EE trực tiếp.

Tại sao vẫn có những lời bàn tán về việc EJB là đối thủ nặng ký trong năm 2010? Có vẻ như mọi người không được cập nhật công nghệ Java EE. Chỉ cần dùng thử, bạn sẽ ngạc nhiên thú vị về cách mọi thứ được đơn giản hóa trong Java EE 6.

Câu trả lời cho câu hỏi của bạn phụ thuộc vào yêu cầu dự án của bạn. Nếu bạn không yêu cầu các tính năng Java EE như hàng đợi tin nhắn, giao dịch toàn cầu được quản lý vùng chứa, v.v. thì hãy sử dụng tomcat + spring.

Cũng từ kinh nghiệm, tôi nhận thấy rằng các dự án yêu cầu nhiều tích hợp dịch vụ web, lập lịch, hàng đợi tin nhắn tốt nhất nên được thực hiện bằng cách sử dụng một số ngăn xếp Java EE. Điều tốt là sử dụng spring, bạn vẫn có thể tích hợp với các mô-đun Java EE chạy trong một máy chủ ứng dụng.

Java EE 6 rất khác so với các phiên bản trước và nó thực sự làm cho mọi thứ dễ dàng hơn rất nhiều. Java EE 6 kết hợp những ý tưởng tốt nhất từ ​​cộng đồng Java đa dạng - ví dụ như Rod Johnson từ Spring framework đã tích cực tham gia vào việc tạo ra Dependency Injection JSR trong Java EE 6. Một lợi ích của việc sử dụng Java EE 6 là bạn đang viết mã theo một tiêu chuẩn, có thể quan trọng trong một số tổ chức để hỗ trợ nhà cung cấp, v.v.

GlassFish v3 hỗ trợ Java EE 6 và nó khá nhẹ và khởi động rất nhanh. Tôi đã sử dụng glassfish v3 cho các phát triển của mình và nó thực sự dễ dàng cấu hình. Nó đi kèm với một bảng điều khiển quản trị rất thân thiện với người dùng cho phép bạn quản trị máy chủ của mình bằng đồ họa.

Nếu bạn đang sử dụng GlassfishV3 và JSF 2, thì bạn có thể tận dụng các tính năng CDI của Java EE 6, cho phép bạn dễ dàng tạo các cuộc hội thoại (ví dụ như trình hướng dẫn giống trang) trong JSF.

Phải nói rằng, sử dụng Java EE 6 cũng đòi hỏi bạn phải học một API mới. Tùy thuộc vào khung thời gian có sẵn, nó có thể không phải là lựa chọn tốt nhất cho bạn. Tomcat đã có từ lâu đời và sự kết hợp tomcat + spring đã được nhiều dự án web áp dụng, có nghĩa là có rất nhiều tài liệu / diễn đàn.

Tôi đã làm việc trong cả Spring và Java EE 6. Điều tôi có thể nói từ kinh nghiệm của mình là Nếu bạn đang sử dụng JSP cũ hoặc Flex độc quyền thì bạn sẽ an toàn nếu ở lại với Spring.

Nhưng nếu bạn muốn tiếp tục với JSF thì đã đến lúc chuyển sang Java EE 6. Với Java EE 6, bạn đang chuyển sang các Thư viện mã lệnh và thư viện thành phần được chuẩn hóa. Không còn sự không tương thích tập lệnh và ma trận thư viện thành phần.

Về Spring MVC, nó tốt miễn là dự án của bạn không phát triển quá lớn. Nếu đó là một ứng dụng doanh nghiệp lớn, hãy sử dụng Java EE 6. Bởi vì đó là cách duy nhất bạn có thể duy trì các thư viện thành phần và gói tài nguyên của riêng mình một cách có trật tự.

Nếu bạn cần Java EE đầy đủ, tôi khuyên bạn nên dùng GlassFish 3.1. Nó bắt đầu rất nhanh so với các bộ chứa Java EE khác, nó thực hiện một số phần hoặc tất cả Java EE 6 (JBoss 6, WebLogic 10.3.4), việc triển khai lại mất vài giây và hầu như tất cả có thể được thực hiện theo quy ước qua cấu hình, nó rất thân thiện.

Tôi muốn một cái gì đó "Nhẹ", bạn có thể tùy chỉnh Apache Tomcat 7.x với các tính năng mong muốn. Tôi đã sử dụng rất nhiều với các thư viện sau: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - chỉ giao dịch cục bộ tài nguyên JSF 2.x (Mojarra) RichFaces 4.0 BIRT thời gian chạy

Là một nhà phát triển Java EE trong 10 năm qua (tôi bị ảnh hưởng bởi các công nghệ web EJB, JSF và web sớm), Java EE 6 rất dễ dàng, kết hợp tốt và phần cứng hiện tại chạy trơn tru nên những lý do ban đầu thúc đẩy Spring không còn hợp lệ.

Tôi vẫn thích mùa xuân hơn.

Và tôi sẽ chuyển JSF. Tôi nghĩ đó là một công nghệ đã chết. Spring MVC sẽ là một lựa chọn thay thế tốt hơn. Flex cũng vậy. Hãy suy nghĩ về các dịch vụ XML đầu tiên theo hợp đồng và bạn có thể tách hoàn toàn phần cuối khỏi giao diện người dùng.

Tôi muốn giới thiệu Spring + Tomcat trừ khi bạn có thể đợi thời gian để glassfish v3 và Weld trở nên trưởng thành hơn. Hiện có một số vấn đề với mức tiêu thụ bộ nhớ / tải cpu khi chạy glassfish với các ứng dụng hỗ trợ CDI.

Tôi đã không đọc tất cả mọi thứ nhưng chỉ để nói rằng bây giờ bạn có thể sử dụng EJB3 trong cuộc chiến trên Java EE 6 để bạn có thể sử dụng EJB3 trên Tomcat (tôi nghĩ vậy).

Tôi đã giới thiệu cho bạn Tomcat với Spring vì:

1. Spring có thể tạo ra các hạt đậu hỗ trợ cho JSP
2. Bạn sẽ sử dụng Spring để duy trì đối tượng thông qua JPA

Chọn Tomcat là một lựa chọn tốt vì bạn không cần bất kỳ quá trình xử lý nặng nề nào