Ketergantungan inversi diterapkan dengan baik memberikan fleksibilitas dan stabilitas di tingkat seluruh arsitektur aplikasi Anda. Ini akan memungkinkan aplikasi Anda berkembang lebih aman dan stabil.
Arsitektur berlapis tradisional
Secara tradisional UI arsitektur berlapis tergantung pada lapisan bisnis dan ini pada gilirannya tergantung pada lapisan akses data.
Anda harus memahami layer, paket, atau pustaka. Mari kita lihat bagaimana kodenya.
Kami akan memiliki pustaka atau paket untuk lapisan akses data.
// DataAccessLayer.dll
public class ProductDAO {
}
Dan perpustakaan lain atau logika paket bisnis lapisan yang bergantung pada lapisan akses data.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private ProductDAO productDAO;
}
Arsitektur berlapis dengan inversi ketergantungan
Pembalikan ketergantungan menunjukkan hal berikut:
Modul tingkat tinggi seharusnya tidak bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi.
Abstraksi tidak harus bergantung pada detail. Detail harus bergantung pada abstraksi.
Apa saja modul tingkat tinggi dan tingkat rendah? Modul-modul berpikir seperti perpustakaan atau paket, modul tingkat tinggi adalah modul-modul yang secara tradisional memiliki dependensi dan level rendah di mana mereka bergantung.
Dengan kata lain, modul level tinggi akan menjadi tempat tindakan dipanggil dan tingkat rendah di mana tindakan dilakukan.
Kesimpulan yang masuk akal untuk ditarik dari prinsip ini adalah bahwa seharusnya tidak ada ketergantungan antar konkret, tetapi harus ada ketergantungan pada abstraksi. Tetapi menurut pendekatan yang kami ambil, kami dapat menyalahgunakan ketergantungan investasi, tetapi abstraksi.
Bayangkan kita mengadaptasi kode kita sebagai berikut:
Kami akan memiliki pustaka atau paket untuk lapisan akses data yang mendefinisikan abstraksi.
// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{
}
Dan perpustakaan lain atau logika paket bisnis lapisan yang bergantung pada lapisan akses data.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private IProductDAO productDAO;
}
Meskipun kami bergantung pada ketergantungan abstrak antara bisnis dan akses data tetap sama.
Untuk mendapatkan inversi dependensi, antarmuka persistensi harus didefinisikan dalam modul atau paket di mana logika atau domain tingkat tinggi ini dan tidak dalam modul tingkat rendah.
Pertama-tama tentukan apa lapisan domain itu dan abstraksi komunikasinya adalah kegigihan.
// Domain.dll
public interface IProductRepository;
using DataAccessLayer;
public class ProductBO {
private IProductRepository productRepository;
}
Setelah lapisan kegigihan tergantung pada domain, dapatkan untuk membalikkan sekarang jika ketergantungan ditentukan.
// Persistence.dll
public class ProductDAO : IProductRepository{
}
(sumber: xurxodev.com )
Memperdalam prinsip
Penting untuk mengasimilasi konsep dengan baik, memperdalam tujuan dan manfaat. Jika kita tinggal secara mekanis dan mempelajari repositori kasus tipikal, kita tidak akan dapat mengidentifikasi di mana kita dapat menerapkan prinsip ketergantungan.
Tetapi mengapa kita membalikkan ketergantungan? Apa tujuan utama di luar contoh spesifik?
Seperti umumnya memungkinkan hal-hal yang paling stabil, yang tidak tergantung pada hal-hal yang kurang stabil, berubah lebih sering.
Jenis persistensi lebih mudah diubah, baik basis data atau teknologi untuk mengakses basis data yang sama daripada logika domain atau tindakan yang dirancang untuk berkomunikasi dengan kegigihan. Karena itu, ketergantungan ini dibalik karena lebih mudah untuk mengubah kegigihan jika perubahan ini terjadi. Dengan cara ini kita tidak perlu mengubah domain. Lapisan domain adalah yang paling stabil, oleh karena itu ia tidak boleh bergantung pada apa pun.
Tetapi tidak hanya ada contoh repositori ini. Ada banyak skenario di mana prinsip ini berlaku dan ada arsitektur berdasarkan prinsip ini.
Ilmu bangunan
Ada arsitektur di mana inversi ketergantungan adalah kunci dari definisinya. Di semua domain itu adalah yang paling penting dan itu adalah abstraksi yang akan menunjukkan protokol komunikasi antara domain dan sisa paket atau pustaka didefinisikan.
Arsitektur Bersih
Dalam arsitektur bersih , domain terletak di tengah dan jika Anda melihat ke arah panah yang menunjukkan ketergantungan, jelas lapisan apa yang paling penting dan stabil. Lapisan luar dianggap alat yang tidak stabil jadi hindari tergantung padanya.
(sumber: 8thlight.com )
Arsitektur Heksagonal
Ini terjadi dengan cara yang sama dengan arsitektur heksagonal, di mana domain juga terletak di bagian tengah dan port adalah abstraksi komunikasi dari domino ke arah luar. Di sini sekali lagi terbukti bahwa domain adalah ketergantungan yang paling stabil dan tradisional dibalik.
