@ Pandakun se va plimba, dar personal aș trece în mod explicit acest parametru la apelarea metodei prezentatorului. În general, acolo aveți un amestec: evenimentele CellChanged în interfața de prezentare și abonamentul la acesta în prezentator nu ar trebui să fie. În schimb, adăugați metoda SavePlavka () la prezentator, unde treceți înregistrarea curentă (selectPlavka) la prezentator.
@andreycha "în modelul MVVM este datele în sine, <.> fără logică de afaceri "- un citat din descriere." MVVM este folosit pentru a separa modelul și reprezentarea sa <.> dezvoltatorul specifică logica de a lucra cu datele, iar designerul funcționează în consecință cu interfața cu utilizatorul "- adică modelul conține logica de afaceri.
@Este evident că l-am suprasolicitat cu termenul "logică de afaceri". Vreau să spun că atât prezentatorul, cât și modelul de vizualizare lucrează cu datele finalizate și includ logica reprezentării datelor, a validării și a altor aspecte strâns legate de interfață. Dar datele finite (model) vin de obicei (și se întorc) prin stratul, care include logica reală a afacerii. Deci, în acest sens, da, modelul include logica de afaceri.
@andreycha "aparent l-am suprasolicitat cu termenul" logica de afaceri "" - da, UI poate avea logica proprie, de exemplu, ca un grup de radiobuttons - una este activată, cealaltă este oprită. Și logica de afaceri este logica aplicației / sistemului, se dizolvă în tipuri / clase etc. Probabil, este necesar să reflectăm într-un fel diferitele logici din răspuns, astfel încât să nu existe confuzie.
@andreycha Din păcate, nu răspundeți la chat, trebuie să continuați să scrieți întrebări aici. Mă întorc la întrebarea ordinului []. pentru că Eu folosesc cadrul entității și abordarea Code First. atunci în cazul meu există o serie de clase care descriu structura mesei. Aceste clase folosesc ca tipuri particularizate care merg între Vizualizare<->Presente-> Model. Dar de ce ar trebui să clasific aceste clase? Este aceasta, de asemenea, parte a modelului, sau este mai mult un DAL?
@andreycha mă întorc la modelul evenimentului. La urma urmei, care, ca model, nu știe că sa schimbat. Că sunt inserate date sau șterse. Deci nu este logic ca modelul să raporteze că au avut loc schimbări în el și cine este interesat de toate acestea - de exemplu, controlorii ar fi înscriși la aceste evenimente și ar determina formularele adecvate pentru redesenarea datelor (actualizarea)?
@ andreycha Contează exact cum ar trebui să primească datele de la prezentator din model? De exemplu, modelul are o metodă Selectare. Pentru a obține date din modelul prezentatorului, puteți apela metoda Selectare. Și cum ar trebui această metodă să transfere date către prezentator? Prin repetare sau prin apel la metoda prezentatorului, contează?
Datele @MikhailDanshin sunt returnate prin returnare. În mod ideal, modelul nu cunoaște nimic despre prezentator.
@MikhailDanshin despre actualizări - puteți și așa. Deși în practica mea nu trebuia să implementez evenimente în model.
@ MikhailDanshin despre Ordin - în teorie este un obiect DAL. Dar pentru prezentator, el face parte din model, deoarece, ca de obicei, prezentatorul nu știe nimic despre lumea exterioară. Dar aceasta nu este o chestiune de principiu. De asemenea, puteți avea obiecte care sunt utilizate numai pentru afișare și sunt transferate în vizualizare. De exemplu, Ordinul este un obiect greu, din care trebuie să afișați o pereche de câmpuri. Puteți să o salvați într-o singură Ordonare, pe care o oferiți vizualizării. Dar toate acestea sunt opțiuni.
@andreycha Despre a reveni prin întoarcere. Nu te uita la această discuție la adresa en.stackoverflow.com/q/477689/194602. Aici am descris problema returnării unei valori și nu a primit încă un răspuns.
@andreycha Și puteți explica din nou de ce în prezentator această linie este privat readonly IOrdersModel model; Nu se poate lega rigid prezentatorul și modelul dacă mai trebuie să lucreze împreună și, prin urmare, să dezlănțuiască modelul și vizualizarea?
@ MikhailDanshin pentru testare: astfel încât în testele să puteți înlocui stub.
@andreycha Puteți dezvălui semnificația frazei "Transferați la prezentare un prezentator deja creat". În general, revenind la conversația despre "dezlănțuirea ideii și a modelului" vine un cerc vicios. Unul dintre scopurile implementării modelului MVP este de a facilita testarea automată a unităților. Dar se pare că dacă pun în aplicare toate regulile MVP (Passive View), atunci nu voi atinge scopul de a facilita testarea în nici un fel.
@MikhailDanshin 1) Ceva de genul: var presenter = MyPresenter nou (MyModel nou ()); forma var = noua MyForm (prezentator); 2) De ce nu faceți mai ușoară testarea? Scopul este de a testa logica ecranului, nu legat de interfață. Logica este pusă în prezentator - prezentatorul este testat. Este clar că din bug-uri pur UI'nyh nu veți scăpa de ea.
Trimiteți-le prietenilor: