Aproape -mvc-abordare la punerea în aplicare a interfeței cu utilizatorul în Delphi

Pentru a face acest lucru, extind clasa TUser după cum urmează:

Am adăugat cel mai simplu eveniment de notificare către obiectul TUser, care ne va notifica despre schimbarea listei rolurilor angajaților. Metoda SetRoles de clasă TUser va lua următoarea formă:






Până la evenimentul OnChangeRoles tuser clasă nu suprascrisă (FOnChangeRoles implicit materie nulă), apel DoChangeRoles pur și simplu nu face nimic. Pentru a putea reacționa cumva la acest eveniment, trebuie să alocați un handler adecvat obiectelor TUser.
Acest handler este logic pentru a obține de la clasa de formular:

Acum trebuie să închidem acest handler de evenimente pe obiectele TUser:

Asta e tot și toate :). Acum, atunci când un obiect va declanșa schimbarea rolurilor OnChangeRoles de tratare a evenimentului alocat, care va provoca FillUserRoles și actualiza GUI (lista de rezerve de roluri). Cu aceste corecții, codul din articolul precedent va funcționa corect.

Ar putea fi făcut mai bine?

1) În contextul articolului precedent, am avut doar să reacționeze la schimbări în lista de roluri, așa că am început un eveniment specific, numai să facă față schimbărilor în rolurile de câmp clasa tuser. Adesea, trebuie să reacționați la schimbarea nu a unuia, ci a câtorva câmpuri ale obiectului. În acest caz, era mai bine să nu evenimentul în OnChangeRoles, ci pur și simplu onchange, adevărul și conductorul său în acest caz, nu trebuie numai reconstrui lista de roluri, dar, de asemenea, să actualizeze orice alte informații despre utilizator, care ar putea, la ora afișată în fereastra. Prin urmare, DoChange provocarea nu a fost doar SetRoles, precum și în alte domenii setterah tuser obiect, pe care schimbările pe care le-ar dori să monitorizeze. Și aici sarcina principală nu este de a uita să adăugați acest apel DoChange atunci când adăugați un câmp nou la obiect, deoarece o saruta destul de usor.
2) Pe baza principiilor programării sigure, dacă vom înregistra o tratare a evenimentului (cum se spune „abona“ în caz), trebuie să ne apoi eliminați ( „anulați“ acest handler abonament), adică întoarce OnChangeRoles la starea inițială sau cel mai rău în zero. Dacă este necesar să se efectueze această înregistrare, în fiecare caz se rezolvă individual. Mai întâi de toate, acest lucru depinde de raportul dintre durata de viață a obiectelor TUser și obiectul de formă. Dacă formularul trăiește mai mult decât TUser, atunci în principiu înregistrarea nu este necesară. Dacă, dimpotrivă, TUser poate mai trăi după distrugerea formularului, atunci, bineînțeles în OnDestroy, forma trebuie să scrie ceva în spirit

Dacă acest lucru nu se face, atunci când încercați să schimbați tuser obiect după distrugerea formei tuser poate încerca pentru a apela un handler eveniment care face referire la metoda a distrus deja obiectul (formă), iar cel mai bun caz, vom obține violare de acces.






3) Când lucrăm cu liste de obiecte, atribuirea unui handler fiecărui obiect nu este întotdeauna convenabilă. În cazul în care elementele din listă sunt conștienți de lista (de exemplu, se referă la ea prin Ownera), se poate face pentru a DoChange obiecte tuser pur și simplu numit Owner.DoChange, și evenimente personalizate (proprietate FOnChange) a fost aproape de lista (în TObjectLista). Deși acest lucru nu schimbă nimic în sensul său.

Notificări cu mai mulți abonați

Acest șablon este adesea folosit în aplicații MDI de înaltă calitate (și într-adevăr în orice aplicații cu mai multe ferestre). Șablonul este utilizat atunci când mai multe ferestre ale sistemului pot afișa aceleași date și dacă modificați aceste date printr-o singură fereastră, este necesar să le actualizați sincron în toate ferestrele. Cu toate acestea, aceste ferestre nu sunt neapărat instanțe ale aceleiași ferestre de clasă și nu au neapărat aceeași interfață de utilizator. Dimpotrivă, ferestrele pot fi complet diferite. Ele afișează numai aceleași informații. De exemplu, într-o fereastră este afișată o listă de angajați, iar în cealaltă - o carte a acestui angajat, unde puteți schimba unele dintre caracteristicile sale. În acest caz, este necesar ca, făcând clic pe butonul "Salvați" din cardul angajatului, datele vor fi actualizate atât în ​​cardul angajatului, cât și în lista generală a angajaților.
Șablonul pentru notificările multiple de conectare este util atunci când aveți un obiect de lungă durată. Durata sa de viață trebuie să fie cunoscută a fi mai mare decât durata de viață a obiectelor care se abonează la notificări din partea ei. Să presupunem că avem un manager de clasă responsabil pentru lucrul cu angajații (în special pentru salvarea modificărilor aduse obiectelor TUser din baza de date):

Cod pentru implementarea acestor metode:

Acum, că am înțeles cum va fi folosit acest lucru, vom reveni direct la momentul notificării, adică până la data evenimentului:

Blocarea răspunsului operatorilor

Codul de mai sus este bine, atâta timp cât sistemul nu apare o dată operațiunea pe un număr mare de obiecte. Poate nu cel mai bun exemplu: un grup de angajați a fost instruit și fiecare dintre ei a primit unele identice pentru toate certificatele. Am aloca 10 angajați din listă, faceți clic pe „Adăugați certificatul“. În continuare apar alternativ provocare UserMngr.Save pentru fiecare dintre aceste 10 de angajați. În acest caz, atunci când salvați fiecare angajat lucrează eveniment de modificare a DoUserChangeNotify, ceea ce duce la reconstrui lista de angajați în toate ferestrele deschise (și fiecare schimbare monetară va duce la mai multe reíncercări angajați din lista de baze de date sau de la serverul de aplicație). În final, salvați modificările la 10 angajați vor fi Sooooo încet și, în plus, avem o mulțime de flash-uri în ferestrele aplicației deschise (liste vor fi reconstruite timp de 10 de ori). Acum voi descrie o modalitate ușoară de a evita acest lucru:

În acest caz, se va schimba și metoda de notificare:

FLock monitorizează nivelul blocării (sunt permise apelurile imbricate BeginUpdate..EndUpdate). FChanged este un steag care ne permite să ne amintim dacă un eveniment a avut loc cel puțin o dată în timpul unei sesiuni de blocare. Dacă sa întâmplat, evenimentul va fi apelat automat în momentul ieșirii din sesiunea de blocare (adică în momentul apelului EndUpdate la cel mai înalt nivel).

Astfel, codul pentru schimbarea unui set de obiecte poate fi ușor protejat de evenimentele inutile:

O astfel de blocare este convenabil de utilizat în alte cazuri, de exemplu, atunci când doriți să transferați un obiect dintr-o stare în alta, schimbând nu unul, ci mai multe câmpuri. În acest caz, unele stări intermediare ale obiectului (unele combinații de valori de câmp) pot fi considerate inadmisibile din punctul de vedere al GUI. În consecință, nu ar trebui să permiteți GUI-ului să știe deloc că obiectul a trecut prin astfel de state. În acest caz, obiectul este, de asemenea, schimbat în sesiunea de actualizare, atunci când evenimentul care declanșează schimbarea acestui obiect este blocat.

Ai o zi frumoasă!







Trimiteți-le prietenilor: