Saya memiliki antarmuka yang disebut IContext. Untuk keperluan ini, tidak masalah apa yang dilakukannya kecuali yang berikut:
T GetService<T>();Apa yang dilakukan metode ini adalah melihat wadah DI aplikasi saat ini dan mencoba untuk menyelesaikan ketergantungan. Cukup standar menurut saya.
Dalam aplikasi ASP.NET MVC saya, konstruktor saya terlihat seperti ini.
protected MyControllerBase(IContext ctx)
{
TheContext = ctx;
SomeService = ctx.GetService<ISomeService>();
AnotherService = ctx.GetService<IAnotherService>();
}
Jadi daripada menambahkan beberapa parameter dalam konstruktor untuk setiap layanan (karena ini akan sangat mengganggu dan memakan waktu bagi pengembang untuk memperluas aplikasi) Saya menggunakan metode ini untuk mendapatkan layanan.
Sekarang, rasanya salah . Namun, cara saya saat ini membenarkannya di kepala saya adalah ini - saya bisa mengejeknya .
Saya bisa. Tidak akan sulit untuk mengejek IContextuntuk menguji Controller. Saya harus tetap:
public class MyMockContext : IContext
{
public T GetService<T>()
{
if (typeof(T) == typeof(ISomeService))
{
// return another mock, or concrete etc etc
}
// etc etc
}
}
Tapi seperti yang saya katakan, rasanya salah. Selamat datang di pikiran / penyalahgunaan.
public SomeClass(Context c). Kode ini cukup jelas, bukan? Ini menyatakan, that SomeClasstergantung pada a Context. Err, tapi tunggu, tidak! Itu hanya bergantung pada ketergantungan Xyang didapat dari Konteks. Itu berarti, setiap kali Anda membuat perubahan, Contextitu bisa pecah SomeObject, meskipun Anda hanya berubah Contexts Y. Tapi ya, Anda tahu Anda hanya berubah , jadi Ytidak Xapa SomeClass-apa. Tetapi menulis kode yang baik bukan tentang apa yang Anda ketahui tetapi apa yang diketahui karyawan baru ketika dia melihat kode Anda pertama kali.