Google Guice vs. PicoContainer untuk Injeksi Ketergantungan

Tim saya sedang meneliti kerangka kerja injeksi ketergantungan dan mencoba memutuskan antara menggunakan Google-Guice dan PicoContainer.

Kami mencari beberapa hal dalam kerangka kami:

1. Jejak kode kecil - Yang saya maksud dengan jejak kode kecil adalah kita tidak ingin memiliki sampah kode injeksi ketergantungan di mana-mana di basis kode kita. Jika kami perlu melakukan refaktorisasi di masa mendatang, kami ingin membuatnya semudah mungkin.
2. Performa - Berapa banyak overhead yang dimiliki setiap framework saat membuat dan memasukkan objek?
3. Kemudahan penggunaan - Apakah ada kurva belajar yang besar? Apakah kita harus menulis gundukan kode untuk membuat sesuatu yang sederhana bekerja? Kami ingin memiliki konfigurasi sesedikit mungkin.
4. Ukuran komunitas - Komunitas yang lebih besar biasanya berarti bahwa sebuah proyek akan terus dipertahankan. Kami tidak ingin menggunakan kerangka kerja dan harus memperbaiki bug kami sendiri;) Juga pertanyaan apa pun yang kami miliki selama ini dapat (mudah-mudahan) dijawab oleh komunitas pengembang / pengguna kerangka.

Perbandingan kedua kerangka kerja terhadap kriteria yang terdaftar akan sangat dihargai. Pengalaman pribadi apa pun yang membantu membandingkan keduanya juga akan sangat membantu.

Penafian: Saya cukup baru dalam injeksi ketergantungan jadi maafkan noob-ness saya jika saya mengajukan pertanyaan yang tidak berhubungan dengan diskusi ini.

Anda mungkin ingin memasukkan Spring dalam daftar framework Injeksi Ketergantungan yang sedang Anda pertimbangkan. Berikut beberapa jawaban atas pertanyaan Anda:

Kopling ke rangka

Pico - Pico cenderung melarang setter injection tetapi selain itu, kelas Anda tidak perlu tahu tentang Pico. Hanya kabel yang perlu diketahui (berlaku untuk semua kerangka DI).

Guice - Guice sekarang mendukung anotasi JSR 330 standar , jadi Anda tidak memerlukan anotasi khusus Guice dalam kode Anda lagi. Spring juga mendukung anotasi standar ini. Argumen yang digunakan orang-orang Guice adalah bahwa tanpa prosesor anotasi Guice yang berjalan, ini seharusnya tidak berdampak jika Anda memutuskan untuk menggunakan kerangka kerja yang berbeda.

Spring - Spring bertujuan untuk memungkinkan Anda menghindari penyebutan framework Spring dalam kode Anda. Karena mereka memiliki banyak pembantu / utilitas lain dll. Godaannya cukup kuat untuk bergantung pada kode Spring.

Performa

Pico - Saya tidak terlalu paham dengan karakteristik kecepatan Pico

Guice - Guice dirancang untuk menjadi cepat dan perbandingan yang disebutkan dalam referensi memiliki beberapa angka. Tentunya jika kecepatan adalah pertimbangan utama baik menggunakan Guice atau kabel dengan tangan harus dipertimbangkan

Musim Semi - Musim semi bisa jadi lambat. Ada pekerjaan untuk membuatnya lebih cepat dan menggunakan pustaka JavaConfig harus mempercepat segalanya.

Kemudahan penggunaan

Pico - Mudah dikonfigurasi. Pico dapat membuat keputusan autowire untuk Anda. Tidak jelas bagaimana skala proyek ini sangat besar.

Guice - Mudah dikonfigurasi, Anda cukup menambahkan anotasi dan mewarisi dari AbstractModule untuk menyatukan semuanya. Menskalakan dengan baik ke project besar karena konfigurasi dijaga seminimal mungkin.

Spring - Relatif mudah dikonfigurasi, tetapi kebanyakan contoh menggunakan Spring XML sebagai metode konfigurasi. File Spring XML bisa menjadi sangat besar dan kompleks dari waktu ke waktu dan membutuhkan waktu untuk dimuat. Pertimbangkan untuk menggunakan campuran Pegas dan Injeksi Ketergantungan engkol tangan untuk mengatasi hal ini.

Ukuran Komunitas

Pico - Kecil

Guice - Medium

Musim Semi - Besar

Pengalaman

Pico - Saya belum memiliki banyak pengalaman dengan Pico tetapi ini bukan kerangka kerja yang banyak digunakan sehingga akan lebih sulit menemukan sumber daya.

Guice - Guice adalah kerangka kerja yang populer dan fokusnya pada kecepatan diterima ketika Anda memiliki proyek besar yang banyak Anda mulai ulang dalam pengembangan. Saya memiliki kekhawatiran tentang sifat terdistribusi dari konfigurasi, yaitu tidak mudah untuk melihat bagaimana seluruh aplikasi kita disatukan. Ini agak seperti AOP dalam hal ini.

Musim Semi - Musim semi biasanya adalah pilihan default saya. Konon, XML bisa menjadi tidak praktis dan perlambatan yang dihasilkan mengganggu. Saya sering berakhir menggunakan kombinasi Injeksi Ketergantungan dan Pegas buatan tangan. Ketika Anda benar-benar membutuhkan konfigurasi berbasis XML, Spring XML cukup bagus. Spring juga berupaya keras untuk membuat kerangka kerja lain lebih ramah Injeksi Ketergantungan yang dapat berguna karena mereka sering menggunakan praktik terbaik saat melakukannya (JMS, ORM, OXM, MVC, dll.).

Referensi

• Pico
• Guice
• Musim semi
• Perbandingan Musim Semi / Guice / Pico
• Perbandingan performa Spring / Guice lainnya

Jawaban yang diberikan oleh jamie.mccrindle sebenarnya cukup bagus, tetapi saya bingung mengapa Spring adalah pilihan default ketika cukup jelas bahwa alternatif unggulan (Pico dan Guice) tersedia. Popularitas IMO Spring telah mencapai puncaknya dan sekarang sedang menjalani hype yang dihasilkan (bersama dengan semua sub proyek "saya juga" Spring lainnya yang ingin mengikuti kereta musik Spring).

Satu-satunya keuntungan nyata Spring adalah ukuran komunitas (dan sejujurnya, karena ukuran dan kerumitannya, diperlukan), tetapi Pico dan Guice tidak membutuhkan komunitas yang besar karena solusi mereka jauh lebih bersih, lebih teratur, dan lebih elegan. Pico tampaknya lebih fleksibel daripada Guice (Anda dapat menggunakan anotasi di Pico, atau tidak - ini sangat efisien). (Sunting: Dimaksudkan untuk mengatakan itu sangat fleksibel, bukannya tidak juga efisien.)

Ukuran kecil Pico dan kurangnya ketergantungan adalah kemenangan BESAR yang tidak boleh diremehkan. Berapa MB yang perlu Anda unduh untuk menggunakan Spring sekarang? Ini adalah kekacauan file jar yang besar, dengan semua dependensinya. Berpikir secara intuitif, solusi yang efisien dan "kecil" seperti itu harus berskala dan bekerja lebih baik daripada sesuatu seperti Spring. Apakah Spring's bloat benar-benar akan membuatnya lebih baik? Apakah ini dunia yang aneh? Saya tidak akan membuat asumsi bahwa Spring "lebih terukur" sampai itu terbukti (dan dijelaskan).

Kadang-kadang membuat sesuatu yang baik (Pico / Guice) dan kemudian MENONAKTIFKAN TANGAN Anda daripada menambahkan fitur mengasapi dan wastafel dapur dengan versi baru yang tak ada habisnya benar-benar berhasil ...

CATATAN: Ini lebih merupakan komentar / kata-kata kasar daripada jawaban

PicoContainer sangat bagus. Saya akan beralih kembali ke sana jika mereka hanya memperbaiki situs web mereka. Ini sangat membingungkan sekarang:

• http://picocontainer.com yang merupakan yang terbaru, tetapi banyak halaman memiliki masalah pemformatan dan beberapa halaman tidak berfungsi sama sekali. Sepertinya halaman diubah secara otomatis dari konten yang lebih lama.
• http://picocontainer.codehaus.org/ Yang tampaknya terhenti pada waktunya pada versi 2.10.2 - Memang sangat menyenangkan jika halaman mengatakan sesuatu seperti "hei, Anda sedang melihat situs web lama!"
• http://docs.codehaus.org/display/PICO/Home - Wiki pertemuan yang mendokumentasikan v 1.x, tetapi tidak mengatakannya di mana pun di halaman!

Saya menggunakan Guice 2.x sekarang, meskipun lebih besar, dan fiturnya lebih sedikit. Jauh lebih mudah untuk menemukan dokumentasinya, dan grup penggunanya sangat aktif. Namun, jika arah Guice 3 adalah indikasi, sepertinya Guice mulai membengkak, seperti yang dilakukan Spring di masa lalu.

Pembaruan: Saya memposting komentar ke orang-orang Pico Container dan mereka telah membuat beberapa perbaikan pada situs web. Sekarang lebih baik!

Ini adalah pertanyaan lama tetapi hari ini Anda dapat mempertimbangkan Dagger ( https://github.com/square/dagger ) di proyek Aplikasi Android Anda. Dagger melakukan pembuatan kode pada waktu kompilasi. Jadi, Anda mendapatkan waktu startup yang lebih pendek dan penggunaan memori yang lebih sedikit pada waktu eksekusi.

Jika Anda menginginkan wadah DI minimalis, Anda dapat melihat Feather . Vanilla JSR-330 DI fungsionalitasnya saja, tapi cukup baik dari segi footprint (16K, tidak ada dependensi) dan performanya. Bekerja di android.

Meskipun saya suka PicoContainer karena kesederhanaannya dan kurangnya ketergantungan. Saya akan merekomendasikan menggunakan CDI sebagai gantinya karena ini adalah bagian dari standar Java EE sehingga Anda tidak memiliki vendor lock-in.

Dalam hal gangguan, masalah utamanya adalah persyaratan wadah dan penggunaan file META-INF / beans.xml yang relatif kosong (diperlukan untuk menunjukkan bahwa jar menggunakan CDI) dan penggunaan anotasi (meskipun standar )

Wadah CDI ringan yang saya gunakan untuk proyek saya sendiri adalah Apache Open Web Beans. Meskipun butuh beberapa saat untuk mengetahui cara membuat aplikasi sederhana (tidak seperti Pico) yang terlihat seperti ini.

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();
}