Bağımlılık Ekleme için Google Guice ve PicoContainer

Ekibim bağımlılık ekleme çerçevelerini araştırıyor ve Google-Guice ile PicoContainer arasında karar vermeye çalışıyor.

Çerçevemizde birkaç şey arıyoruz:

1. Küçük bir kod ayak izi - Küçük bir kod ayak izi ile demek istediğim, kod tabanımızın her yerinde bağımlılık enjeksiyon kodu çöpüne sahip olmak istemiyoruz. Yolda yeniden düzenleme yapmamız gerekirse, olabildiğince kolay olmasını isteriz.
2. Performans - Nesneleri oluştururken ve enjekte ederken her çerçevenin ne kadar ek yükü var?
3. Kullanım kolaylığı - Büyük bir öğrenme eğrisi var mı? Basit bir şeyin çalışmasını sağlamak için yığın kod yazmamız gerekiyor mu? Mümkün olduğunca az yapılandırmaya sahip olmak istiyoruz.
4. Topluluk boyutu - Daha büyük topluluklar, genellikle bir projenin korunmaya devam edeceği anlamına gelir. Bir çerçeve kullanmak istemiyoruz ve kendi hatalarımızı düzeltmek zorundayız;) Ayrıca yol boyunca sahip olduğumuz herhangi bir soru (umarız) çerçevenin geliştiricisi / kullanıcı topluluğu tarafından yanıtlanabilir.

İki çerçevenin listelenen kriterlere göre karşılaştırılması büyük ölçüde takdir edilecektir. İkisini karşılaştırmaya yardımcı olacak herhangi bir kişisel deneyim de son derece yardımcı olacaktır.

Sorumluluk reddi: Bağımlılık enjeksiyonu konusunda oldukça yeniyim, bu yüzden bu tartışmayla ilgili olmayan bir soru sorduğumda çaylaklığımı bağışlayın.

Spring'i, düşündüğünüz Bağımlılık Enjeksiyon çerçeveleri listenize dahil etmek isteyebilirsiniz. İşte sorularınıza bazı cevaplar:

Çerçeveye bağlantı

Pico - Pico, ayarlayıcı enjeksiyonunu engelleme eğilimindedir, ancak bunun dışında, sınıflarınızın Pico hakkında bilgi sahibi olmasına gerek yoktur. Bilmesi gereken yalnızca kablolamadır (tüm DI çerçeveleri için geçerlidir).

Guice - Guice artık standart JSR 330 açıklamalarını destekliyor , böylece artık kodunuzda Guice'e özgü ek açıklamalara ihtiyacınız yok. Bahar ayrıca bu standart açıklamaları destekler. Guice elemanlarının kullandığı argüman, bir Guice açıklama işlemcisi çalışmadan, farklı bir çerçeve kullanmaya karar verirseniz bunların bir etkisi olmayacağıdır.

İlkbahar - Bahar, kodunuzda Bahar çerçevesinden herhangi bir şekilde bahsetmemenizi sağlamayı amaçlar. Pek çok başka yardımcıları / araçları vb. Olduğundan, Bahar koduna bağlı olmak oldukça güçlüdür.

Verim

Pico - Pico'nun hız özelliklerine pek aşina değilim

Guice - Guice hızlı olacak şekilde tasarlanmıştır ve referansta bahsedilen karşılaştırmanın bazı rakamları vardır. Elbette, hız ya Guice kullanılarak ya da elle kablolama ile birincil husus ise, dikkate alınmalıdır.

İlkbahar - Bahar yavaş olabilir. Daha hızlı hale getirmek için çalışmalar yapıldı ve JavaConfig kitaplığını kullanmak işleri hızlandırmalı.

Kullanım kolaylığı

Pico - Yapılandırması basit. Pico sizin için bazı otomatik tel kararları verebilir. Çok büyük projelere nasıl ölçeklendiği belli değil.

Guice - Yapılandırması basit, sadece ek açıklamalar ekler ve nesneleri birbirine bağlamak için AbstractModule'dan miras alırsınız. Yapılandırma minimumda tutulduğundan büyük projelere iyi ölçeklenir.

Yay - Yapılandırması nispeten kolaydır, ancak çoğu örnek yapılandırma yöntemi olarak Spring XML'i kullanır. Spring XML dosyaları zamanla çok büyük ve karmaşık hale gelebilir ve yüklenmesi zaman alabilir. Bunun üstesinden gelmek için Yay ve elle çevrilen Bağımlılık Enjeksiyonunun bir karışımını kullanmayı düşünün.

Topluluk Boyutu

Pico - Küçük

Guice - Orta

İlkbahar - Büyük

Deneyim

Pico - Pico ile fazla deneyimim olmadı ama yaygın olarak kullanılan bir çerçeve değil, bu yüzden kaynak bulmak daha zor olacak.

Guice - Guice popüler bir çerçevedir ve hıza odaklanması, geliştirme aşamasında çok fazla yeniden başlattığınız büyük bir projeniz olduğunda memnuniyetle karşılanır. Yapılandırmanın dağıtılmış doğası hakkında bir endişem var, yani tüm uygulamamızın nasıl bir araya getirildiğini görmek kolay değil. Bu açıdan biraz AOP'ye benziyor.

İlkbahar - İlkbahar genellikle varsayılan seçimimdir. Bununla birlikte, XML hantal hale gelebilir ve sonuçta ortaya çıkan yavaşlama can sıkıcı olabilir. Sık sık el yapımı Dependency Injection ve Spring kombinasyonunu kullanıyorum. Aslında XML tabanlı yapılandırmaya ihtiyaç duyduğunuzda, Spring XML oldukça iyidir. Spring ayrıca diğer çerçeveleri daha Bağımlılık Enjeksiyonu dostu hale getirmek için çok çaba sarf etti, bu da yararlı olabilir çünkü bunu yaparken genellikle en iyi uygulamayı kullanırlar (JMS, ORM, OXM, MVC vb.).

Referanslar

• Pico
• Guice
• İlkbahar
• Yay / Guice / Pico karşılaştırması
• Başka bir Spring / Guice performans karşılaştırması

Jamie.mccrindle tarafından ortaya konan cevap aslında oldukça iyi, ancak üstün alternatiflerin (hem Pico hem de Guice) mevcut olduğu oldukça açıkken, Spring'in neden varsayılan seçim olduğu konusunda kafam karıştı. IMO Spring'in popülaritesi zirveye ulaştı ve şu anda üretilen hype ile yaşıyor (Spring bandwagonunu kullanmak isteyen diğer tüm diğer "ben de" Spring alt projeleri ile birlikte).

Baharın tek gerçek avantajı topluluk büyüklüğüdür (ve açıkçası, boyut ve karmaşıklık nedeniyle buna ihtiyaç vardır), ancak Pico ve Guice'nin çok büyük bir topluluğa ihtiyacı yoktur çünkü çözümleri çok daha temiz, daha organize ve daha zariftir. Pico, Guice'den daha esnek görünüyor (Pico'da ek açıklamaları kullanabilir veya kullanamazsınız - son derece etkilidir). (Düzenleme: Son derece esnek olduğunu söylemek anlamına gelir, aynı zamanda verimli olmadığı anlamına gelmez.)

Pico'nun küçük boyutu ve bağımlılık eksikliği, hafife alınmaması gereken BÜYÜK bir kazançtır. Şimdi Spring'i kullanmak için kaç mega indirmeniz gerekiyor? Bu, tüm bağımlılıkları ile birlikte büyük jar dosyalarının karışıklığı. Sezgisel olarak düşünürsek, böylesine verimli ve "küçük" bir çözüm, Spring gibi bir şeyden daha iyi ölçeklenmeli ve daha iyi performans göstermelidir. Baharın şişkinliği gerçekten daha iyi ölçeklenmesini sağlayacak mı? Bu tuhaf dünya mı? Bu kanıtlanana (ve açıklanana) kadar Baharın "daha ölçeklenebilir" olduğu varsayımlarında bulunmam.

Bazen iyi bir şey yaratmak (Pico / Guice) ve sonra sonsuz yeni sürümlerle şişkinlik ve mutfak lavabosu özellikleri eklemek yerine ELİNİZİ KAPALI tutmak gerçekten işe yarıyor ...

NOT: Bu bir cevaptan çok bir yorum / ranttır

PicoContainer harika. Web sitelerini düzeltselerdi ona geri dönerim. Şimdi gerçekten kafa karıştırıcı:

• En güncel olan http://picocontainer.com , ancak birçok sayfada biçimlendirme sorunları var ve birkaç sayfa hiç çalışmıyor. Görünüşe göre sayfalar eski içerikten otomatik olarak dönüştürülmüş.
• http://picocontainer.codehaus.org/ Bu, 2.10.2 sürümünde zaman içinde donmuş görünüyor - Sayfalarda "hey, eski bir web sitesine bakıyorsun!" gibi bir şey söylese çok güzel olurdu.
• http://docs.codehaus.org/display/PICO/Home - v 1.x'i belgeleyen bir izdiham wiki'si, ancak sayfaların hiçbir yerinde bunu söylemez!

Guice 2.x'i şimdi daha büyük olmasına ve daha az özelliğe sahip olmasına rağmen kullanıyorum. Belgeleri bulmak çok daha kolaydı ve kullanıcı grubu çok aktif. Bununla birlikte, Guice 3'ün yönü herhangi bir gösterge ise, tıpkı Spring'in ilk günlerde yaptığı gibi, Guice şişmeye başlıyor gibi görünüyor.

Güncelleme: Pico Container çalışanlarına bir yorum gönderdim ve web sitesinde bazı iyileştirmeler yaptılar. Şimdi daha iyi!

Bu eski bir soru ama bugün Android Uygulama projenizde Dagger'ı ( https://github.com/square/dagger ) düşünebilirsiniz . Dagger, derleme zamanında kod üretiyor. Böylece, daha kısa başlatma süresi ve yürütme süresinde daha az bellek kullanımı elde edersiniz.

Minimalist bir DI konteynerin peşindeyseniz, Feather'a göz atabilirsiniz . Vanilla JSR-330 DI işlevselliği yalnızca, ancak kapladığı alan (16K, bağımlılık yok) ve performans açısından oldukça iyi. Android üzerinde çalışır.

PicoContainer'ı basitliği ve bağımlılık eksikliği nedeniyle sevmeme rağmen. Bunun yerine CDI kullanmanızı tavsiye ederim çünkü Java EE standardının bir parçası olduğu için satıcıya bağımlı kalmazsınız.

Müdahalecilik açısından asıl sorun, bir konteyner gerekliliği ve nispeten boş bir META-INF /bean.xml dosyasının kullanılması (kavanozun CDI kullandığını belirtmek için gereklidir) ve ek açıklamaların kullanılmasıdır (standart olsa da )

Kendi projelerim için kullandığım hafif CDI konteyneri Apache Open Web Beans. Buna benzeyen basit bir uygulamanın (Pico'nun aksine) nasıl oluşturulacağını bulmak biraz zaman aldı.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}