Come scegliere di NON utilizzare un framework (Caliburn.Micro, ecc.) in una determinata applicazione MVVM?

Ho provato CaliburnMicro e MVVMLight e quando uso Caliburn sento davvero quello che senti, sicuro che è davvero magico in grado di legare il controllo alla proprietà usando semplicemente Name="PropertyName" invece di old Text="{Bind PropertyName}" ma alla fine Caliburn va troppo in mare per fare questa cosa magica, quando qualcosa va storto è davvero difficile fare il debug, per peggiorare le cose hanno un sacco di modi per fare una cosa.

Ma quando si usa MVVMLight è sottile, quando lo si utilizza ci si rende conto che è quasi al 100% come MVVM Framework, con alcune funzioni sparse in esso.

So che questo non risponde alla tua domanda "Come NON usare framework" ma francamente non posso raccomandarti di seguire questa strada perché è solo sbagliato, penso anche che ti sei perso perché usi la struttura Full featured di usare prima uno semplice.

È importante capire cos'è MVVM. Non è un po 'di funzionalità condivisa che non è necessario reimplementare (analizzare un file JPEG o connettersi a un determinato server di database SQL), è un modello - un modello per come si può scegliere implementare una ricca GUI. Quindi, se la tua implementazione del pattern è semplice e diretta, non penso che tu abbia bisogno di provare vergogna nell'usarlo piuttosto che in un framework.

In effetti, credo che l'intera idea di schemi come quadri sia andata troppo oltre. Perché qualsiasi cosa sia un modello deve essere la forma generale di una classe di soluzioni. Poiché è così, ci si può aspettare che i pattern debbano essere adattati ai sistemi che li usano e non è possibile farlo se si tenta di utilizzare un modello adatto a una sola misura. Sarebbe molto più costruttivo lasciare l'implementazione del pattern al progettista dell'applicazione e fornire librerie che incapsulino funzionalità, piuttosto che architettura.

La mia prima esperienza con WPF è stata l'utilizzo di Caliburn.Micro, quindi probabilmente è molto diverso dalla maggior parte degli sviluppatori. Ho trovato sia WPF che Caliburn.Micro come una curva di apprendimento piuttosto ripida, proveniente da WinForms, tuttavia, dopo una certa esperienza con entrambi, ho trovato loro un piacere da usare in coppia. Attualmente lavorando in una diversa organizzazione in cui Caliburn.Micro non viene utilizzato, trovo che ci sia un sacco di codice idraulico duplicato che rende la base di codice abbastanza gonfia e inutilmente complessa.

Sono assolutamente d'accordo sul fatto che ci sono alcuni trucchi con Caliburn.Micro, che può complicare il debug, tuttavia, una volta sperimentato, è molto meno probabile che si tratti di un dolore. L'aumento della velocità di sviluppo, il codice più pulito e snello e il quadro generale che incoraggia MVVM migliori sono più che validi per me.

Caliburn.Micro inoltre non invalida il WPF di riserva: si basa solo su di esso, il che significa che puoi ancora utilizzare le funzionalità di WPF, se lo desideri, e usare Caliburn per pochi bit se lo desideri. Questo è simile al modo in cui TypeScript e JavaScript coesistono insieme nella mia mente.

Sicuramente userò Caliburn.Micro in qualsiasi nuovo progetto WPF su cui lavoro in futuro, se ne avessi la possibilità.

Per chi arriva qui per frustrazione con Caliburn.Micro, dai uno sguardo a questo quadro: Stylet

È ispirato a Caliburn.Micro, tranne che rimuove molta della magia che ti lascia disorientato su ciò che sta accadendo. Inoltre, la documentazione è scritta in un linguaggio molto più semplice senza pensare che tu voglia approfondire 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 scomodi. Se sei già molto bravo con i principi SOLID e il codice con motivi, è probabile che tu possa trovare un approccio ViewModel-First più naturale dal momento che assume la prospettiva che la tua logica dovrebbe guidare il sistema, non la vista.