Bagaimana Anda mengelola konfigurasi dengan injeksi ketergantungan?

Saya penggemar berat DI / IOC. Ini bagus untuk menangani / menghilangkan ketergantungan sulit, dan membuat hidup sedikit lebih mudah.

Namun saya memiliki keluhan kecil dengan itu, yang saya tidak yakin bagaimana menyelesaikannya.

Ide dasar dalam DI / IOC adalah bahwa ketika sebuah objek dipakai, semua dependensinya sudah diisi sebelumnya di dalam konstruktor.

Namun IMHO ada beberapa jenis parameter untuk konstruktor (terutama ketika objek Anda tidak dapat diubah).

Dependency (Objek yang diperlukan agar objek Anda bisa bekerja)
Konfigurasi (informasi tentang lingkungan yang diperlukan untuk melakukan pekerjaan)
Parameter (Data yang sedang dikerjakan)

Saya menemukan bahwa IOC berfungsi baik dengan dependensi. Tetapi saya masih berusaha mencari cara terbaik untuk berurusan dengan dua lainnya. Namun, karena konstruktor dijalankan dimaksudkan untuk dijalankan oleh wadah IOC, sepertinya saya perlu menempatkan barang-barang ini ke dalam wadah IOC.

Saya ingin tahu strategi / pola apa yang digunakan orang dan keuntungan serta kerugian apa yang ditemukan orang.

NB. Saya sadar ini adalah pertanyaan yang sangat subyektif, dan telah mencoba menjadikannya pertanyaan subyektif "baik" sesuai pedoman SE.

design-patterns configuration-management inversion-of-control

— ArT
sumber

Dengan "Konfigurasi" maksud Anda konfigurasi lingkungan-dev (seperti Pengembangan atau Produksi)? Jika demikian, saya biasanya mengatasinya sebagai Ketergantungan tradisional.

— MetaFight

Terbaik untuk membangun dengan dependensi tetapi konfigurasi default sehingga objek terbentuk dengan baik. Panggil metode tambahan untuk mengatur konfigurasi dan parameter lainnya. Melakukan terlalu banyak dalam aktor adalah hal yang buruk.

— david.pfx

I am still trying to work out the best way to deal with the other two- Mengirimnya sebagai parameter biasa ke objek Anda?

— Robert Harvey

@RobertHarvey benda abadi? Mereka membuat proses debug jauh lebih mudah.

— ArTs

Jawaban:

Konfigurasi (informasi tentang lingkungan yang diperlukan untuk melakukan pekerjaan)

Buat kelas konfigurasi (untuk pilih-pilih: antarmuka + implementasi) yang tujuannya adalah untuk memberikan informasi tentang lingkungan. Ini membuat konfigurasi sama sekali berbeda dari objek lain yang diperlukan agar objek Anda berfungsi (poin 1).

Parameter (Data yang sedang dikerjakan)

Dalam lingkungan yang berorientasi objek, tipe data primitif dapat dienkapsulasi dalam objek, jadi ini juga mengarah ke poin 1. Tetapi Anda mungkin akan menemukan pertanyaan SO ini menarik, ini berhubungan persis dengan situasi parameter primitif dalam konstruktor, saat menggunakan DI wadah. Dalam contoh yang diberikan, desain dapat ditingkatkan, yang menghindari kebutuhan untuk tipe primitif di konstruktor sepenuhnya.

— Doc Brown
sumber

Apa yang saya lakukan adalah pola pabrik untuk kasus ini.

Saya tidak menggunakan objek itu sendiri sebagai dependensi tetapi membuat objek pabrik dengan metode Dapatkan yang menerima parameter yang tidak dapat diikat secara otomatis oleh kontainer.

Ex.:

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }

— Vilém Procházka
sumber