it-swarm-vi.tech

Tôi nên sử dụng EJB3 hoặc Spring cho lớp doanh nghiệp của mình?

Nhóm của tôi đang phát triển một sản phẩm hướng dịch vụ mới với giao diện người dùng web. Trong các cuộc thảo luận về những công nghệ mà chúng tôi sẽ sử dụng, chúng tôi đã giải quyết việc chạy máy chủ ứng dụng JBoss và lối vào Flex (có thể triển khai trên máy tính để bàn bằng Adobe AIR) và các dịch vụ web để giao diện máy khách và máy chủ.

Chúng tôi đã đạt đến một bế tắc khi nói đến việc sử dụng công nghệ máy chủ nào cho logic kinh doanh của chúng tôi. Cuộc tranh luận lớn là giữa EJB3 và Spring, với mối quan tâm lớn nhất của chúng tôi là khả năng mở rộng và hiệu suất, và khả năng duy trì của cơ sở mã.

Đây là câu hỏi của tôi:

  1. Các đối số cho hoặc chống lại EJB3 so với Spring là gì? [.__.]
    • Những cạm bẫy tôi có thể mong đợi với mỗi?
    • Tôi có thể tìm thông tin điểm chuẩn ở đâu?
71
Justin Standard

Sẽ không có nhiều khác biệt giữa EJB3 và Spring dựa trên Hiệu suất. Chúng tôi chọn Spring vì những lý do sau (không được đề cập trong câu hỏi):

  • Spring điều khiển kiến ​​trúc theo hướng dễ dàng hơn hỗ trợ kiểm tra đơn vị. Ví dụ: tiêm một đối tượng DAO giả để kiểm tra đơn vị lớp doanh nghiệp của bạn hoặc sử dụng đối tượng MockHttpRequest của Spring để kiểm tra đơn vị một servlet. Chúng tôi duy trì một cấu hình Spring riêng cho các thử nghiệm đơn vị cho phép chúng tôi cách ly các thử nghiệm với các lớp cụ thể.
  • Một trình điều khiển ghi đè là khả năng tương thích. Nếu bạn cần hỗ trợ nhiều hơn một Máy chủ ứng dụng (hoặc cuối cùng muốn tùy chọn chuyển từ JBoss sang Glassfish, v.v.), về cơ bản, bạn sẽ mang theo thùng chứa (Spring) bên mình, thay vì dựa vào khả năng tương thích giữa các triển khai khác nhau của Đặc điểm kỹ thuật EJB3.
  • Spring cho phép các lựa chọn công nghệ cho Tính bền bỉ, từ xa đối tượng, v.v. Ví dụ: chúng tôi cũng đang sử dụng giao diện Flex và đang sử dụng giao thức Hessian để liên lạc giữa Flex và Spring.
72
John Stauffer

Khoảng cách giữa EJB3 và Spring nhỏ hơn nhiều so với trước đây, rõ ràng. Điều đó nói rằng, một trong những nhược điểm của EJB3 bây giờ là bạn chỉ có thể tiêm vào một hạt đậu, vì vậy cuối cùng bạn có thể biến các thành phần thành đậu không cần thiết.

Đối số về kiểm thử đơn vị hiện tại không liên quan - EJB3 được thiết kế rõ ràng để dễ kiểm tra đơn vị hơn.

Đối số tương thích ở trên cũng không liên quan: dù bạn sử dụng EJB3 hay Spring, bạn vẫn phụ thuộc vào các triển khai do bên quản lý giao dịch, JMS cung cấp, v.v.

Điều gì sẽ cuốn nó cho tôi, tuy nhiên, là sự hỗ trợ của cộng đồng. Làm việc trong một dự án EJB3 năm ngoái, không có nhiều người ngoài đó sử dụng nó và nói về vấn đề của họ. Mùa xuân, đúng hay sai, cực kỳ phổ biến, đặc biệt trong doanh nghiệp và điều đó giúp dễ dàng tìm thấy ai đó có cùng vấn đề mà bạn đang cố gắng giải quyết.

37
PEELY

Các đối số cho hoặc chống lại EJB3 so với Spring là gì ? Spring luôn đổi mới và nhận ra các ràng buộc trong thế giới thực. Spring mang đến sự đơn giản và thanh lịch cho các máy chủ ứng dụng Java 1.4 và không yêu cầu phiên bản đặc tả J2EE mà không ai có quyền truy cập vào năm 2004 - 2006. Tại thời điểm này, nó gần như là một tôn giáo tranh luận rằng bạn có thể bị cuốn hút vào - Thông số kỹ thuật Spring + trừu tượng + mã nguồn mở so với Java Enterprise Edition (Java EE) 5.0.

Tôi nghĩ Spring bổ sung nhiều hơn so với các đối thủ với các thông số Java EE. Vì các tính năng từng là duy nhất của Spring tiếp tục được đưa vào đặc tả, nhiều người sẽ lập luận rằng EJB 3 cung cấp một bộ tính năng 'đủ tốt' cho hầu hết các ứng dụng kinh doanh nội bộ.

Những cạm bẫy nào tôi có thể mong đợi với mỗi ? Nếu bạn coi đây là vấn đề dai dẳng (Spring + JPA) so với EJB3 thì bạn thực sự không phải là một lựa chọn lớn.

Tôi có thể tìm thấy thông tin điểm chuẩn tốt ở đâu ? Tôi đã không theo dõi kết quả điểm chuẩn specj đôi khi, nhưng chúng đã phổ biến trong một thời gian. Dường như mỗi nhà cung cấp (IBM, JBOSS, Oracle và Sun) ngày càng ít quan tâm đến việc có một máy chủ tuân thủ. Các danh sách nhận được ngắn hơn và ngắn hơn các nhà cung cấp được chứng nhận khi bạn đi từ 1.3, 1.4. 1.5 Java Phiên bản doanh nghiệp. Tôi nghĩ rằng thời của một máy chủ khổng lồ tuân thủ đầy đủ tất cả các thông số kỹ thuật đã kết thúc.

18
Brian

Tôi chắc chắn sẽ giới thiệu EJB3 trong mùa xuân. Chúng tôi thấy rằng nó được sắp xếp hợp lý hơn, mã hóa đẹp hơn và được hỗ trợ tốt hơn. Trước đây tôi đã sử dụng Spring và thấy nó rất khó hiểu và không được ghi chép rõ ràng như EJB3 (hoặc JPA tôi đoán vào cuối ngày)

  1. Kể từ EJB3, bạn không còn phải đối phó với các tệp cấu hình bên ngoài và chỉ có một POJO mà bạn chú thích trên mỗi bảng cơ sở dữ liệu. POJO này có thể được chuyển đến tầng web của bạn mà không gặp vấn đề gì. Các IDE như Netbeans thậm chí có thể tự động tạo các POJO này cho bạn. Chúng tôi đã sử dụng EJB3 như là phần cuối cho khá nhiều ứng dụng quy mô lớn và không nhận thấy bất kỳ vấn đề nào về hiệu suất. Đậu phiên của bạn có thể dễ dàng được hiển thị dưới dạng các dịch vụ web mà bạn có thể hiển thị cho giao diện Flex của mình. Đậu phiên dễ dàng khóa ở một phương thức hoặc cấp lớp để gán vai trò và những thứ tương tự nếu bạn cần.

Tôi không thể nói nhiều về mùa xuân, vì tôi chỉ thử nó trong vài tuần. Nhưng ấn tượng chung của tôi về nó rất kém. Điều đó không có nghĩa là khung xấu, nhưng nhóm của chúng tôi ở đây đã tìm thấy EJB3 là tốt nhất cho tầng kinh doanh/kiên trì.

9
rustyshelf

Tôi có xu hướng thích Spring hơn EJB3 nhưng khuyến nghị của tôi là bất kỳ cách tiếp cận nào bạn thực hiện, hãy cố gắng viết POJO và sử dụng các chú thích tiêu chuẩn nếu có thể, như các chú thích JSR như @PostConstruct, @PreDestroy và @Resource hoạt động với cả EJB3 hoặc Spring để bạn có thể chọn bất kỳ khung nào bạn thích.

ví dụ. bạn có thể quyết định một số dự án sử dụng Guice thay thế cho IoC.

Nếu bạn muốn sử dụng phép tiêm theo yêu cầu trước, chẳng hạn như trong ứng dụng web, bạn có thể thấy Guice nhanh hơn một chút đối với phép tiêm phụ thuộc so với Spring.

Đậu phiên chủ yếu đun sôi để tiêm phụ thuộc và giao dịch; Vì vậy, EJB3 và Spring giống nhau thực sự cho điều đó. Trường hợp Spring có Edge là tiêm phụ thuộc tốt hơn và trừu tượng hơn cho những thứ như JMS

7
James Strachan

tôi đã sử dụng một kiến ​​trúc rất giống nhau trong quá khứ. Spring + Java 1.5 + Hành động 2/3 khi được kết hợp với Dịch vụ dữ liệu Flex giúp mã hóa rất dễ dàng (và thú vị!). Tuy nhiên, giao diện Flex có nghĩa là bạn cần máy khách mạnh mẽ .

2
Soumitra

Liên quan đến câu hỏi của bạn:

Các đối số cho hoặc chống lại EJB3 vs Spring là gì?

Tôi đề nghị đọc phản hồi từ các chuyên gia: MỘT TRẢ LỜI ĐẾN: EJB 3 VÀ PHÂN TÍCH PHÂN TÍCH THÀNH PHẦN của Mark Fisher . Đọc các bình luận để tìm nhận xét của Reza Rahman (EJB 3.0).

1
krams

Một điều nữa có lợi cho mùa xuân là hầu hết các công cụ/khung công tác khác có hỗ trợ tốt hơn cho việc tích hợp với mùa xuân, hầu hết chúng cũng sử dụng mùa xuân trong nội bộ (ví dụ: activemq, lạc đà, CXF, v.v.).

Nó cũng trưởng thành hơn và có nhiều tài nguyên hơn (sách, bài viết, thực tiễn tốt nhất, v.v.) và các nhà phát triển có kinh nghiệm có sẵn hơn so với EJB3.

0
kamal.gs