•  01-07-2019
  •  | 
  •  

Domanda

Quando ho sentito parlare per la prima volta di StackOverflow e ho sentito che era stato creato in ASP.Net MVC, ero un po' confuso.Pensavo che ASP.Net fosse sempre un esempio di architettura MVC.Hai la pagina .aspx che fornisce la vista, la pagina .aspx.vb che fornisce il controller e puoi creare un'altra classe che funga da modello.Il processo per utilizzare MVC in ASP.Net è descritto in questo Articolo Microsoft.

Quindi la mia domanda è.Cosa fornisce ASP.Net MVC che non saresti in grado di fare con ASP.Net normale (anche fino a ASP.Net 1.1)?Sono solo URL fantasiosi?È solo per vantarsi che MS possa confrontarsi con le nuove tecnologie come Ruby On Rails e dire: "Possiamo farlo anche noi"?C'è qualcosa in più fornito effettivamente da ASP.Net MVC, piuttosto che un paio di modelli aggiuntivi nel menu File->Nuovo?

Probabilmente sembro davvero scettico e negativo in questo momento, quindi mi fermo.Ma voglio davvero sapere cosa fornisce effettivamente ASP.Net MVC.Inoltre, se qualcuno può dirmi perché è Model-View-Controller e non nell'ordine degli strati di View-Controller-Model o Model-Control-View a seconda che tu stia andando dall'alto verso il basso o viceversa, lo farei apprezzo davvero anche quello.

MODIFICARE

Inoltre, probabilmente vale la pena sottolineare che non mi è mai interessato nemmeno il modello dei moduli Web (controlli server AKA).L'ho usato pochissimo e mai sul lavoro.

È stato utile?

Soluzione

.aspx non soddisfa il modello MVC perché la pagina aspx (la "visualizzazione") viene chiamata prima del code-behind (il "controller").

Ciò significa che il controller ha una "forte dipendenza" dalla vista, il che è decisamente contrario ai principi MVC.

Uno dei vantaggi principali di MVC è che ti consente di testare il tuo controller (che contiene molta logica) senza istanziare una vista reale.Semplicemente non puoi farlo nel mondo .aspx.

Testare il controller da solo è molto più veloce che dover creare un'istanza di un'intera pipeline asp.net (applicazione, richiesta, risposta, stato di visualizzazione, stato di sessione, ecc.).

Altri suggerimenti

Scott Guthrie lo ha spiegato in questo post”ASP.NET MVC Framework"

  • Abilita la separazione pulita di preoccupazioni, testabilità e TDD per impostazione predefinita.Tutti i contratti principali all'interno del framework MVC sono basati sull'interfaccia e facilmente modellabili (include IHTTPREQUEST/IHTTPRESCONSE IHTTPREQUEST BASATA/IHTTTPRESCONSE).È possibile testare unità l'applicazione senza dover eseguire i controller all'interno di un processo ASP.NET (rendendo rapidamente il test unitario).È possibile utilizzare qualsiasi framework di test unitari che desideri questo test (inclusi NUNIT, MBUnit, MS Test, ecc.).

  • È altamente estensibile e collegabile.Tutto nel framework MVC è progettato in modo che possa essere facilmente sostituito/personalizzato (ad esempio:È possibile facoltativamente collegare il tuo motore di visualizzazione, politica di routing, serializzazione dei parametri, ecc.).Supporta anche l'utilizzo dell'iniezione di dipendenza esistente e dei modelli di contenitori IOC (Windsor, Spring.net, NHibernate, ecc.).

  • Include un componente di mappatura URL molto potente che consente di creare applicazioni con URL puliti.Gli URL non devono avere estensioni al suo interno e sono progettati per supportare facilmente i modelli di denominazione SEO e per il riposo.Ad esempio, potrei facilmente mappare l'URL/Products/Edit/4 all'azione "Modifica" della classe ProductsController nel mio progetto sopra o mappare/Blogs/Scottgu/10-10-2007/Sometopic/URL a A " DisplayPost "Azione di una classe BlogEnGineController.

  • Il framework MVC supporta utilizzando i file ASP.Aspx, .ascx e .Ascx esistenti come "Modelli di visualizzazione" (significa Controlli del server, modelli, legame dati, localizzazione, ecc.).Tuttavia, non utilizza il modello post-back esistente per le interazioni di ritorno al server.Invece, invece inserirai tutte le interazioni dell'utente finale a una classe di controller, il che aiuta a garantire una pulita separazione di preoccupazioni e testabilità (significa anche nessuna vista di viewstate o ciclo di vita con viste basate su MVC).

  • Il framework ASP.NET MVC supporta pienamente funzionalità ASP.NET esistenti come Autenticazione di moduli/Windows, autorizzazione URL, appartenenza/ruoli, output e memorizzazione nella cache dei dati, gestione dello stato di sessione/profilo, monitoraggio sanitario, sistema di configurazione, architettura del provider, ecc.

In primo luogo, rende molto semplice la creazione di siti Web testabili con separazioni di responsabilità ben definite.È anche molto più semplice creare interfacce utente XHTML valide utilizzando il nuovo framework MVC.

Ho utilizzato il 2° CTP (penso che siano su cinque adesso) per iniziare a lavorare su un sito Web e, avendo creato alcune applicazioni Web in precedenza, devo dire che è centinaia di volte migliore rispetto all'utilizzo del modello di controllo del server.

I controlli del server vanno bene quando non sai cosa stai facendo.Quando inizi a imparare come dovrebbero funzionare le applicazioni web, inizi a combatterle.Alla fine, dovrai scriverne uno tuo per superare le carenze dei controlli attuali.È a questo punto che l'MVC inizia a brillare.E questo senza considerare nemmeno la testabilità del tuo sito web...

Ottimo articolo di Dino Esposito che ha lo scopo di spiegare ASP.net MVC agli sviluppatori di moduli web ASP.net:

http://dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx

Niente più ID HTML generati automaticamente!!!Chiunque esegua qualsiasi tipo di Javascript apprezza questo fatto.

ASP.Net con il suo codice è Quasi MVC - ma non - l'unica cosa importante che non lo fa è che i codebehind sono legati direttamente agli aspx, che è un componente importante di MVC.Se stai pensando ai codebehind come al controller, dovrebbero essere completamente disaccoppiati dalla vista.Il nuovo .NET MVC completa tutto ciò e offre un framework MVC completo.Sebbene ne esistano già per .NET (vedi Spring.NET).

Ho esaminato un paio di semplici esempi come Questo.Posso vedere la differenza.Tuttavia, non vedo davvero come MVC disaccoppia la vista dal controller.La vista fa ancora riferimento a elementi presenti nel controller.Vedo come rende molto più semplice il test e che almeno in MVC il controller non ha alcuna conoscenza della vista.E non dovresti elaborare la vista per chiamare i metodi nel controller.Vedo che è un bel salto, anche se a prima vista potrebbe non sembrare molto.

Sono d'accordo con @Will sulla lotta ai controlli del server.Non ho mai lavorato in una situazione in cui venivano effettivamente utilizzati, ma molte persone che conosco che lo hanno fatto hanno riscontrato alcune limitazioni con loro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top