Rischi principali quando si utilizza ASP.NET MVC per la prima volta

Si prevede di utilizzare ASP.NET MVC su un progetto relativamente importante (per l'azienda). Il team di sviluppo comprende 4 sviluppatori e un responsabile tecnico. 2 degli sviluppatori e il capo tecnico hanno lavorato insieme in precedenza sul progetto WebForms di ASP.NET e sono fiduciosi nell'utilizzo di tale tecnologia.Rischi principali quando si utilizza ASP.NET MVC per la prima volta

Ci scaldiamo un po 'quando guardiamo indietro ad alcuni degli approcci utilizzati in alcuni dei nostri primi progetti WebForms (esempi includono l'uso eccessivo di UpdatePanels, la mancanza di conoscenza di controlli come ListView, ViewState gonfiato, ecc.).

È importante non guardare indietro a questo progetto tra un anno e rabbrividire ad alcuni dei nostri approcci MVC ASP.NET!

Sulla base dell'esperienza, qualcuno ha dei rischi chiave che possono citare quando si utilizza ASP.NET MVC per la prima volta?

Sto pensando a trucchi, lampadine che impiegano un po 'di tempo per andare avanti, parti del telaio che sentivi di combattere fino a quando non hai appreso un oggetto specifico, quel genere di cose.

fonte

2009-06-02 Richard Everett

Non è del tutto normale guardare indietro al tuo codice tra un anno e l'ora e rabbrividire a quello che hai scritto? In particolare una nuova struttura? A meno che i tuoi senior non abbiano familiarità con il pattern MVC, nessuno sarà lì per tenere la tua mano e aiutarti a scrivere codice fantastico la prima volta. –

@Chad - probabilmente hai ragione, sto solo cercando di minimizzare il fattore di rabbia che potremmo affrontare! –

I maggiori rischi che ho visto derivano da un ritorno a un mezzo senza stato.

Il post è scomparso. La maggior parte dei controlli server è sparita. Viewstate è andato. Il modello guidato dagli eventi è sparito.

Se i tuoi sviluppatori hanno utilizzato SOLO Webforms asp.net per creare siti e mai un'altra tecnologia web, hanno un sacco di apprendimento.

fonte

2009-06-02 21:26:31

Sono d'accordo sul fatto che potrebbe essere un sacco di apprendimento, ma è un buon apprendimento ;-) Unformamente molti sviluppatori di moduli web sanno molto poco del web, in molti casi meno di un tipico sviluppatore ASP classico, che almeno ha dovuto pensare abuot HTTP POST e GET anche se la maggior parte del codice è finito come spaghetti. Credo che sia salutare per i moduli Web che i ragazzi imparino a conoscere MVC poiché significa che impareranno cosa succede realmente in un'app web. Non sono d'accordo che si tratti di un ritorno a un mezzo senza stato. Il web è sempre stato un mezzo senza stato, è solo che le forme web nascondono il fatto in un modo piuttosto maldestro. –

Oh, totalmente. È un apprendimento molto buono, e qualcosa che è molto vantaggioso per qualsiasi sviluppatore, se non altro in realtà mostra loro come usare i dadi e bulloni di HTTP. Quando dico return, per troppe persone di webform, * è * stateful. Viewstate è goffo e brutto per chi lo sa, ma per troppi sviluppatori di asp.net è come funziona il web. –

I più grandi per me sono stati la comprensione del modello Binding e la possibilità di avere visualizzazioni digitate.

Proteggere adeguatamente i percorsi.

fonte

2009-06-02 21:23:02 nikmd23

Puoi aggiungere ulteriori dettagli? Model Binding: stai parlando di visualizzazioni fortemente tipizzate? Cosa intendi per proteggere i tuoi percorsi? –

Usa fortemente tipizzato Vista e creare un nuovo modello per ogni visualizzazione

ragione semplice: Che è quello di assicurarsi che il proprio modello è separted dalla tua vista. Se hai bisogno di fare il refactoring, rompi solo una parte. Quindi se hai una vista chiamata "Ultime notizie", dovresti avere un "LatestNewsViewModel". È quindi compito del controller ottenere i dati dall'attuale modello/database e creare un modello di vista che ha trasmesso alle viste. Inoltre, se si decide di aver bisogno di elementi aggiuntivi nella vista, non è necessario ridefinire l'intero livello di accesso ai dati, poiché è sufficiente modificare ViewModel e l'azione Controller che lo popola.

prestazioni

mi consiglia di check-out this slideshow su problemi di prestazioni e ottimizzazioni che possono avere un impatto enorme.

fonte

2009-06-02 21:25:28

Interessante slideshow nel link, grazie :) –

Ho avuto l'impressione che i tuoi modelli non dovrebbero "preoccuparsi" delle viste in cui vengono utilizzati (separazione delle preoccupazioni). Stai raccomandando due classi di modelli: quelli che rappresentano i "soli" dati e quelli specificamente adattati per l'uso nelle viste? –

Sì. Fondamentalmente avete le solite classi di modelli per occuparsi di leggere e scrivere dati nel database, ma anche di avere classi del modello separate per ogni vista, i cosiddetti View Models. Quei modelli di vista non fanno nulla, sono solo un insieme di proprietà e contengono esattamente i dati di cui ha bisogno la vista. Il controller parla quindi con il modello "normale" per ottenere esattamente i dati necessari, crea un'istanza del ViewModel appropriato e lo popola e quindi lo invia alla vista (fortemente tipizzata). All'inizio sembra eccessivo, ma in seguito risparmia il mal di testa. –

È possibile scaricare gratuitamente il numero eBook da Scotts Il blog di Guthrie offre una guida completa e approfondita su come creare un sito MVC ASP.NET da zero.

fonte

2009-06-02 21:25:53

Rischi principali quando si utilizza ASP.NET MVC per la prima volta

risposta

Problemi correlati