Apabila melihat builder.Services.AddScoped<...>(), kita mungkin menganggap container akan menyelesaikan semua masalah reka bentuk. Ia memang memudahkan penyediaan dependency, tetapi ia tidak tahu sama ada service yang kita cipta mempunyai skop tugas yang masuk akal. Class dengan sebelas dependency masih sukar difahami walaupun semuanya berjaya disuntik.
Mulakan dengan sebab class itu wujud. Controller yang memerlukan service pembayaran dan logger mungkin jelas. Jika ia juga memerlukan lima repository, dua klien API dan pembina e-mel, barangkali aliran perniagaan perlu dipisahkan. Panduan Microsoft menyebut banyak dependency sebagai petanda class memegang terlalu banyak tanggungjawab.
Fahami lifetime sebelum memilihnya
Singleton hidup lebih lama dan perlu berhati-hati dengan state serta keselamatan thread. Scoped lazimnya terikat pada satu skop request dalam aplikasi web. Transient dicipta apabila diminta. Jangan memilih lifetime berdasarkan mana yang membuat ralat hilang. Jika singleton memegang dependency scoped, reka bentuk itu perlu disemak kerana hayatnya tidak sepadan.
Apabila mendaftarkan service baharu, tulis satu ujian kecil untuk memastikan ia boleh dicipta dalam skop yang dimaksudkan. Ralat lifetime kadangkala hanya muncul pada runtime. Jika service memerlukan terlalu banyak tetapan dan dependency untuk hidup, gunakan itu sebagai petunjuk untuk menyemak sempadan tugasnya.
Uji service dengan dependency yang boleh diganti atau dikawal. Jika satu ujian memerlukan seluruh aplikasi dan pangkalan data sebenar untuk menguji pengiraan kecil, sempadan class mungkin kurang jelas. DI membantu kita menyusun hubungan; disiplin reka bentuk tetap kerja manusia.