CDI ve EJB nasıl karşılaştırılır? etkileşim?

İkisinin nasıl etkileşime girdiğini ve aralarındaki sınırın nerede olduğunu anlamakta zorlanıyorum. Çakışıyorlar mı? Aralarında fazlalık var mı?

Her ikisiyle ilişkili ek açıklamalar olduğunu biliyorum, ancak her ikisi için de kısa açıklamalarla tam bir liste bulamadım. Bunun nasıl farklı olduklarını veya nerede çakıştıklarını açıklamaya yardımcı olup olmayacağından emin değilim.

Gerçekten kafam karıştı. EJB'yi oldukça iyi anladığımı düşünüyorum (sanırım), CDI'ın masaya tam olarak ne getirdiğini ve EJB'nin halihazırda sunduklarını nasıl desteklediğini veya geliştirdiğini anlamakta zorlanıyorum.

CDI: bağımlılık enjeksiyonu ile ilgili. Bu, arayüz uygulamasını istediğiniz yere enjekte edebileceğiniz anlamına gelir. Bu nesne herhangi bir şey olabilir, EJB ile ilgili olamaz. İşte CDI kullanarak rastgele jeneratör enjekte etmek nasıl bir örnektir. EJB hakkında hiçbir şey yok. EJB dışı hizmetleri, farklı uygulamaları veya algoritmaları enjekte etmek istediğinizde CDI kullanacaksınız (böylece orada EJB'ye hiç ihtiyacınız yok).
EJB: anlıyorsunuz ve muhtemelen @EJBek açıklamalarla kafanız karışıyor - hizmetinize uygulama enjekte etmenize veya her neyse, size izin veriyor. Ana fikir, enjekte ettiğiniz sınıfın EJB kabı tarafından yönetilmesidir. Görünüşe göre CDI, EJB'nin ne olduğunu anlıyor, bu nedenle Java EE 6 uyumlu sunucuda, sunucu uygulamanızda her ikisini de yazabilirsiniz

@EJB EJBService ejbService;

ve

@Inject EJBService ejbService;

kafanızı karıştırabilecek şey budur, ancak muhtemelen EJB ile CDI arasındaki köprü olan tek şey budur.

CDI hakkında konuştuğumuzda, diğer nesneleri CDI tarafından yönetilen sınıflara enjekte edebilirsiniz (bunlar sadece CDI duyarlı çerçeveler tarafından oluşturulmalıdır).

CDI başka neler sunuyor ... Örneğin, MVC çerçevesi olarak Struts 2'yi kullanıyorsunuz (sadece örnek olarak) ve burada sınırlısınız, EJB 3.1'i kullansanız bile - @EJBStruts eyleminde açıklama kullanamazsınız , konteyner tarafından yönetilmez. Ancak Struts2-CDI eklentisini eklediğinizde @Inject, aynı şey için oraya açıklama yazabilirsiniz (yani artık JNDI araması gerekmez). Bu şekilde EJB gücünü artırır, ancak daha önce de bahsettiğim gibi, CDI ile ne enjekte ettiğiniz - EJB ile ilişkili olup olmadığı önemli değildir ve bu onun gücüdür.

PS. örnek için güncellenmiş bağlantı

Java EE'de şu anda birden fazla bileşen modeli olduğu için şu anda biraz kafa karıştırıcı. Bunlar CDI , EJB3 ve JSF Yönetilen Fasulyelerdir .

CDI mahalledeki yeni çocuk. CDI fasulye özelliği dependency injection, scopingve bir event bus. CDI fasulyeleri, enjeksiyon ve kapsam belirleme açısından en esnektir. Olay veri yolu çok hafiftir ve en basit web uygulamaları için bile çok uygundur. Buna ek olarak, CDI ayrıca portable extensions, satıcıların Java EE'ye tüm uygulamalarda (Glassfish, JBoss AS, Websphere, vb.) Kullanılabilen ekstra işlevsellik sağlaması için bir tür eklenti mekanizması olan çok gelişmiş bir özelliği de ortaya çıkarır. .

EJB3 çekirdekleri eski eski EJB2 bileşen modelinden ^* sonradan uyarlandı ve Java EE'de bir açıklama yoluyla yönetilen ilk çekirdeklerdi. EJB3 fasulye özelliği dependency injection,declarative transactions , declarative security, pooling, concurrency control, asynchronous executionve remoting.

EJB3 çekirdeklerinde bağımlılık enjeksiyonu, CDI çekirdeklerinde olduğu kadar esnek değildir ve EJB3 çekirdeklerinde kapsam belirleme kavramı yoktur. Ancak, EJB3 çekirdekleri işlemseldir ve varsayılan olarak havuzlanır ^** , CDI'nın EJB3 alanında bırakmayı seçtiği çok kullanışlı iki şey. Bahsedilen diğer öğeler de CDI'da mevcut değildir. EJB3'ün kendi başına bir olay veri yolu yoktur, ancak mesajları dinlemek için özel bir fasulye türü vardır; mesaj odaklı fasulye. Bu, Java Mesajlaşma Sisteminden veya JCA kaynak bağdaştırıcısı olan başka herhangi bir sistemden mesaj almak için kullanılabilir. Basit olaylar için tam gelişmiş mesajlaşma kullanmak, CDI olay veri yolundan çok daha ağırdır ve EJB3, bir üretici API'sini değil, yalnızca bir dinleyiciyi tanımlar.

JSF Managed Beans , JSF'nin dahil edilmesinden bu yana Java EE'de mevcuttur. Onlar da öne çıkıyordependency injection ve scoping. JSF Managed Beans, bildirim temelli kapsam belirleme kavramını tanıttı. Başlangıçta kapsamlar oldukça sınırlıydı ve aynı Java EE sürümünde, EJB3 çekirdeklerinin ek açıklamalar aracılığıyla zaten bildirilebildiği durumda, JSF Yönetilen Fasulye'nin hala XML olarak bildirilmesi gerekiyordu. JSF Managed Beans'in mevcut sürümü de nihayet bir açıklama yoluyla bildirilir ve kapsamlar, bir görünüm kapsamı ve özel kapsamlar oluşturma becerisiyle genişletilir. Aynı sayfaya gelen istekler arasındaki verileri hatırlayan görünüm kapsamı, JSF Managed Beans'in benzersiz bir özelliğidir.

Görünüm kapsamı dışında, Java EE 6'da JSF Managed Beans için hala çok az şey var. CDI'daki eksik görünüm kapsamı talihsiz, çünkü aksi takdirde CDI, JSF Managed Beans'in sunduğu mükemmel bir süper set olurdu. Güncelleme : Java EE 7 / JSF 2.2'de CDI uyumlu @ViewScoped eklendi, bu da CDI'yı gerçekten mükemmel bir süper set haline getirdi. Güncelleme 2 : JSF2.3'te, JSF tarafından yönetilen çekirdekler, CDI tarafından yönetilen çekirdekler lehine kullanımdan kaldırılmıştır.

EJB3 ve CDI ile durum o kadar da net değil. EJB3 bileşen modeli ve API, CDI'nın sunmadığı birçok hizmet sunar, bu nedenle tipik olarak EJB3, CDI ile değiştirilemez. Öte yandan, CDI, EJB3 ile kombinasyon halinde kullanılabilir - örneğin, EJB'lere kapsam desteği eklemek.

Uzman grup üyesi ve CanDI adlı bir CDI uygulamasının uygulayıcısı Reza Rahman, sık sık EJB3 bileşen modeliyle ilişkili hizmetlerin bir dizi CDI ek açıklaması olarak güçlendirilebileceğini ima etti. Bu gerçekleşirse, Java EE'deki tüm yönetilen çekirdekler CDI çekirdekleri haline gelebilir. Bu, EJB3'ün kaybolduğu veya eski hale geldiği anlamına gelmez, sadece işlevselliğinin EJB'nin @ Stateless ve @EJB gibi kendi açıklamaları yerine CDI aracılığıyla açığa çıkarılacağı anlamına gelir.

Güncelleme

TomEE ve OpenEJB'den David Blevins, blogunda CDI ve EJB arasındaki farklılıkları ve benzerlikleri çok iyi açıklıyor: CDI, EJB'leri ne zaman kırmalı?

_{* Sadece sürüm numarasında bir artış olmasına rağmen, EJB3 çekirdekleri çoğunlukla tamamen farklı bir fasulye türüdür: basit bir tek açıklama uygulayarak "yönetilen fasulye" haline gelen basit bir pojo, EJB2'deki modele kıyasla ağır ve Her bir çekirdek için aşırı derecede ayrıntılı XML dağıtım tanımlayıcısı gerekliydi, buna ek olarak, çeşitli son derece ağır ve çoğunlukla anlamsız bileşen arabirimleri uygulamak için gerekli olan çekirdek gerekiyordu.}

_{** Durum bilgisi olmayan oturum çekirdekleri tipik olarak havuzlanır, durum bilgisi olan oturum çekirdekleri tipik olarak değildir (ancak olabilirler). Her iki tür için de havuzlama bu nedenle isteğe bağlıdır ve EJB spesifikasyonu bunu her iki şekilde de zorunlu kılmaz.}

Albert Einstein: If you can't explain it simply, you don't understand it well enough

Ejbs ve CDI'ın anlaşılması oldukça basittir.

Ejbs:

1. @Stateless, @Stateful, @Request vb. Gibi kapsam niteleyicileriyle her zaman açıklama yapılır.
2. Ejbs örnekleri Java EE çerçevesi tarafından kontrol edilir ve havuzda toplanır. Tüketici için örnekleri sağlamak EV çerçevesinin görevidir.

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

CarMaker'a özel Ejbs kapsamı eklenmiştir, bu nedenle Ejb'dir.

CDI:

1. Tamamen EE çerçevesi tarafından yönetilmediğinden, örnekler sizin tarafınızdan oluşturulmalıdır.

2. Her zaman bağımlıdır. "Bağımlı" ifadesini örnekle açıklamama izin verin:

   class Specification { private String color; private String model; //- Getter and Setter }

SpecificationO EJB kapsamları ile açıklamalı değildir ve de bu şekilde kod değil EE çerçevesi tarafından başlatıldı beri sınıf, CDI olduğunu. Burada dikkat edilmesi gereken bir nokta, Specificationsınıfa Açıklamalar eklemediğimizden , varsayılan olarak açıklama ile Açıklamalı @Dependentolduğudur.

@Dependent  <- By default added 
class Specification { ... }

Further reading: Konsepti daha da netleştirecek olan Ejbs kapsam açıklaması ve CDI kapsam açıklaması arasında daha fazla çalışmanız gerekir.