public mstSparePartHandler(IMstSparePartDomain carDomain)
{
this._carSparePart = carDomain;
}
/// <summary>
/// Bingung. Ini constructor diisi dari mana? Bingung? pusing?
/// Dibawah ini, gue menggunakan yang namanya dependency injection. Pake Ninject
/// Lagi lagi, ini tuh design pattern.
/// Singkatnya gini, Sebenernya kalo nggak kepepet untuk business logic kita menghindari pemanggilan concrete class
/// Kenapa? Nih misal Andai kita punya custom logging tools yang inherit dari interface ILog (yang kayak dibawah ini)
/// Sejatinya gue saat ini membuat logging ke dalam database. makanya gue bikin class databaselogging inherit dari Ilog
/// Ninject membantu kita mencentralized settingan kalau gue tembak Ilog dari api controller secara otomatis yang kepanggil adalah class databaselogging
/// Jadi gue gak tergantung harus lempar class database logging buat ngelog activity
/// Nah pertanyaannya, andai kedepan database amit amit udah penuh. udah gak bisa insert data. Pasti ngelog ke database error juga kan?
/// Salah satu solusinya apa? kita bikin logging ke txtfile. Kita bikin class baru letsay txtlogging yang inherit Ilog.
/// Nah nanti di Ninject, kita tinggal ubah yang tadinya ILog ke database logging sekarang ILog ke txtLogging.
/// Once kita ubah di ninject. Semua langsung bahagia. Simple bukan?
/// </summary>
/// <param name="carDomain"></param>
/// <param name="spDomain"></param>
public TransactionController(IMstCarDomain carDomain, IMstSparePartDomain spDomain, IMstLogDomain logDomain)
{
_carDomain = carDomain;
_spDomain = spDomain;
_logDomain = logDomain;
}
public CarTransactionFacade(IUnitofWork uow, IMstCarDomain carDomain, IMstSparePartDomain SparePartDomain)
{
_uow = uow;
_carDomain = carDomain;
_SparePartDomain = SparePartDomain;
}
