Google Guice và JSR-299 CDI/Weld

Question

Được hàn, JSR-299 Contexts và Dependency Injection reference reference, tự coi mình là kiểu kế thừa của Spring và Guice.

CDI chịu ảnh hưởng của một số khung công tác Java hiện có, bao gồm Seam, Guice và Spring. Tuy nhiên, CDI có tính cách riêng, rất khác biệt: an toàn hơn Seam, trung tâm hơn và ít tập trung hơn XML so với Spring, nhiều ứng dụng web và doanh nghiệp hơn Guice. Nhưng nó không thể là một trong số này mà không có cảm hứng từ các khuôn khổ được đề cập và rất nhiều công việc cộng tác và chăm chỉ của Nhóm chuyên gia JSR-299 (EG).

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

Điều gì làm cho mối hàn có khả năng hơn cho các ứng dụng doanh nghiệp so với Guice? Có lợi thế hay bất lợi nào so với Guice không? Bạn nghĩ gì về Guice AOP so với Wcept interceptor? Điều gì về hiệu suất?

My lựa chọn

Cuối cùng tôi quyết định sử dụng Guice vì tôi thích mô hình lập trình sạch mà đi kèm hầu như không có chú thích bên cạnh @Inject theo mặc định. Việc sử dụng libs bên ngoài với Guice dễ dàng hơn nhiều so với CDI. AOP cũng khá đơn giản với Guice.

Answer 1

CDI (Weld) chưa được sử dụng rộng rãi, do đó so sánh khó thực hiện. Một vài điểm:

• CDI được thiết kế với sự tích hợp với tiêu chuẩn EJB3, JSF và các tiêu chuẩn JavaEE khác. CDI có các phần mở rộng di động cho phép các thư viện của bên thứ ba tích hợp với vòng đời và chức năng nội bộ của việc thực hiện CDI. . Spring, Guice và Seam phát triển thành một trạng thái như vậy, trong khi CDI sử dụng kinh nghiệm từ ba nhóm này.
• theo ý kiến ​​của tôi, những người đánh chặn CDI sẽ không thể đáp ứng tất cả các yêu cầu mà AOP Xuân đã gặp. Có lẽ cũng vậy với Guice AOP. Bạn không thể định nghĩa một interceptor bằng cách sử dụng cú pháp AspectJ.
• việc thiếu định nghĩa xml vừa là lợi thế vừa là một bất lợi và một số người (đúng trong một số trường hợp) thích cấu hình xml.
• việc sử dụng mở rộng các chú thích định danh sẽ (theo ý kiến ​​của tôi) tạo ra một số mớ hỗn độn lớn nếu không được sử dụng cẩn thận.

Answer 2

Trước khi cố gắng để trả lời câu hỏi của bạn, hãy để tôi chỉ cần thêm một phần quan trọng của thông tin: JSR 330 (@Inject) đã được tiêu chuẩn hóa bởi Guice và các dự án Spring (announcement from May 2009) và đang được reused in JSR 299. Điều này bao gồm các cơ chế DI cơ bản về khai báo một điểm tiêm.

Bây giờ, hãy quay lại câu hỏi - với tuyên bố từ chối trách nhiệm rằng tôi có nhiều kinh nghiệm hơn với Spring so với Guice.

khả năng doanh nghiệp trong Weld

• Alternative configuration mechanisms có một thiết kế rất sạch sẽ trong JSR-299 và cho phép cơ chế cấu hình bên ngoài của mã Java (beans.xml).
• Events là một điều rất mạnh mẽ và phù hợp độc đáo với JMS. Tôi chỉ tìm thấy một số Event Bus for Guice, nhưng tôi không thể nói điều đó so sánh như thế nào.
• Portable extensions là SPI có thể được sử dụng để tích hợp với công nghệ hiện có hoặc bọc mã cũ theo cách rõ ràng.

Ưu/Nhược điểm

Lưu ý: Tôi sẽ cố gắng thêm một vài mặt hàng ở đây sau đó, nhưng câu trả lời này đã kéo dài hơn tôi mong đợi đã, xin lỗi.

• Weld/CDI

  • Tiêu chuẩn: Nếu một cái gì đó được chuẩn hóa và có một thực hiện tốt, có rất nhiều người sẽ sử dụng nó. Ví dụ: Built-in scopes trong Weld cung cấp thêm một vài phạm vi hơn Guice hoặc Spring. Tất cả những điều này có thể được mở rộng, nhưng các khung ứng dụng sẽ dựa vào các phạm vi tiêu chuẩn nếu chúng được sử dụng bởi một cộng đồng lớn.
  • Hỗ trợ vùng chứa: điều này tương tự với mục trước đó, nhưng là một đối số chính cho việc áp dụng. Các máy chủ ứng dụng mã nguồn mở lớn, chẳng hạn như Glassfish và JBoss 6 cung cấp hỗ trợ CDI (xem here).

• Guice/Spring

  • ứng dụng thực tế: Hầu hết các ứng dụng hiện có sẽ được sử dụng Guice/mùa xuân rồi. Spring/Guice đã luôn luôn xây dựng trên các tiêu chuẩn và cung cấp các khả năng mới mà không có tiêu chuẩn tồn tại hoặc không thể được sử dụng. Nếu bạn làm theo các phương pháp hay nhất tương ứng, khuôn khổ sẽ giúp bạn làm cho các ứng dụng của bạn dựa trên các tiêu chuẩn và sạch sẽ.

AOP và đánh chặn

Đây là một chủ đề rất nặng nề thảo luận, và tôi không thể ủng hộ một trong khác. Cả hai cơ chế này đều rất mạnh mẽ nhưng đòi hỏi ít nhất một sự hiểu biết tối thiểu về kiến ​​trúc của ứng dụng. Ngoài ra, hãy xem Decorators và tham chiếu Events trước đây. Tốt nhất là nên sử dụng đúng công cụ, nhưng đừng quên rằng nếu một nhà phát triển phải làm việc với một trong những cơ chế này thì đó là điều tốt nếu anh ta/cô ta hiểu khái niệm đó.

Performance

Đáng tiếc là tôi không thể nhìn vào điều này, nhưng có một vài quy tắc tôi cố gắng để làm theo, đặc biệt là khi sử dụng một khuôn khổ cung cấp cho bạn rất nhiều chức năng mà bạn không chú ý đến nó:

• Bất cứ khi nào có thể, hãy ưu tiên một bước đấu dây đơn qua nhiều lần tra cứu khi chạy.
• Nếu có thể, hãy thực hiện tất cả các hệ thống dây điện khi khởi tạo ứng dụng.
• Bất kỳ bước chặn hoặc proxy AOP nào thêm một vài lời gọi phương thức vào ngăn xếp.

Answer 3

Một điểm khác biệt là CDI có định hướng Java EE rất cao. Nó cung cấp một cơ chế để keo khác nhau hệ thống con Java EE cùng nhau.

Tức là. Bằng cách chú thích một bean với @Named("book"), hạt đậu được biết đến trong EL thống nhất (Ngôn ngữ biểu thức) là 'book'.

Sau đó, bạn có thể sử dụng nó trong một trang JSF ví dụ:

<h:outputLabel value="Book title:" for="bookTitle"/> 
    <h:outputText id="bookTile" value="#{book.title}"/> 

Answer 4

Tính năng quan trọng nhất CDI đã trái ngược với Guice, là nó là một chuẩn phần của Java EE 6.

Tầm quan trọng của điều này không thể được đánh giá thấp, vì nó có nghĩa là CDI là tiêu chuẩn DI bạn nên sử dụng khi viết mã các ứng dụng web. Trong khi trở lại, tôi đã xem xét các công nghệ để có thể xác định cách chúng ta có thể có phân phối lõi chuẩn - được chuẩn bị phù hợp - nơi chúng ta có thể thêm các mô đun bổ sung theo ý muốn có thể ghi đè lên chức năng hiện tại mà không phải thay đổi lõi mô-đun. I E. thêm một cái bình và chức năng này sẽ tự động kích hoạt. Chúng tôi đã sử dụng JSR-330 chú thích cho mã của chúng tôi, và sau đó sử dụng CDI hoặc Guice (SVN, sắp tới), chúng tôi đã sử dụng JSR-330 chú thích cho mã của chúng tôi. thực sự ngay bây giờ trong 3.0) là động cơ.

Sau một vài dự án tôi thấy rằng tôi thích cấu hình Guice tốt nhất thay vì ma thuật mờ đục xảy ra ở Weld. Ngoài ra tôi thấy rằng cách để làm những gì chúng ta muốn như mô tả ở trên với Weld, tôi phải đánh dấu lớp trong jar phụ như @Alternative, và sau đó đề cập đến trong beans.xml mà tôi muốn lớp thay thế được thi hành (và đó không phải là mạnh mẽ chống lại tái cấu trúc). Tuy nhiên, tất cả trong tất cả, JSR-330 cho phép chúng ta làm điều gì đó rất tẻ nhạt và mong manh trước đây (vì new liên kết cực kỳ chặt chẽ), và đó là một chiến thắng tuyệt vời. Tôi có thể khuyên bạn nên xem xét DI nếu bạn có nhu cầu như thế này.

Answer 5

CDI for Guice users là một so sánh tốt đẹp.