Chúng tôi đang có kế hoạch viết một ứng dụng web từ đầu, nó đã được quyết định đi với phiên bản mới nhất của Glassfish tuân thủ tiêu chuẩn Java EE 6, do đó chúng tôi đang phân tích nếu CDI có thể được sử dụng thay vì Spring.CDI có phải là sự thay thế tốt cho mùa xuân?
Chúng ta có thể nói rằng CDI có thể thay thế cho mùa xuân?
CDI là viết tắt của "bối cảnh và tiêm phụ thuộc", trong khi mùa xuân là một hệ sinh thái hoàn chỉnh xung quanh một container tiêm phụ thuộc. Để so sánh cả hai, bạn phải phân biệt so sánh.
Tiêm phụ thuộc được xử lý bởi cả hai vùng chứa. Điểm khác biệt chính là CDI xử lý DI theo cách động (còn gọi là: trạng thái) - điều này có nghĩa là các phụ thuộc được giải quyết tại thời gian thực hiện. Cách tiếp cận của Spring là static - điều này có nghĩa là các thành phần được kết nối với nhau tại thời gian tạo. Mặc dù cách CDI có vẻ hơi khác thường ở cái nhìn đầu tiên, nó vượt trội hơn rất nhiều và cung cấp các tùy chọn nâng cao hơn (tôi viết bài này với nền của hai ứng dụng CDI hiệu quả).
Nếu bạn nhìn vào các hệ sinh thái , tình hình là khác nhau: Mùa xuân đi kèm với rất nhiều lọ (> 150), trong khi CDI là khá nhỏ của chính nó. Một điển hình sử dụng CDI sẽ nằm bên trong một máy chủ ứng dụng Java EE 6, nhưng bạn có thể dễ dàng làm cho nó hoạt động trong một công cụ servlet hoặc thậm chí là Java SE. Điều này có nghĩa là việc sử dụng CDI sẽ không đưa ra giả định về việc sử dụng Hibernate, JPA, EJB hay bất kỳ thứ gì - tùy thuộc vào bạn.
Nếu bạn cần thêm chức năng, CDI đi kèm với khái niệm về các tiện ích mở rộng di động (tự nó làm cho API đáng giá). Các mô-đun mở rộng độc lập như Apache CODI và Seam 3 tồn tại và bao gồm các chủ đề như bảo mật, gửi thư, báo cáo và hơn thế nữa.
Để tóm tắt: CDI không giống như "thay thế" cho hệ sinh thái mùa xuân, nó đúng hơn là một cải tiến so với cơ chế tiêm phụ thuộc của Spring. Đó là một phần của Java EE 6, vì vậy nếu bạn đang sử dụng GlasFish với Java EE 6, bạn chắc chắn nên đi CDI. Trong mắt tôi, câu hỏi của bạn là khá: Tôi có thể thay thế Spring bằng Java EE 6 không? Tôi đoán câu trả lời của tôi là khá rõ ràng ;-)
Có một cái nhìn tại Weld để có được một sự khởi đầu tốt ...
Tôi nghĩ rằng CDI sử dụng inyection tĩnh như mùa xuân. Theo [Tài liệu được hàn] (http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#injection) 'Chú giải @Inject cho phép chúng tôi xác định điểm tiêm được tiêm khi tôi hiểu nó, tiêm động là tiêm xảy ra nhiều lần. Nó xảy ra mỗi khi một phương thức kinh doanh được gọi vào thành phần đó. Ngoài ra đối với tôi, 'trạng thái vô hạn 'có nghĩa là khả năng xử lý việc tiêm đậu từ các ngữ cảnh khác nhau, nó sử dụng các proxy tham chiếu đến trường hợp“ đúng ”của mỗi bean –
Không, điều đó không đúng - tôi không tuân theo định nghĩa của bạn năng động tiêm. Phần năng động của CDI là các phụ thuộc được ủy quyền (như viết của bạn) và proxy sẽ cẩn thận để giải quyết sự phụ thuộc đúng khi được yêu cầu (vì vậy hai yêu cầu phụ thuộc có thể được chuyển tiếp đến hai trường hợp phụ thuộc khác nhau). Nhưng có thể một nhận xét không phải là nơi thích hợp để bắt đầu một cuộc thảo luận, bạn có thể muốn mở một câu hỏi mới cho điều đó ... –
Đây có phải là trường hợp này không? – naaz
Mùa xuân không chỉ là thùng chứa phụ thuộc. Nó cũng có các công cụ cho AOP, các mẫu để sử dụng với JPA, SQL, v.v. và thậm chí nhiều hơn nữa.
Tuy nhiên, CDI có thể được sử dụng để thay thế cho DI API của Spring.
Tôi nghĩ CDI xử lý AOP qua bộ chặn Interceptors – prassee
Thiết bị chặn rất giống với AOP nói chung, nhưng chúng không có bề rộng của các tính năng mà khung hoặc ngôn ngữ AOP như AspectJ cung cấp. – Behrang
Bạn có thể viết các tiện ích mở rộng bổ sung các trình chặn đánh chặn dựa trên các quy tắc của bạn cho đậu. Điều đó rất dễ. Đối với hầu hết các ứng dụng, tập quán sử dụng AOP quá phức tạp để có ích. –
Tôi đang sử dụng Apache OpenWebBeans như thực hiện CDI và MyFaces CODI như phần mở rộng di động cho một số dự án. Tôi rất hài lòng với nó và tôi không có vấn đề với nó. OpenWebBeans hiện thiếu một chút về tài liệu nhưng nếu bạn không thể làm việc gì đó thì khá dễ sử dụng các Maven Archetypes do MyFaces cung cấp để tạo các dự án đơn giản với tất cả các phụ thuộc cần thiết hoặc bạn yêu cầu trong danh sách gửi thư. Thật tuyệt vời nếu bạn chỉ làm việc trên Ứng dụng của mình và bạn không bị chặn bởi các lỗi khó chịu. Tôi cũng đã làm rất nhiều dự án với Spring. Được rồi, nhưng nếu bạn hỏi tôi sẽ sử dụng cái gì cho dự án tiếp theo thì câu trả lời rõ ràng là OpenWebBeans và CODI! Tôi thích OpenWebBeans hơn Weld vì OpenWebBeans rất dễ chấp nhận, điều này rất tuyệt vì bạn có thể tùy chỉnh nhiều hơn hoặc ít hơn tất cả mọi thứ không được APII/SPI chính thức và runtimeperformance thực hiện tốt hơn.Và sau dự án đầu tiên, tôi sẽ không bao giờ hỏi CODI nữa vì nó rất ổn định, chúng có bản phát hành thường xuyên và hầu hết trong số chúng mang lại những tính năng mới tuyệt vời giúp cải thiện năng suất rất nhiều. CODI là IMHO nơi ổn định nhất và hầu hết các cải tiến đến từ toàn bộ đất CDI.
Để trả lời câu hỏi của bạn: Đối với tôi CDI thay thế hoàn toàn Spring, nhưng bạn cần các phần mở rộng di động lấp đầy khoảng trống. CDI như là tiêu chuẩn không bao giờ có ý định giải quyết mọi thứ và một số phần như các cuộc hội thoại bị phá vỡ bởi thiết kế. Tin tốt là bạn có những dự án tuyệt vời như MyFaces CODI. CODI sửa hầu như tất cả các vấn đề đó.
Xem thêm https://dzone.com/articles/cdi-10-vs-spring-31-feature – GKislin