Am început odată un proiect MVVM / WPF, care a fost în cele din urmă construit și implementat, iar pentru asta am studiat o mulțime de cadru Caliburn.Micro MVVM. Faptul este că am ajuns să nu folosesc Caliburn.Micro pentru asta și am ajuns să implementez eu câteva concepte MVVM (mai exact, doar ViewModelBase și RoutedCommand clase).
Acum am fost repartizat la un proiect ceva mai mare pe aceeași linie: un ” single-user Rich Client Offline Desktop Application „, ca să spun așa, și am decis să folosesc Caliburn.Micro. Și acolo începe ” problema „.
Am citit în această celebră postare de blog , al cărei titlu spune că ” Dacă utilizați MVVM, atunci nevoie un cadru „, care:
” Încercarea de a face ceva de genul MVVM fără un cadru este o muncă imensă. Tone de cod duplicat, reinventând roata și reinstruind oamenii să gândească diferit .
Cel puțin cu un cadru pentru care evitați codul duplicat și, sperăm, nu trebuie să reinventați roata – permițându-vă să vă concentrați asupra recalificării oamenilor. Partea de recalificare este, în general, inevitabilă, dar un cadru asigură codul și structura de instalații, facilitând procesul. ”
Aș fi de acord cu prima lectură, dar experiența mea actuală cu Caliburn.Micro (CM) în aplicația mea actuală este lipsit de idei și dezorientare. Adică, cadrul nu a ușurat deloc procesul, ci chiar opusul. Citind exemplele mereu repetate furnizate de Rob Eisenberg în documentația destul de (prea) informală și încercând să deduc modele de utilizare din mostrele complicate furnizate, și relațiile lor de clasă și interfață complet indirecte, în care lucrurile par a fi concepute pentru a funcționa bazate pe efecte secundare, par uman imposibil dacă nu sunteți un geniu experimentat (îmi pare rău pentru răbdare, dar cred că știți ceea ce vreau să spun).
Ca să nu mai vorbim că orice scenariu deasupra banalului pare să implice containere IoC, lucru cu care nu am lucrat niciodată și care par să rezolv o problemă pe care s-ar putea să nu o am chiar . Nu am chef să petrec mai multe ore de proiect învățând acele lucruri în loc să mă gândesc la problema mea și la domeniile de aplicații. Voiam doar o banană, dar CM mi-a dat o gorilă (IoC) care ținea un coș de banane.
Acum, când mă gândesc să mă întorc la cadrul meu MVVM de la domiciliu – compus doar din mână de MVVM- clase specifice pe care de fapt vreau să le implementez – aș dori cel puțin să dau o șansă CM, în cazul în care pierd ceva aici sau pur și simplu fac lucruri ” în mod greșit ” din lipsă de experiență și ignoranță. Astfel, întrebarea este:
Există un consens larg conform căruia cadrele ” fac lucrurile mai ușoare și mai naturale „, dar dacă se întâmplă să experimentez exact contrariul, înseamnă că nu ar trebui să folosesc cadrul sau că încerc să îl învăț într-un mod greșit? Există un indiciu că nici măcar nu ar trebui să folosesc un cadru? Sau există un ” drept ” mod de a afla cum să folosiți CM pentru dezvoltarea simplă a MVVM?
Comentarii
Răspundeți
Am încercat CaliburnMicro și MVVMLight și când folosesc Caliburn, simt cu adevărat ceea ce simți, sigur că se simte cu adevărat magic capabil să lege un control de o proprietate doar folosind Name = ” PropertyName ” în loc de text vechi = ” {Bind PropertyName} ” dar în cele din urmă Caliburn merge mult peste bord pentru a face acest lucru magic . Când ceva nu merge bine, este foarte greu de depanat și, pentru a agrava lucrurile, au multe modalități de a face un singur lucru.
În schimb, MVVMLight este foarte subțire. Când îl utilizați, probabil că vă dați seama că este aproape 100% ca MVVM Framework, cu unele caracteristici presărate în el.
Știu că acest lucru nu vă răspunde la întrebare ” Cum NU se folosește cadrul ” dar, sincer, nu vă pot recomanda să mergeți pe acel traseu. Cred că tocmai te-ai pierdut pentru că ai folosit un cadru cu funcții complete în loc să folosești mai întâi unul simplu.
Comentarii
- Crezi, atunci, că ar trebui cel puțin să încerc să folosesc MVVMLight ca o anumită sorte de ” vindecare ” de la ” Caliburn.Micro dezorientare „? Aș arunca cu siguranță o privire dacă acesta este cazul.
- @heltonbiker Cu siguranță, dați o încercare. Este mult mai simplu, cel puțin ar trebui să vă oferiți un punct de sprijin bun în cadrul MVVM.
- Sunt de acord că există prea multă magie. Provenind dintr-un fundal c și asamblare presupun. Ceva a câștigat ‘ nu funcționează decât pentru a găsi că se întâmplă datorită magiei din fundal. Imposibil de depanat și atunci când aveți probleme de performanță, adesea nu puteți face cu ușurință.
Răspuns
Este important să vă dați seama ce este MVVM. Nu este o parte din funcționalitatea partajată pe care nu trebuie să o reimplementați (analizarea unui fișier JPEG sau conectarea la un anumit server de baze de date SQL), este un model – un model pentru modul în care se poate alege pentru a implementa un GUI bogat. Deci, dacă implementarea modelului dvs. este simplă și simplă, nu cred că trebuie să simțiți rușine în a-l folosi mai degrabă decât a unui cadru.
Într-adevăr, cred că întreaga idee de modele-ca-cadre are a mers mult prea departe. Pentru ca orice să fie un model, trebuie să fie forma generală a unei clase de soluții. Deoarece acest lucru este așa, este de așteptat ca modelele să fie adaptate la sistemele care le utilizează și nu puteți face acest lucru dacă încercați să utilizați un model unic. Ar fi mult mai constructiv să lăsați implementarea modelului proiectantului aplicației și să oferiți biblioteci care încapsulează funcționalitatea, mai degrabă decât arhitectura.
Comentarii
- Adăugat la că, MVVM oferit de Microsoft (din cutie, WPF) lipsește foarte mult. Foarte frustrant chiar și pentru programatorii care se gândesc la ei înșiși (și pe bună dreptate) ca dezvoltatori experimentați. Șiruri magice, excepții obscure în timpul rulării, lucruri de bază, cum ar fi legarea unui grup de butoane radio la o enum, arată ca stackoverflow.com/q/397556/168719 – ce pot face cadrele? Trebuie fie să facă ecou acestui nivel de complexitate, fie să încerce să ofere o abstracție foarte groasă peste el.
- @KonradMorawski WPF de la sine nu este MVVM; puteți face cod în urmă cu WPF, dar ‘ nu este MVVM. Deci, dacă doriți să faceți WPF și MVVM, ‘ va trebui să utilizați un framework MVVM sau să îl implementați singur.
- @Andy, desigur, dar ‘ este sigur să spunem că WPF este destinat pentru MMVM.Mă ‘ mă refer la funcționalitatea MVVM care vine încorporată cu WPF. Știu că poți face codul în spatele lui
- @KonradMorawski Poți folosi WPF cu MVVM și l-au construit având în vedere această posibilitate, dar nu există funcționalitate specifică MVVM încorporată în WPF. La fel cum puteți utiliza MVP cu WinForms, dar WinForms nu oferă nimic special pentru a utiliza acel model, depinde de dvs.
- @Andy poate că ‘ ne certăm definiții acum. Ce vreau să spun este că tot ” lipici ” care face posibil MVVM este deja acolo – legături de date în XAML,
DataContextetc.
Răspuns
Prima mea experiență cu WPF a fost utilizarea Caliburn. Micro, deci este probabil destul de diferit de majoritatea dezvoltatorilor. Am găsit atât WPF, cât și Caliburn.Micro sunt o curbă de învățare destul de abruptă, provenind de la WinForms, cu toate acestea, după o experiență cu ambele, le-am găsit o plăcere să le folosesc ca pereche. În prezent lucrez într-o altă organizație în care Caliburn.Micro nu este folosit. Constat că există o mulțime de coduri de instalații sanitare duplicate, ceea ce face ca baza de cod să fie destul de umflată și inutil de complexă.
Sunt de acord cu siguranță că există unele probleme cu Caliburn.Micro, care poate complica depanarea, cu toate acestea odată experimentate, acestea sunt mult mai puțin susceptibile de a fi din nou o durere. Viteza crescută de dezvoltare, codul mai curat și mai slab și cadrul general care încurajează un MVVM mai bun sunt mai mult decât merită pentru mine.
Caliburn.Micro, de asemenea, nu invalidează WPF stoc – se bazează doar pe acesta, ceea ce înseamnă că puteți utiliza în continuare funcții WPF dacă doriți și puteți utiliza Caliburn pentru câțiva biți dacă doriți. Acest lucru este similar cu modul în care TypeScript și JavaScript coexistă împreună în mintea mea.
Cu siguranță aș folosi Caliburn.Micro în orice nou proiect WPF la care voi lucra în viitor, dacă mi se va da ocazia.
Comentarii
- Vă mulțumim pentru răspuns. Doi ani mai târziu, am găsit mult mai ușor să ” să accept ” aceste cadre după ce am înțeles conceptul de containere de injecție pentru dependență, pe care l-am învățat din excelent Mark Seeman ‘ s ” DI în .NET ” carte.
Răspuns
Pentru oricine ajunge aici din frustrare cu Caliburn.Micro, aruncă o privire asupra acestui cadru: Stylet
Este inspirat de Caliburn.Micro, cu excepția faptului că elimină o mulțime de magie care te lasă dezorientat de ceea ce se întâmplă. În plus, documentația este scrisă într-un limbaj mult mai simplu, fără a presupune că doriți să vă plimbați prin jargonul tehnic. Mult mai bine pentru începători.
De asemenea, Stylet are o abordare ViewModel-First. Caliburn.Micro și multe alte cadre adoptă o abordare View-First, care vine cu unele probleme incomode. Dacă sunteți deja foarte priceput la principiile SOLID și la codul modelat, este probabil să găsiți o abordare ViewModel-First mai naturală, deoarece are în vedere că logica dvs. ar trebui să conducă sistemul – nu vizualizarea.
EventAggregatorpentru mesaje șiNotificationObjectpentru un ViewModelBase și MVVM Light ‘ sRelayCommandpentru comenzi. Important este să identificați ce probleme vă va rezolva cadrul și să utilizați doar acele soluții. Nu ‘ nu te simți de parcă ‘ ești forțat să folosești întreaga bibliotecă cadru.RelayCommand(deoarece ” leagă ” direct la metode prin convenție, în loc să se lege de proprietățile ICommand).RelayCommanddintr-o altă bibliotecă dacă cea utilizată de Caliburn Micro nu funcționează pentru dvs.