Mengapa kita membutuhkan kerangka kerja untuk injeksi ketergantungan? [Tutup]

42

Saya telah membaca lebih lanjut tentang prinsip Inversion of Control dan Dependency Injection sebagai implementasi dan saya yakin saya memahaminya.

Tampaknya pada dasarnya mengatakan 'jangan deklarasikan anggota kelas Anda' di dalam kelas '. Alih-alih bahwa instansiasi harus dilewatkan dan ditugaskan melalui konstruktor; 'disuntikkan' ke dalam kelas dari sumber luar.

Jika sesederhana ini, yang tampaknya seperti itu, mengapa kita membutuhkan kerangka kerja seperti pegas atau guice yang menerapkan ini dengan anotasi? Apakah saya melewatkan sesuatu yang mendasar di sini? Saya benar-benar berjuang untuk memahami apa penggunaan kerangka kerja Dependency Injection.

Sunting: Tentang kemungkinan duplikat, saya yakin pertanyaan saya lebih unik karena menanyakan tentang kerangka kerja DI secara umum, bukan hanya Spring. Spring bukan hanya kerangka DI, jadi ada banyak alasan bahwa seseorang ingin menggunakan Spring yang tidak terkait dengan DI.

— timsworth
sumber

Kemungkinan duplikat dari Apa yang dilakukan kerangka kerja Spring? Haruskah saya menggunakannya? Mengapa atau mengapa tidak?

— Agak

11

Mereka berguna untuk mengubah kesalahan menjadi runtime alih-alih waktu kompilasi.

— Den

1

@den Mengapa kita ingin melakukan itu? Itu tampaknya melanggar gagal dengan cepat

— PENGGUNA INI MEMBUTUHKAN BANTUAN

26

Kami tidak membutuhkan kerangka kerja. Sangat mungkin untuk menerapkan injeksi ketergantungan secara manual, bahkan untuk proyek yang relatif besar.

Di sisi lain, menggunakan kerangka kerja membuatnya lebih mudah, terutama yang didasarkan pada anotasi atau deteksi otomatis dependensi, karena membuat prosesnya lebih sederhana: jika saya memutuskan bahwa saya memerlukan dependensi baru di kelas, yang harus saya lakukan adalah menambahkan ke konstruktor (atau mendeklarasikan setter) dan objek disuntikkan - Saya tidak perlu mengubah kode Instansiasi.

Juga, kerangka kerja sering mengandung fungsi berguna lainnya. Spring, misalnya, berisi kerangka kerja yang berguna untuk pemrograman berorientasi aspek, termasuk demarkasi transaksi deklaratif (yang sangat praktis) dan berbagai implementasi adaptor yang membuat banyak perpustakaan pihak ke-3 lebih mudah untuk diintegrasikan.

— Jules
sumber

8

Memukul paku di kepala. Kami tidak membutuhkan mereka. Mereka hanya membuat hidup lebih mudah untuk proyek-proyek besar. Jujur, saya menemukan bahwa kerangka kerja lebih merepotkan daripada layak untuk proyek yang lebih kecil. Saya akan mendorong OP untuk tidak membingungkan Injeksi Ketergantungan dengan kerangka kerja yang mendukungnya.

— RubberDuck

1

kata baik. Dan mengapa menemukan kembali roda ketika orang lain telah membuat yang bagus dan bulat?

— jwenting

Tepat seperti itu. Kecuali saya tidak perlu mengubah kode Instansiasi - tentu saja, tidak ada kode Instansiasi ;-)

— Mathieu Guindon

Sepertinya perpustakaan DI Anda payah. Yang baik bisa menebak kelas untuk instantiate menggunakan refleksi.

— Florian Margaine

2

siapa pun yang menggunakan refleksi untuk pemrosesan runtime melakukan kesalahan. Refleksi adalah salah satu teknologi itu, hanya karena Anda dapat melakukan sesuatu tidak berarti Anda harus melakukannya.

— gbjbaanb

12

Mengapa kita perlu DI (Injeksi Ketergantungan) sama sekali?

Mekanisme DI memisahkan produksi objek dari konsumsi objek. Ketergantungan objek yang dibutuhkan dikirimkan secara transparan dari luar. Keuntungan dari mekanisme ini jelas: Anda dapat kapan saja menukar dependensi, mis. Menggunakan Obyek Null untuk tujuan pengujian.
Bagaimana ini dilakukan?

Ada beberapa cara untuk mencapai tujuan:
- Ketergantungan injeksi melalui injeksi konstruktor
- Injeksi melalui pengambil / penyetel
- Injeksi Antarmuka
Apakah kita membutuhkan kerangka kerja DI?

Tidak, tidak sama sekali. Anda cukup meneruskan semua instance ke objek lain secara manual. Jika Anda memiliki aplikasi kecil, tidak perlu wadah pegas.

Tetapi di sisi lain, kerangka memberi Anda uluran tangan, mengelola objek:
- Mereka membantu Anda menghubungkan hubungan objek yang kompleks. Anda harus menulis kode tanpa boilerplate, untuk menghasilkan instance dan meneruskannya ke objek yang sesuai
- Mereka membantu Anda mengontrol ketika suatu objek dibuat: Anda dapat membuat instance saat bootstrap aplikasi, tetapi dalam beberapa kasus penciptaan malas - hanya saat dibutuhkan - lebih baik
- Mereka membantu Anda mengontrol berapa banyak instance yang dibuat: satu per aplikasi seumur hidup atau satu per permintaan (jika Anda melakukan pemrograman web)

Jika proyek Anda memiliki ukuran yang sesuai - jika Anda merasa perlu untuk menulis lebih sedikit kode boilerplate - sangat masuk akal menggunakan kerangka kerja (DI-). Ada lebih banyak pro dan kontra.

— Thomas Junk
sumber

2

Anda dapat menggunakan perpustakaan DI tanpa menggunakan kerangka sama sekali.

— Florian Margaine

5

Dengan musim semi, sebagian besar masalah kenyamanan.

Jika Anda memiliki kelas TopLevelyang membangun kelas MiddleLevelyang membangun kelas LowLevel, dan Anda menyadari bahwa Anda memerlukan parameter konstruktor baru LowLevel, Anda juga harus menambahkannya ke TopLevel, dan untuk MiddleLevel, sederhananya sehingga ketika saatnya untuk MiddleLevelmembangun suatu LowLevelnilai akan tersedia sehingga dapat diteruskan ke konstruktornya. Dengan musim semi, Anda cukup menambahkan anotasi.

Juga, dengan pegas, dimungkinkan untuk menentukan dependensi dalam file konfigurasi eksternal, bukan xml, dan ini seharusnya memberi Anda kemampuan untuk menghasilkan sistem baru dengan kabel yang sama sekali berbeda "tanpa mengubah kode apa pun". (IMHO ini benar-benar salah arah, karena mengubah xml tidak jauh berbeda dengan mengubah kode, dan sebenarnya, kode biasanya memiliki pengecekan error dan mengetik yang jauh lebih baik daripada xml.)

Hal lain adalah banyak orang takut pada konstruktor; mereka tidak mengerti mereka, mereka tidak menyukainya, mereka lebih suka tidak menggunakannya.

— Mike Nakis
sumber

3

Sebagian besar setuju, terutama dengan komentar XML. IMHO, takut konstruktor mungkin merupakan alasan buruk untuk menggunakan kerangka kerja DI.

— Robert Harvey

2

IMHO, takut konstruktor adalah alasan bagus untuk menjauh dari pemrograman. C -: =

— Mike Nakis

5

Tapi bagaimana ini lebih menguntungkan daripada pabrik (statis atau sebaliknya)? (Yang memiliki keuntungan menjadi opsi yang dapat Anda gunakan sebagaimana mestinya sedangkan musim semi tampaknya merupakan urusan semua atau tidak sama sekali)

— Richard Tingle

@RichardTingle Spring dapat mewakili keuntungan sebagian besar karena semua hal lain yang dilakukannya selain DI, karena jelas, Anda dapat mencapai DI dengan banyak cara lain, pabrik statis menjadi satu. (Salah satu yang paling tidak keren, tapi tetap saja.) Tetapi pertanyaannya adalah apakah perlu menggunakan pegas untuk mencapai DI, dan itulah yang saya coba jawab: pada dasarnya, itu tidak perlu, hanya kenyamanan. .

— Mike Nakis

Ini adalah contoh dari apa yang bukan DI. ´TopLevel` seharusnya tidak membuat MiddleLevel, tetapi harus menerimanya saat membangun TopLevelsebagai argumen ke konstruktor. Demikian juga MiddleLevelharus menerima LowLeveldalam konstruktornya.

— jelas

1

Beberapa tahun yang lalu saya menulis sebuah program untuk memonitor halaman web, portlet web, bahkan tabel database tertentu, di perusahaan tempat saya bekerja. Saya ingin itu cukup fleksibel sehingga pengguna dapat menentukan monitor mana yang akan berjalan dan dengan parameter mana (url, login, kriteria keberhasilan, dll.). Jadi saya menulisnya untuk membaca dari file XML dan menggunakan Java refleksi untuk membuat instance kelas yang ditentukan dan menggunakan metode setter untuk mengatur parameter yang ditentukan.

Kemudian saya menemukan bahwa Spring akan melakukan hal yang sama untuk Anda, dan banyak lagi.

Jadi dalam kasus saya, saya menemukan itu

Menggunakan kerangka kerja injeksi ketergantungan membantu membuat program fleksibel dan membuatnya lebih mudah untuk menentukan bagaimana itu akan beroperasi (tentu saja dalam parameter yang didefinisikan dengan baik).
Menggunakan kerangka DI pihak ketiga membuat Anda tidak perlu menemukan kembali roda.

— Paul J Abernathy
sumber

4

Bisakah Anda menjelaskan lebih lanjut tentang mengapa mendefinisikan kelas konkret yang akan digunakan lebih baik di dalam xml daripada dalam file java. Itu hal yang saya tidak pernah mengerti.

— Richard Tingle

1

Ini bukan peluru ajaib, tetapi satu keuntungan menggunakan file konfigurasi adalah, setidaknya secara teori, mereka lebih mudah diedit daripada kode. Plus, mereka dapat diubah oleh pengguna yang menjalankan program Anda tetapi tidak memiliki akses ke kode sumber Anda. Dalam contoh yang saya berikan dari program injeksi ketergantungan kasar saya, saya kadang-kadang akan mengubah file konfigurasi XML sehingga saya bisa mengubah cara program berjalan meskipun saya adalah orang yang menulisnya. Jika Anda tidak memerlukan konfigurasi eksternal, akan lebih mudah melakukannya dengan kode. Saya memiliki pekerjaan lain di mana kami melakukan semua DI dalam kode dan itu bekerja dengan baik.

— Paul J Abernathy