Ci sono alcune cose che non posso fare con ASP.NET MVC? Le cose che sono possibili solo con Web Forms ASP.NET, o estremamente molto più facile con WebForms?Cose che non posso fare in ASP.NET MVC
Consideriamo l'utilizzo di ASP.NET MVC per un nuovo progetto. Ma mi chiedo se ci sono alcune cose ovvie che non saremo in grado di fare con ASP.NET MVC rispetto a WebForms o dove dovremo passare molto tempo con ASP.NET MVC.
Il più grande utilizza i controlli di terze parti esistenti nel modulo. La maggior parte dei controlli incorporati è piuttosto facile da riprodurre, ma se si dispone di un controllo di terze parti per gli animali domestici, potrebbe essere necessario ospitarli su una normale pagina aspx (non MVC) (per fortuna questo è supportato).
Allo stesso modo, "parti web"
Inoltre - la caratteristica in cui ASP.NET utilizza diversi HTML per diversi clienti (mobili, ecc) diventa ... diverso; non vorresti farlo a mano, ma in realtà la maggior parte dei client ora funziona con standard html, quindi è meno un problema in primo luogo.
Alcune cose come i18n tramite file resx richiedono un lavoro extra rispetto al modello MVC di vanilla, ma i campioni sono presenti su Internet.
Un punto ... MVC è concesso in licenza solo per MS/ASP.NET; quindi una cosa che non puoi fare (senza violare i termini, a quanto ho capito) è eseguirla in mono/Apache - ma IANAL.
Ora consideriamo le cose che si possono fare con MVC, che non si può (o sono difficili) con vaniglia:
re risoluzione di ingresso:
public ActionResult Show(string name, int? page, int? pageSize) {...}
selezionerà "nome", "pagina" e "pagina Dimensiona "off (nessuna) del percorso, della stringa di query o del modulo, in modo da non dover dedicare molto tempo alla selezione dei valori delle richieste.
modelli - aspx/ascx non sono le uniche opzioni di modello. Ad esempio, vedi here; oppure puoi scrivere il tuo se vuoi ... La vista non è legata ai controlli ASP.NET a tutti.
Penso che lo stato di visualizzazione non esista in MVC. Dovrai tracciare il tuo stato di visualizzazione in un modo diverso rispetto allo stato di visualizzazione incorporato nei progetti non MVC.
MODIFICA: In base ai commenti: "Sbarazzarsi di ViewState è un vantaggio non uno svantaggio". - Craig
MVC ha una raccolta chiave/valore ViewData che persiste sui post per il mantenimento dello stato. una collezione TempData viene utilizzata anche per modifiche di stato una tantum: es. messaggi di stato "questo record è stato cancellato" –
ViewState fa parte del modello di postback WebForms e non ha alcun utilizzo in MVC, allo stesso modo in cui non viene utilizzato con PHP o Python. Sbarazzarsi di ViewState è un vantaggio non uno svantaggio. – Craig
+1 per Craig.Viewstate è una cosa migliore solo mediocre, e nelle peggiori situazioni è un abominio completo. È meglio che ce ne sbarazziamo. – Kibbee
Quello grande è Controlli. I controlli utente non sono disponibili con ASP.NET MVC. Sono persino arrivato al punto di provare ad usare codice come questo:
new Label().RenderControl(...ResponseStream...);
Nessun dado.
Naturalmente, come parte di questo, non è necessario per visualizzare lo stato, in modo che non è lì.
I controlli server funzionano, tuttavia.
Mentre è vero, puoi utilizzare le viste parziali per qualcosa di simile –
questo è di progettazione: l'approccio MVC tenta di creare semplicità e un maggiore controllo su esattamente quale markup è reso –
MVC ha controlli utente, non ha Controlli server poiché sono progettati per andare con il modello WebForms. Poiché MVC non è concepito per essere visivo drag'n'drop, i controlli server di sviluppo basati sugli eventi non sono necessari. Non è una svista, è una decisione progettuale. – Craig
Come ha detto Marc, non è possibile utilizzare strumenti di terze parti e (web server) i controlli web. Quindi schiaffeggiare qualcosa insieme rapidamente trascinando alcuni controlli su un modulo (come una griglia e un controllo di accesso ai dati) non è più un'opzione.
Ma con la codegenerazione ecc. Si può ancora fare qualcosa velocemente. E hai ancora l'opzione sopra se hai bisogno di qualcosa di veloce.
La convalida non è semplice come in WebForms. In Webforms puoi aggiungere un validatore e solo impostare una proprietà che abiliti la validazione dei client. È possibile localizzare il messaggio errato. La localizzazione funziona lato client e lato server.
Non esiste alcuna convalida clientide in MVC e è necessario trovare un modo per localizzare i messaggi errati dei client.
La localizzazione è diversa. Le risorse ovviamente per impostazione predefinita non esistono per pagina, perché non esiste una pagina. Ma c'è un buon modo per avere risorse per visualizzazione.
Non ho ancora controllato, se è possibile impostare SSL richiesto per cartella.
EDIT
La storia è diversa con MVC3. C'è un buon supporto per la validazione ora.
Ci sono ancora cose che non sono implementate in MVC. Il più grande problema per me è un'implementazione completa per l'incasso a ciambella e l'incasso parziale. C'è un certo miglioramento in MVC3 in quest'area ma non è ancora completo. Comunque rimanete sintonizzati: il team MVC sembra essere consapevole che questo è qualcosa su cui dovrebbero lavorare.
Grazie per i commenti. Riguardo la validazione serveride/clientide, ho trovato xval (http://xval.codeplex.com) che sembra offrire una soluzione a questo ... –
La validazione è stata molto migliorata in MVC2 –
.. e anche in MVC3 –
ASP.NET Ajax non funziona con ASP.NET MVC, quindi nessun UpdatePanel (a causa della mancanza di postback). Fortunatamente esiste un ajax integrato (Ajax.Form) che può essere utilizzato per eseguire aggiornamenti parziali, per non parlare di jQuery, che viene fornito di default con il modello di progetto di Visual Studio.
Grazie per la bella risposta, il che mi rende più sicuro che sia relativamente sicuro andare su mvc. Tuttavia, non capisco cosa c'è dietro i tuoi punti con 'risoluzione automatica dell'input', 'IoC/DI', e 'più opzioni per i modelli'. Hai qualche esempio di cosa intendi con questo? –
aggiornato per domanda –
ASP.Net MVC è open source sotto MS-PL, che è una licenza molto liberale, vedere http://weblogs.asp.net/scottgu/archive/2009/04/01/asp-net- MVC-1-0.aspx. È perfettamente legale correre sotto mono. – jeroenh