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

Una volta ho avviato un progetto MVVM / WPF, che alla fine è stato creato e distribuito, e per questo ho studiato molto il framework Caliburn.Micro MVVM Framework. Il fatto è: ho finito per non usare Caliburn.Micro per quello, e ho finito per implementare alcuni concetti MVVM (in particolare, solo le classi ViewModelBasee RoutedCommand).

Ora sono stato assegnato a un progetto un po 'più grande seguendo le stesse linee: "Applicazione desktop offline Rich Client per utente singolo", per così dire, e ho deciso di utilizzare Caliburn.Micro. Ed è qui che inizia il mio "problema".

Ho letto in questo famoso post sul blog , il cui titolo dice che "Se stai usando MVVM allora hai bisogno di un framework", che:

"Cercare di fare qualcosa come MVVM senza un framework è un'enorme quantità di lavoro. Tonnellate di codice duplicato, reinventare la ruota e riqualificare le persone a pensare in modo diverso .

Almeno con un framework eviti il ​​codice duplicato e spero che non devi reinventare la ruota, permettendoti di concentrarti sulla riqualificazione delle persone. La parte di riqualificazione è generalmente inevitabile, ma un framework fornisce codice e struttura idraulica, rendendo più semplice il processo. "

Concordo sulla prima lettura, ma la mia esperienza reale con Caliburn.Micro (CM) nella mia attuale applicazione è stata di insicurezza e disorientamento. Cioè, il framework non ha affatto semplificato il processo, al contrario. Leggendo gli esempi sempre ripetuti forniti da Rob Eisenberg nella documentazione piuttosto (troppo) informale, e cercando di inferire i modelli di utilizzo dagli esempi forniti contorti, e le loro relazioni di classe e interfaccia totalmente indirette, in cui le cose sembrano progettate per funzionare in base a effetti collaterali, sembra umanamente impossibile a meno che tu non sia un genio esperto (scusami per l'ira, ma immagino che tu sappia cosa intendo).

Per non parlare del fatto che qualsiasi scenario sopra banale sembra coinvolgere i contenitori IoC, che è qualcosa con cui non ho mai lavorato e che sembra risolvere un problema che non potrei nemmeno avere . Non ho voglia di passare più ore di progetto a imparare queste cose invece di pensare al mio problema e ai domini dell'applicazione. Volevo solo una banana, ma CM mi ha regalato un gorilla (IoC) con in mano un cesto di banane.

Ora che sto pensando di tornare al mio framework MVVM homespun - composto solo da una manciata di classi specifiche MVVM che voglio implementare - vorrei almeno dare una possibilità a CM, nel caso in cui sto perdendo qualcosa qui, o semplicemente facendo le cose "nel modo sbagliato" per pura inesperienza e ignoranza. E quindi la domanda è:

Vi è un ampio consenso sul fatto che "i framework rendono 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 modo "giusto" per capire come utilizzare CM per un semplice sviluppo MVVM?

Ho provato CaliburnMicro e MVVMLight e quando uso Caliburn sento davvero quello che senti, sicuro che sia davvero magico poter legare il controllo alla proprietà semplicemente usando Name = "PropertyName" invece del vecchio Text = "{Bind PropertyName}" ma nel fine Caliburn si spinge oltre per fare questa cosa magica, quando qualcosa va storto è davvero difficile eseguire il debug, per peggiorare le cose hanno molto modo di fare una cosa.

Ma quando usi MVVMLight è sottile, quando lo usi probabilmente ti rendi conto che è quasi al 100% come il tuo MVVM Framework, con alcune caratteristiche sparse in esso.

So che questo non risponde alla tua domanda "Come NON usare il framework" ma francamente non posso raccomandarti di seguire questa strada perché è sbagliato, penso anche che ti sei perso perché usi il framework completo invece di usare semplici uno per primo.

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

In effetti, credo che l'intera idea di modelli come quadri sia andata troppo oltre. Perché qualsiasi cosa sia un modello, 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 adatto a tutti. Sarebbe molto più costruttivo lasciare l'implementazione del modello al progettista dell'applicazione e fornire librerie che incapsulino la funzionalità, piuttosto che l'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 essere una curva di apprendimento piuttosto ripida, proveniente da WinForms, tuttavia dopo qualche esperienza con entrambi ho trovato un piacere usarli come coppia. Attualmente sto lavorando in un'altra organizzazione in cui non viene utilizzato Caliburn.Micro. Trovo MOLTO codice duplicato dell'impianto idraulico che rende la base di codice piuttosto gonfia e inutilmente complessa.

Sono assolutamente d'accordo sul fatto che ci siano alcuni problemi con Caliburn.Micro, che può complicare il debugging, tuttavia una volta sperimentati hanno molte meno probabilità di essere di nuovo un dolore. La maggiore velocità di sviluppo, un codice più pulito e più snello e il quadro generale che incoraggia una MVVM migliore sono più che valsa la pena per me.

Caliburn.Micro inoltre non invalida il WPF stock, ma si basa solo su di esso, il che significa che puoi ancora utilizzare le funzionalità WPF se ti piace e utilizzare Caliburn per alcuni bit e pezzi se vuoi. Questo è simile a come TypeScript e JavaScript coesistono nella mia mente.

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

Per chiunque arrivi qui per frustrazione con Caliburn.Micro, dai un'occhiata a questo framework: 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 supporre che tu voglia superare 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 strutturato, è probabile che tu trovi un approccio ViewModel-First più naturale poiché considera la logica che dovrebbe guidare il sistema, non la vista.