Haruskah pembuatan Unity Container dianggap sebagai operasi yang mahal karena berkaitan dengan sumber daya dan waktu?

Saya baru-baru ini mulai menggunakan Unity untuk injeksi ketergantungan di .net. Saya mendapat kesan bahwa Unity Container kemungkinan besar adalah anggota kelas tunggal atau statis. Saya melihat pengembang lain menggunakannya dalam penangan permintaan yang akan menerima banyak lalu lintas.

Apakah ada keajaiban yang terjadi sehingga biaya pembuatan Unity Container baru tetap rendah setiap saat, atau haruskah kode ini difaktorkan ulang agar hanya membuat container Unity satu kali?

Kode ini adalah bagian dari kelas implementasi Layanan .svc.

public string DoSomeWork(Request request)
{
   var container = new UnityContainer().LoadConfiguration("MyContainer");
   var handler = container.Resolve<RequestHandler>();
   return handler.Handle(request);
}

person ScArcher2    schedule 14.09.2011    source sumber
comment
Anda biasanya membuat wadah DI di root komposisi Anda. Bukan karena ini mahal, tapi hanya karena masuk akal dalam skema besar DI. Melakukan pengikatan di luar akar komposisi biasanya menghasilkan desain yang lebih buruk.   -  person Andrew Savinykh    schedule 15.09.2011
comment
Saya seharusnya mengklarifikasi bahwa kode ini digunakan untuk mengimplementasikan Layanan (file .svc). Saya tidak tahu apakah Unity bisa langsung digunakan sebagai bagian dari .svc.   -  person ScArcher2    schedule 15.09.2011


Jawaban (2)


Tidak 100% yakin dengan Unity, tetapi dengan sebagian besar container IoC, pembuatan container dan khususnya pemuatan konfigurasi container adalah operasi yang cukup mahal.

Saya harus mempertanyakan mengapa pengembang ini menggunakan wadah dengan cara ini. Idealnya, kontainer IoC tidak boleh berupa objek statis atau tunggal - kontainer tersebut harus dibuat hanya untuk menyelesaikan objek tingkat atas dari pohon ketergantungan Anda, dan objek lainnya dalam aplikasi Anda harus dibuat secara otomatis melalui injeksi ketergantungan. Dalam kasus contoh Anda, kelas yang berisi metode tersebut idealnya memiliki RequestHandler (idealnya antarmuka ini) yang disuntikkan ke dalamnya melalui konstruktor sehingga kelas tersebut tidak perlu mengetahui tentang wadah IoC.

person Paul Kirby    schedule 14.09.2011
comment
Saya seharusnya mengklarifikasi bahwa kode ini digunakan untuk mengimplementasikan Layanan (file .svc). Saya tidak tahu apakah Unity bisa langsung digunakan sebagai bagian dari .svc. - person ScArcher2; 15.09.2011

Ini bukan cara yang tepat untuk menggunakan wadah IOC - pada dasarnya Anda menggunakannya sebagai pencari layanan , tetapi ini akan menyebabkan ketergantungan pada wadah IOC tersebar di seluruh basis kode.

Apa yang harus Anda lakukan adalah memiliki satu titik pusat dalam basis kode Anda di mana semua dependensi diselesaikan dan kemudian menggunakan injeksi ketergantungan (DI) untuk menyebarkan kelas-kelas konkret yang diselesaikan ke bawah rantai, yaitu melalui injeksi konstruktor. Jadi kelas Anda seharusnya terlihat seperti ini:

public class Foo
{
    private readonly IRequestHandler _handler;

    public Foo(IRequestHandler handler)
    {
        _handler = handler;
    }

    public string DoSomeWork(Request request)
    {
        return _handler.Handle(request);
    }
}
person BrokenGlass    schedule 14.09.2011
comment
Saya seharusnya mengklarifikasi bahwa kode ini digunakan untuk mengimplementasikan Layanan (file .svc). Saya tidak tahu apakah Unity bisa langsung digunakan sebagai bagian dari .svc. - person ScArcher2; 15.09.2011