Tôi vừa mới bắt đầu đọc qua Core JavaServer Faces, Phiên bản thứ 3. và họ nói điều này (nhấn mạnh của tôi):

Đó là một sự cố lịch sử mà có hai cơ chế riêng biệt, các bean CDI và các bean được quản lý JSF, cho các bean có thể được sử dụng trong các trang JSF. Chúng tôi khuyên bạn nên sử dụng các hạt CDI trừ khi ứng dụng của bạn phải hoạt động trên một trình chạy servlet đơn giản như Tomcat.

Tại sao? Họ không đưa ra bất kỳ lời biện minh nào. Tôi đã sử dụng @ManagedBeancho tất cả các bean trong một ứng dụng nguyên mẫu chạy trên GlassFish 3 và tôi thực sự không nhận thấy bất kỳ vấn đề nào với điều này. Tôi đặc biệt không bận tâm khi chuyển từ @ManagedBeansang @Named, nhưng tôi muốn biết tại sao tôi phải bận tâm .

CDI được ưu tiên hơn JSF đơn giản vì CDI cho phép đưa vào JavaEE trên toàn bộ phụ thuộc. Bạn cũng có thể tiêm POJO và để chúng được quản lý. Với JSF, bạn chỉ có thể đưa vào một tập hợp con những gì bạn có thể với CDI.

Sử dụng CDI.

Theo JSF 2.3, @ManagedBeanđược tán thành . Xem thêm thông số kỹ thuật số 1417 . Điều này có nghĩa rằng có không nữa một lý do để lựa chọn @ManagedBeanhơn @Named. Điều này lần đầu tiên được triển khai trong phiên bản beta Mojarra 2.3.0 m06.

Lịch sử

Sự khác biệt cốt lõi là, @ManagedBeanđược quản lý bởi khuôn khổ JSF và chỉ @ManagedPropertycó sẵn cho các bean được quản lý JSF khác. @Namedđược quản lý bởi máy chủ ứng dụng (container) qua khuôn khổ CDI và là thông qua @Injectcung cấp cho bất kỳ loại một tạo tác quản lý container như @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, vv và thậm chí là một JSF @ManagedBean. Từ phía bên kia về, @ManagedPropertykhông không làm việc bên trong một @Namedhoặc bất kỳ container quản lý vật khác. Nó chỉ hoạt động bên trong @ManagedBean.

Một sự khác biệt khác là CDI thực sự đưa các proxy ủy quyền cho phiên bản hiện tại trong phạm vi đích trên cơ sở mỗi yêu cầu / luồng (giống như cách EJB được đưa vào). Cơ chế này cho phép đưa một bean có phạm vi hẹp hơn vào bean có phạm vi rộng hơn, điều này không thể thực hiện được với JSF @ManagedProperty. JSF "đưa" vào đây trực tiếp cá thể vật lý bằng cách gọi một setter (đó cũng chính xác là lý do tại sao cần phải có setter, trong khi điều đó không bắt buộc với @Inject).

Mặc dù không trực tiếp là một bất lợi - có những cách khác - phạm vi của @ManagedBeannó chỉ đơn giản là hạn chế. Ở góc độ khác, nếu bạn không muốn phơi bày "quá nhiều" @Inject, bạn cũng có thể giữ lại những hạt đậu đã quản lý của mình @ManagedBean. Nó giống như protectedso với public. Nhưng điều đó không thực sự được tính.

Ít nhất, trong JSF 2.0 / 2.1, nhược điểm lớn của việc quản lý các hạt sao lưu JSF bằng CDI là không có CDI tương đương @ViewScoped. Quá trình @ConversationScopednày đến gần, nhưng vẫn yêu cầu bắt đầu và dừng theo cách thủ công và nó thêm một cidtham số yêu cầu xấu vào các URL kết quả. MyFaces CODI giúp việc này trở nên dễ dàng hơn bằng cách kết nối hoàn toàn minh bạch giữa JSF javax.faces.bean.ViewScopedvới CDI để bạn có thể thực hiện @Named @ViewScoped, tuy nhiên, điều đó sẽ thêm một windowIdtham số yêu cầu xấu vào các URL kết quả, cũng trên điều hướng từ trang đến trang đơn giản. OmniFaces giải quyết tất cả điều này bằng một CDI @ViewScopedthực sự liên kết phạm vi của bean với trạng thái xem JSF thay vì với một tham số yêu cầu tùy ý.

JSF 2.2 (được phát hành 3 năm sau câu hỏi / câu trả lời này) cung cấp một @ViewScopedchú thích hoàn toàn mới tương thích với CDI javax.faces.view.ViewScoped. JSF 2.2 thậm chí còn đi kèm với chỉ CDI @FlowScopedmà không có @ManagedBeantương đương, do đó thúc đẩy người dùng JSF hướng tới CDI. Kỳ vọng là như vậy @ManagedBeanvà bạn bè sẽ không được chấp nhận theo Java EE 8. Nếu bạn hiện vẫn đang sử dụng @ManagedBean, do đó, bạn nên chuyển sang CDI để chuẩn bị cho các lộ trình nâng cấp trong tương lai. CDI có sẵn trong các vùng chứa tương thích với Hồ sơ Web Java EE, chẳng hạn như WildFly, TomEE và GlassFish. Đối với Tomcat, bạn phải cài đặt nó một cách riêng biệt, chính xác như bạn đã làm cho JSF. Xem thêm Cách cài đặt CDI trong Tomcat?

Với Java EE 6 và CDI, bạn có tùy chọn khác cho Managed Beans

• @javax.faces.bean.ManagedBeanlà tham chiếu đến JSR 314 và được giới thiệu với JSF 2.0. Mục tiêu chính là tránh cấu hình trong tệp face-config.xml để sử dụng bean bên trong Trang JSF.
• @javax.annotation.ManagedBean(“myBean”) được định nghĩa bởi JSR 316. Nó tổng quát các bean được quản lý JSF để sử dụng ở những nơi khác trong Java EE
• @javax.inject.Named(“myBean”) gần giống như tệp ở trên, ngoại trừ bạn cần tệp bean.xml trong Thư mục web / WEB-INF để kích hoạt CDI.

Tôi đang sử dụng CDI trong GlassFish 3.0.1, nhưng để nó hoạt động, tôi phải nhập khuôn khổ Seam 3 (Weld). Điều đó hoạt động khá tốt.

Trong GlassFish 3.1 CDI ngừng hoạt động và Seam Weld ngừng hoạt động với nó. Tôi đã mở một lỗi về điều này nhưng vẫn chưa thấy nó được sửa. Tôi đã phải chuyển đổi tất cả mã của mình sang sử dụng các chú thích javax.faces. * Nhưng tôi dự định quay lại CDI khi chúng hoạt động.

Tôi đồng ý rằng bạn nên sử dụng CDI, nhưng một vấn đề mà tôi chưa thấy giải quyết là phải làm gì với chú thích @ViewScoped. Tôi có rất nhiều mã phụ thuộc vào nó. Không rõ liệu @ViewScoped có hoạt động hay không nếu bạn không sử dụng @ManagedBean với nó. Nếu bất cứ ai có thể làm rõ điều này, tôi sẽ đánh giá cao nó.

Một lý do chính đáng để chuyển sang CDI: bạn có thể có một tài nguyên có phạm vi phiên chung (ví dụ: hồ sơ người dùng) @Inject đưa vào cả các dịch vụ được quản lý JSF và các dịch vụ REST (tức là Jersey / JAX-RS).

Mặt khác, @ViewScopedlà một lý do thuyết phục để gắn bó với JSF @ManagedBean- đặc biệt là đối với bất kỳ thứ gì có AJAX quan trọng. Không có tiêu chuẩn thay thế cho điều này trong CDI.

Có vẻ như nó có thể có một số hỗ trợ cho @ViewScopedchú thích giống như đậu CDI, nhưng cá nhân tôi chưa chơi với nó.

http://seamframework.org/Seam3/FacesModule