Vă mulțumim pentru susținere

Declanșatoarele de evenimente bazate pe temporizator

În prezent, lucrez la un proiect cu cerințe specifice. O scurtă trecere în revistă a acestora este următoarea:

  • Datele sunt preluate de la serviciile web externe
  • Datele sunt stocate în SQL 2005
  • Datele sunt manipulate printr-un GUI web
  • Serviciul de ferestre care comunică cu serviciile web nu are legătură cu interfața web internă, cu excepția bazei de date.
  • Comunicarea cu serviciile web trebuie să fie bazată atât pe timp cât și declanșată prin intervenția utilizatorului pe interfața web.

Modelul curent (pre-pre-producție) pentru declanșarea comunicațiilor de servicii web este realizat printr-o tabelă de baze de date care stochează cererile de declanșare generate de intervenția manuală. Nu vreau cu adevărat să dispun de mai multe mecanisme de declanșare, dar aș dori să pot popula tabela de baze de date cu declanșatori în funcție de timpul apelului. După cum văd, există două modalități de a realiza acest lucru.

1) Adapt the trigger table to store two extra parameters. One being "Is this time-based or manually added?" and a nullable field to store the timing details (exact format to be determined). If it is a manaully created trigger, mark it as processed when the trigger has been fired, but not if it is a timed trigger.
or
2) Create a second windows service that creates the triggers on-the-fly at timed intervals.

Cea de-a doua opțiune pare a fi o fudge pentru mine, dar gestionarea opțiunii 1 ar putea deveni cu ușurință un coșmar de programare (cum știi dacă ultimul sondaj al mesei a returnat evenimentul pe care trebuie să îl tragă și cum îl oprești declanșarea din nou a sondajului următor)

Aș aprecia dacă cineva ar putea să scutească câteva minute pentru a-mi ajuta să decid care dintre aceste trasee (una dintre aceste două sau, eventual, a treia, una nelistată) să le ia.

0
adăugat editat

3 răspunsuri

Felul în care văd asta este acesta.

Aveți un serviciu Windows, care joacă rolul unui programator și în el există câteva clase care numesc pur și simplu serviciile web și pun datele în bazele dvs. de date.

Deci, puteți folosi aceste clase direct de la WebUI și puteți importa datele bazate pe declanșatorul WebUI.

Nu-mi place ideea de a stoca o acțiune generată de utilizator ca un semn (declanșator) în baza de date unde un serviciu o va sondaj (la un interval care nu este sub controlul utilizatorului) pentru a executa acea acțiune.

Puteți chiar să transformați întregul cod într-un exe pe care apoi îl puteți programa folosind Windows Scheduler. Și apelați același exe ori de câte ori utilizatorul declanșează acțiunea din interfața Web Web.

0
adăugat

@Vaibhav

Din păcate, arhitectura fizică a soluției nu va permite nici o comunicare directă între componente, cu excepția Web UI la baza de date, și baza de date pentru servicii (care poate apoi apel la serviciile web). Cu toate acestea, sunt de acord că reutilizarea clasei de comunicare ar fi ideală aici - nu pot să o fac în limitele afacerii noastre *

* Nu este întotdeauna modul în care o soluție "mai bună" din punct de vedere tehnic este împiedicată de factori externi?

0
adăugat

De ce să nu folosiți o lucrare SQL în locul serviciului Windows? Puteți încapsula toți db "declanșa" codul în Procedurile stocate. Apoi, interfața dvs. de utilizare și instrucțiunile SQL pot apela aceleași proceduri stocate și pot crea declanșatoarele în același mod, fie manual, fie într-un interval de timp.

0
adăugat