Musíte si položit několik otázek.
Nechcete žádnou z vaší obchodní logiky na úrovni db? Zřejmě by to mohl udělat spouštěč db (provést nějakou akci, když se změní hodnota, i když pouze velmi konkrétní hodnota).
Viděl jsem některé systémy, které jsou db trigger heavy. Jejich „logika“ je hluboce a vysoce spojena s platformou db. To má určité výhody, ale většina lidí by pravděpodobně řekla, že nevýhody jsou příliš velké (spojování, nedostatek zapouzdření/znovupoužitelnosti).
V závislosti na tom, co děláte a na vašich sklonech, můžete:
-
Ujistěte se, že všechny objekty DAO/BusinessFunctoin volají vaši „událost“
object.functiondělat, co chcete, když dojde k určité změně hodnoty. -
Pomocí spouštěče zavolejte svou 'událost'
object.functionkdyž dojde k určité změně hodnoty. -
Vaše spoušť dělá všechno.
Osobně bych se přiklonil k možnosti 2, kde máte minimální spouštěč (který jednoduše spustí volání události vaší object.function ), takže svou db hluboce nespojíte s vaší obchodní logikou.
Možnost 1 je v pořádku, ale může to být trochu problém, pokud nemáte velmi úzkou sadu BF/DAO, které mluví s tímto polem db table.field, které chcete sledovat.
Možnost 3 je imho nejhorší volbou, protože spojíte logiku s vaší db a snížíte její dostupnost pro vaši vrstvu obchodní logiky.
Vzhledem k tomu zde uvádíme několik informací, jak toho dosáhnout prostřednictvím Možnosti 2:
Pomocí tohoto příkladu z MSDN:http://msdn.microsoft.com/en -us/library/938d9dz2.aspx .
Toto ukazuje, jak spustit spouštěč a volat objekt CLR v projektu.
Ve svém projektu efektivně vytvoříte spouštěč a necháte jej zavolat vaši třídu.
Všimněte si řádku:[SqlTrigger(Name="UserNameAudit", Target="Users", Event="FOR INSERT")]
Toto definuje, kdy se kód spustí, pak v rámci kódu můžete zkontrolovat své omezení a poté spustit zbytek metody (nebo ne) nebo zavolat jinou object.method podle potřeby.
Primární rozdíl mezi přechodem přímo do databáze a přidáním spouštěče je ten, že při společném nasazení získáte přístup ke všem objektům ve vašem projektu.