Come sviluppatore .NET WPF quali sono le differenze chiave di cui dovrei essere a conoscenza quando lavoro con ASP.NET MVC? [chiuso]

Sono passato da MVC a MVVM e ho scoperto che la differenza principale è che con MVC ci si occupa di una singola richiesta da Controller a modello per visualizzare più volte, che è possibile trasformare in un'app di tipo a pagina singola con AJAX.

In MVVM, l'asincronia di dati / vista viene gestita tramite le proprietà che notificano qualsiasi cosa legata a loro che il valore è cambiato. Le tue viste possono aggiornarsi senza dover ripetere l'intera chiamata MVC e ridisegnare tutto, ma solo le proprietà interessate vengono ridisegnate per così dire.

Ho trovato che la natura asincrona di MVVM è favorevole su MVC. Il più grande ostacolo per me è stato cercare di aderire rigorosamente al pattern MVVM e non inserire il codice in View Code-Behind o rendere i modelli / VM consapevoli di qualsiasi Views ecc. Per i progetti più piccoli, non ha molta importanza.

Esempio semplificato:

MVC: $ utente invia la richiesta di accesso tramite controller, il controller crea una nuova vista con $ utente definito dal modello

Controller [$msg = Hello, $user!] => Model [$user = Bob] => View ["Hello, Bob!"]

MVVM: $ utente invia la richiesta di accesso attraverso la vista, visualizza la proprietà degli aggiornamenti del modello con $ utente definito dal modello, Proprietà notifica Visualizza che è stato modificato e Visualizza è aggiornato (senza dover ridisegnare o ripresentare l'intero processo)

ViewModel [$msg = Hello, $user!] => Model [$user = Bob] => View ["Hello, Bob!"]

È una bestia completamente diversa. WPF consiste nel legare ViewModel alle viste usando XAML. Ci sono framework (penso che Caliburn Micro sia quello che ho usato una volta) che aiutano a costruire automaticamente questo bridge, permettendoti così di riutilizzare più codice.

D'altra parte, ASP MVC sta usando un modello per i tuoi oggetti C #, ma una volta che la tua pagina è stata pubblicata, di solito hai bisogno di più programmazione sul lato client. Assegnagli un nome a JQuery, Knockout, AngularJs, ecc. In questo modo puoi creare associazioni per ciascun controllo, in base a ciò che fa XAML, ma con più potere a mio parere.

Man mano che si impara di più su come funziona il ciclo di richiesta / risposta http, credetemi, desidererete sempre più programmazione nel browser e meno sul lato ASP. Almeno questo è quello che mi è successo. Oggigiorno uso C # come applicazione console per servire / ricevere JSON, serializzare / deserializzare e leggere / scrivere nei database. Anche il tentativo di mettere la logica in viste ASP non mi attrae più. È normale che HTML sia perfetto per javascript senza la necessità di utilizzare il template del server.