Una volta ho avviato un progetto MVVM / WPF, che alla fine è stato costruito e distribuito, e per questo ho studiato molto Caliburn.Micro MVVM Framework. Il fatto è: ho finito per non usare Caliburn.Micro per questo e ho finito per implementare alcuni concetti MVVM da solo (in particolare, solo il ViewModelBase e RoutedCommand classes).
Ora sono stato assegnato a un progetto un po più grande sulla stessa linea: un ” Single-User Rich Client Offline Desktop Application “, per così dire, e ho deciso di utilizzare Caliburn.Micro. Ed è qui che inizia il mio ” problema “.
Ho letto in questo famoso post del blog , il cui titolo dice che ” Se” stai utilizzando MVVM, allora serve un framework “, che:
” Cercare di fare qualcosa come MVVM senza un framework è unenorme quantità di lavoro. Tantissimi codici duplicati, reinventare la ruota e riqualificare le persone a pensare in modo diverso .
Almeno con un framework in cui eviti il codice duplicato e, si spera, non devi reinventare la ruota, permettendoti di concentrarti sulla riqualificazione delle persone. La parte di riqualificazione è generalmente inevitabile, ma un framework fornisce il codice e la struttura dellimpianto idraulico, rendendo il processo più semplice. ”
Sono daccordo sulla prima lettura ma la mia effettiva esperienza con Caliburn.Micro (CM) nella mia effettiva applicazione è essere di incapacità e disorientamento. Cioè, il framework non ha reso il processo affatto più semplice, al contrario. Leggendo gli esempi sempre ripetuti forniti da Rob Eisenberg nella documentazione piuttosto (troppo) informale, e cercando di inferire modelli di utilizzo dai contorti esempi forniti, e le loro relazioni di classe e interfaccia totalmente indirette, dove le cose sembrano essere progettate per funzionare sulla base di effetti collaterali, sembrano umanamente impossibili a meno che tu non sia un genio esperto (scusa per lo sfogo, ma immagino tu lo sappia cosa intendo).
Per non parlare del fatto che qualsiasi scenario sopra banale sembra coinvolgere contenitori IoC, che è qualcosa con cui non ho mai lavorato e che sembra risolve un problema che forse non ho nemmeno . Non ho voglia di dedicare più ore al progetto a imparare queste cose invece di pensare al mio problema e ai domini dellapplicazione. Volevo solo una banana, ma CM mi ha dato un gorilla (IoC) con in mano un cesto di banane.
Ora che sto pensando di tornare al mio framework MVVM fatto in casa, composto solo dalla manciata di MVVM- classi specifiche che voglio effettivamente implementare – vorrei almeno dare a CM una possibilità, nel caso in cui sto perdendo qualcosa qui, o semplicemente facendo le cose ” nel modo sbagliato ” per pura inesperienza e ignoranza. Quindi la domanda è:
È opinione diffusa che i ” framework rendano le cose più semplici e naturali “, ma se mi capita di sperimentare il contrario, significa che non dovrei usare il framework o che sto cercando di impararlo nel modo sbagliato? Cè un indizio che non dovrei nemmeno usare un framework in primo luogo? Oppure esiste un ” corretto ” modo per capire come utilizzare CM per un semplice sviluppo MVVM?
Commenti
Answer
Ho provato CaliburnMicro e MVVMLight e quando uso Caliburn sento davvero quello che provi, certo che sembra davvero magico poter associare un controllo a una proprietà semplicemente usando Name = ” PropertyName ” invece del vecchio Text = ” {Bind PropertyName} ” ma alla fine Caliburn va fuori bordo per fare questa cosa magica . Quando qualcosa va storto è davvero difficile eseguire il debug e per peggiorare le cose hanno molti modi per fare una cosa.
Al contrario, MVVMLight è davvero scarno. Quando lo usi probabilmente ti rendi conto che è quasi al 100% come il tuo MVVM Framework, con alcune funzionalità sparse in esso.
So che questo non risponde alla tua domanda ” Come NON usare framework ” ma francamente non posso “t consigliarti di seguire quella strada. Penso che ti sei perso perché hai usato un framework completo invece di usarne uno semplice prima.
Commenti
- Pensi, allora, che dovrei almeno provare a utilizzare MVVMLight come una sorta di ” cure ” da ” Caliburn.Micro disorientation “? Sicuramente darei unocchiata se è così.
- @heltonbiker Sicuramente, provaci. È molto più semplice che dovrebbe almeno darti un buon punto dappoggio su MVVM Framework.
- Sono daccordo che ci sia troppa magia in corso. Proveniente da un background di c e assembly presumo. E qualcosa non ‘ funziona solo per scoprire che funziona a causa della magia in sottofondo. Impossibile eseguire il debug e quando si hanno problemi di prestazioni spesso non è molto facile risolverlo.
Risposta
È importante capire cosè MVVM. Non è una funzionalità condivisa che non è necessario reimplementare (analizzare un file JPEG o connettersi a un determinato server di database SQL), è un pattern – un pattern per come si può scegliere per implementare una ricca GUI. Quindi, se la tua implementazione del pattern è semplice e diretta, non penso che tu debba provare alcuna vergogna nellusarlo piuttosto che un framework.
In effetti, credo che lintera idea dei patterns-as-frameworks abbia andato troppo lontano. Perché qualsiasi cosa sia uno schema deve essere la forma generale di una classe di soluzioni. Poiché è così, è prevedibile che i modelli debbano essere adattati ai sistemi che li utilizzano e non è possibile farlo se si tenta di utilizzare un modello valido per tutti. Sarebbe molto più costruttivo lasciare limplementazione del pattern al progettista dellapplicazione e fornire librerie che incapsulino funzionalità, piuttosto che architettura.
Commenti
- Aggiunto a che, MVVM offerto da Microsoft (out of the box, WPF) manca molto. Molto frustrante anche per i programmatori che si considerano (e giustamente) come sviluppatori esperti. Stringhe magiche, eccezioni oscure in runtime, la maggior parte delle cose di base come lassociazione di un gruppo di radiobuttons a un enum assomiglia a stackoverflow.com/q/397556/168719 – cosa possono fare i framework? Devono riecheggiare questo livello di complessità o cercare di fornire unastrazione molto spessa su di esso
- @KonradMorawski WPF da solo non è MVVM; puoi eseguire il code behind con WPF, ma ‘ non è MVVM. Quindi, se vuoi fare WPF e MVVM, ‘ dovrai utilizzare un framework MVVM o implementarne uno tu stesso.
- @ Andy ovviamente, ma ‘ è sicuro di dire che WPF è inteso per MMVM.Mi ‘ mi riferisco alla funzionalità MVVM incorporata in WPF. So che puoi ancora creare codice
- @KonradMorawski Puoi usare WPF con MVVM e lhanno costruito pensando a questa possibilità, ma non cè NESSUNA funzionalità specifica MVVM incorporata in WPF. Proprio come puoi usare MVP con WinForms, ma WinForms non offre niente di specifico per usare quel pattern, dipende da te.
- @ Anddy forse ‘ stiamo discutendo definizioni ora. Quello che voglio dire è che tutto il ” colla ” che rende possibile MVVM è già presente: associazioni di dati in XAML,
DataContextecc.
Risposta
La mia prima esperienza con WPF è stata lutilizzo di Caliburn. Micro quindi questo è probabilmente abbastanza diverso dalla maggior parte degli sviluppatori. Ho trovato sia WPF che Caliburn.Micro una curva di apprendimento piuttosto ripida, provenendo da WinForms, tuttavia dopo alcune esperienze con entrambi ho trovato un piacere da usare in coppia. Attualmente lavoro in unaltra organizzazione in cui Caliburn.Micro non viene utilizzato, trovo che ci sia MOLTO codice idraulico duplicato che rende la base di codice piuttosto gonfia e inutilmente complessa.
Sono assolutamente daccordo che ci sono alcuni trucchi con Caliburn.Micro, che può complicare il debug, tuttavia una volta sperimentato è molto meno probabile che sia di nuovo un problema. La maggiore velocità di sviluppo, il codice più pulito e snello e il framework generale che incoraggia un migliore MVVM valgono più che valere la pena per me.
Caliburn.Micro inoltre non invalida il WPF di serie: si limita a costruire sopra di esso, il che significa che puoi ancora utilizzare le funzionalità WPF se lo desideri e utilizzare Caliburn per alcuni bit e pezzi se lo desideri. Questo è simile al modo in cui TypeScript e JavaScript coesistono nella mia mente.
Utilizzerei sicuramente Caliburn.Micro in qualsiasi nuovo progetto WPF su cui lavoro in futuro, se ne avessi la possibilità.
Commenti
- Grazie per la tua risposta. Due anni dopo, ho trovato molto più facile ” accettare ” questi framework dopo aver compreso il concetto di Dependency Injection Containers, che ho imparato dal eccellente Mark Seeman ‘ s ” DI in .NET ” libro.
Risposta
Per chiunque arrivi qui per la frustrazione con Caliburn.Micro, dai unocchiata a questo framework: Stylet
È ispirato a Caliburn.Micro, tranne per il fatto che rimuove gran parte della magia che ti lascia disorientato su ciò che sta accadendo. Inoltre, la documentazione è scritta in un linguaggio molto più semplice senza dare per scontato che si desideri guadare il gergo tecnico. Molto meglio per i principianti.
Inoltre, Stylet adotta un approccio ViewModel-First. Caliburn.Micro e molti altri framework adottano un approccio View-First, che presenta alcuni problemi imbarazzanti. Se sei già molto bravo con i principi SOLID e il codice modellato, probabilmente troverai un approccio ViewModel-First più naturale poiché assume la prospettiva che la tua logica debba guidare il sistema, non la vista.
EventAggregatorper la messaggistica eNotificationObjectper un ViewModelBase e MVVM Light ‘ sRelayCommandper i comandi. La cosa importante è identificare quali problemi il framework risolverà per te e utilizzare solo quelle soluzioni. Non ‘ ti senti come se ‘ fossi costretto a utilizzare lintera libreria del framework.RelayCommand(poiché ” associa ” direttamente ai metodi per convenzione, invece di associare alle proprietà ICommand).RelayCommandda unaltra libreria se quella usata da Caliburn Micro non funziona per te.