Ioc / DI - Mengapa saya harus mereferensikan semua lapisan / rakitan di titik masuk aplikasi?

(Terkait dengan pertanyaan ini, EF4: Mengapa pembuatan proxy harus diaktifkan saat pemuatan lambat diaktifkan? ).

Saya baru mengenal DI, jadi bersabarlah. Saya memahami bahwa penampung bertanggung jawab untuk membuat instance semua jenis terdaftar saya tetapi untuk melakukannya diperlukan referensi ke semua DLL dalam solusi saya dan referensi mereka.

Jika saya tidak menggunakan DI container, saya tidak perlu mereferensikan library EntityFramework di aplikasi MVC3 saya, hanya layer bisnis saya, yang akan mereferensikan layer DAL / Repo saya.

Saya tahu bahwa pada akhirnya semua DLL disertakan dalam folder bin tetapi masalah saya harus merujuknya secara eksplisit melalui "tambahkan referensi" di VS agar dapat mempublikasikan WAP dengan semua file yang diperlukan.

Jika saya tidak menggunakan kontainer DI, saya tidak perlu mereferensikan pustaka EntityFramework di aplikasi MVC3 saya, hanya lapisan bisnis saya yang akan mereferensikan lapisan DAL / Repo saya.

Ya, itulah situasi yang saya hindari dengan susah payah :)

Dengan kode yang digabungkan erat, setiap pustaka mungkin hanya memiliki beberapa referensi, tetapi ini lagi-lagi memiliki referensi lain, membuat grafik dependensi yang dalam, seperti ini:

Karena grafik ketergantungan dalam, itu berarti bahwa sebagian besar perpustakaan menyeret sepanjang banyak dependensi lain - misalnya dalam diagram, Perpustakaan C menyeret bersama Perpustakaan H, Perpustakaan E, Perpustakaan J, Perpustakaan M, Perpustakaan K dan Perpustakaan N . Hal ini mempersulit penggunaan kembali setiap library secara terpisah dari yang lain - misalnya dalam pengujian unit .

Namun, dalam aplikasi yang digabungkan secara longgar, dengan memindahkan semua referensi ke Akar Komposisi , grafik ketergantungan menjadi sangat rata :

Seperti yang diilustrasikan oleh warna hijau, sekarang dimungkinkan untuk menggunakan kembali Library C tanpa menyeret dependensi yang tidak diinginkan.

Namun, semua yang dikatakan, dengan banyak Kontainer DI, Anda tidak perlu menambahkan referensi keras ke semua pustaka yang diperlukan. Sebagai gantinya, Anda dapat menggunakan pengikatan terlambat baik dalam bentuk pemindaian rakitan berbasis konvensi (lebih disukai) atau konfigurasi XML.

Namun, ketika Anda melakukannya, Anda harus ingat untuk menyalin rakitan ke folder bin aplikasi, karena itu tidak lagi terjadi secara otomatis. Secara pribadi, saya jarang menganggap upaya ekstra itu sepadan.

Versi yang lebih terperinci dari jawaban ini dapat ditemukan dalam kutipan dari buku saya Injeksi Ketergantungan, Prinsip, Praktik, Pola .

Jika saya tidak menggunakan kontainer DI, saya tidak perlu merujuk pustaka EntityFramework di aplikasi MVC3 saya

Bahkan saat menggunakan kontainer DI, Anda tidak harus membiarkan proyek MVC3 Anda mereferensikan EF, tetapi Anda (secara implisit) memilih untuk melakukan ini dengan mengimplementasikan Akar Komposisi (jalur startup tempat Anda membuat grafik objek) di dalam proyek MVC3 Anda. Jika Anda sangat ketat dalam melindungi batas arsitektur Anda menggunakan rakitan, Anda dapat memindahkan logika presentasi Anda ke proyek yang berbeda.

Saat Anda memindahkan semua logika terkait MVC (pengontrol, dll) dari proyek startup ke perpustakaan kelas, ini memungkinkan rakitan lapisan presentasi ini tetap terputus dari aplikasi lainnya. Proyek aplikasi web Anda sendiri akan menjadi shell yang sangat tipis dengan logika startup yang diperlukan. Proyek aplikasi web akan menjadi Akar Komposisi yang mereferensikan semua rakitan lainnya.

Mengekstrak logika presentasi ke pustaka kelas dapat mempersulit banyak hal saat bekerja dengan MVC. Akan lebih sulit untuk menghubungkan semuanya, karena pengontrol tidak ada dalam proyek startup (sementara tampilan, gambar, file css, kemungkinan besar harus tetap berada dalam proyek startup). Ini mungkin bisa dilakukan tetapi akan membutuhkan lebih banyak waktu untuk menyiapkan.

Karena kelemahannya, saya biasanya menyarankan untuk tetap menggunakan Akar Komposisi dalam proyek web. Banyak pengembang tidak ingin perakitan MVC mereka bergantung pada perakitan DAL, tetapi itu sebenarnya bukan masalah. Jangan lupa bahwa majelis adalah artefak penyebaran ; Anda membagi kode menjadi beberapa rakitan untuk memungkinkan kode diterapkan secara terpisah. Di sisi lain, lapisan arsitektur adalah artefak logis . Sangat mungkin (dan umum) untuk memiliki banyak lapisan dalam rakitan yang sama.

Dalam hal ini kita akan mendapatkan Composition Root (layer) dan Presentation Layer dalam proyek aplikasi web yang sama (sehingga dalam perakitan yang sama). Dan meskipun rakitan tersebut mereferensikan rakitan yang berisi DAL, Lapisan Presentasi masih tidak mereferensikan Lapisan Akses Data . Ini adalah perbedaan yang besar.

Tentu saja, ketika kita melakukan ini, kita kehilangan kemampuan kompilator untuk memeriksa aturan arsitektur ini pada waktu kompilasi, tetapi ini seharusnya tidak menjadi masalah. Kebanyakan aturan arsitektur sebenarnya tidak dapat diperiksa oleh kompiler dan selalu ada sesuatu yang masuk akal. Dan jika tidak ada akal sehat dalam tim Anda, Anda selalu dapat menggunakan tinjauan kode (yang harus selalu dilakukan oleh setiap tim oleh IMO). Anda juga dapat menggunakan alat seperti NDepend (yang bersifat komersial), yang membantu Anda memverifikasi aturan arsitektur Anda. Saat Anda mengintegrasikan NDepend dengan proses build Anda, ini dapat memperingatkan Anda ketika seseorang memeriksa kode yang melanggar aturan arsitektur tersebut.

Anda dapat membaca diskusi yang lebih terperinci tentang cara kerja Akar Komposisi di bab 4 buku saya Injeksi Ketergantungan, Prinsip, Praktik, Pola .

Jika saya tidak menggunakan kontainer DI, saya tidak perlu merujuk pustaka EntityFramework di aplikasi MVC3 saya, hanya lapisan bisnis saya yang akan mereferensikan lapisan DAL / Repo saya.

Anda dapat membuat proyek terpisah yang disebut "DependencyResolver". Dalam proyek ini Anda harus mereferensikan semua perpustakaan Anda.

Sekarang Lapisan UI tidak memerlukan NHibernate / EF atau perpustakaan lain yang tidak relevan dengan UI kecuali Castle Windsor untuk direferensikan.

Jika Anda ingin menyembunyikan Castle Windsor dan DependencyResolver dari lapisan UI Anda, Anda dapat menulis HttpModule yang memanggil barang-barang registri IoC.

Saya hanya punya contoh untuk StructureMap:

public class DependencyRegistrarModule : IHttpModule
{
    private static bool _dependenciesRegistered;
    private static readonly object Lock = new object();

    public void Init(HttpApplication context)
    {
        context.BeginRequest += (sender, args) => EnsureDependenciesRegistered();
    }

    public void Dispose() { }

    private static void EnsureDependenciesRegistered()
    {
        if (!_dependenciesRegistered)
        {
            lock (Lock)
            {
                if (!_dependenciesRegistered)
                {
                    ObjectFactory.ResetDefaults();

                    // Register all you dependencies here
                    ObjectFactory.Initialize(x => x.AddRegistry(new DependencyRegistry()));

                    new InitiailizeDefaultFactories().Configure();
                    _dependenciesRegistered = true;
                }
            }
        }
    }
}

public class InitiailizeDefaultFactories
{
    public void Configure()
    {
        StructureMapControllerFactory.GetController = type => ObjectFactory.GetInstance(type);
          ...
    }
 }

DefaultControllerFactory tidak menggunakan container IoC secara langsung, tetapi mendelegasikan ke metode container IoC.

public class StructureMapControllerFactory : DefaultControllerFactory
{
    public static Func<Type, object> GetController = type =>
    {
        throw new  InvalidOperationException("The dependency callback for the StructureMapControllerFactory is not configured!");
    };

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        if (controllerType == null)
        {
            return base.GetControllerInstance(requestContext, controllerType);
        }
        return GetController(controllerType) as Controller;
    }
}

The GetControllerdelegasi diatur dalam Registry StructureMap (di Windsor itu harus menjadi Installer).

• Ada ketergantungan: jika sebuah objek membuat instance objek lain.
• Tidak ada ketergantungan: jika suatu objek mengharapkan abstraksi (injeksi kontraktor, injeksi metode ...)
• Majelis Referensi (referensi dll, webservices ..) tidak bergantung pada konsep ketergantungan, karena untuk menyelesaikan abstraksi dan dapat menyusun kode, lapisan harus mereferensikannya.