Il più grande vantaggio nell'uso di ASP.Net MVC rispetto ai moduli web

Quali sono alcuni dei vantaggi dell'utilizzo l'uno rispetto all'altro?

I principali vantaggi di ASP.net MVC sono:

1. Abilita il controllo completo sull'HTML renderizzato.

2. Fornisce una separazione netta delle preoccupazioni (SoC).

3. Abilita Test Driven Development (TDD) .

4. Facile integrazione con framework JavaScript.

5. Seguendo il design della natura apolide del web.

6. URL RESTful che abilitano il SEO.

7. Nessun evento ViewState e PostBack

I principali vantaggi di ASP.net Web Form sono:

1. Fornisce lo sviluppo RAD

2. Modello di sviluppo semplice per gli sviluppatori che provengono dallo sviluppo di winform.

ASP.NET Web Forms e MVC sono due framework Web sviluppati da Microsoft: sono entrambe buone scelte. Nessuno dei due framework web deve essere sostituito dall'altro né ci sono piani per farli "fondere" in un singolo framework. Supporto e sviluppo continui vengono eseguiti in parallelo da Microsoft e nessuno dei due "andrà via".

Ognuno di questi framework Web offre vantaggi / svantaggi, alcuni dei quali devono essere considerati durante lo sviluppo di un'applicazione Web. Un'applicazione Web può essere sviluppata utilizzando una delle due tecnologie: potrebbe facilitare lo sviluppo di una particolare applicazione selezionando una tecnologia rispetto all'altra e viceversa.

Moduli Web ASP.NET:

• Lo sviluppo supporta lo stato • Dà l'illusione che un'applicazione Web sia a conoscenza di ciò che l'utente ha fatto, in modo simile alle applicazioni Windows. Vale a dire, rende la funzionalità 'guidata' un po 'più semplice da implementare. I moduli Web fanno un ottimo lavoro nel nascondere molta di quella complessità allo sviluppatore.
• Sviluppo rapido delle applicazioni (RAD) • La capacità di "saltare dentro" e iniziare a fornire moduli Web. Questo è contestato da alcuni membri della comunità MVC, ma è stato spinto da Microsoft. Alla fine, dipende dal livello di competenza dello sviluppatore e da ciò con cui si sentono a proprio agio. Il modello di moduli Web ha probabilmente una curva di apprendimento inferiore per gli sviluppatori meno esperti.
• Toolbox di controllo più grande • ASP.NET Web Forms offre un toolbox molto più grande e più robusto (controlli web) mentre MVC offre un set di controllo più primitivo che si affida maggiormente a controlli lato client avanzati tramite jQuery (Javascript).
• Maturo • È in circolazione dal 2002 e ci sono molte informazioni in merito a domande, problemi, ecc. Offre un maggiore controllo da parte di terzi - è necessario considerare i kit di strumenti esistenti.

ASP.NET MVC:

• Separazione delle preoccupazioni (SoC) • Da un punto di vista tecnico, l'organizzazione del codice all'interno di MVC è molto chiara, organizzata e granulare, rendendo più facile (si spera) che un'applicazione web si ridimensioni in termini di funzionalità. Promuove l'ottimo design dal punto di vista dello sviluppo.
• Integrazione più semplice con gli strumenti lato client (strumenti di interfaccia utente avanzati) • Più che mai, le applicazioni Web stanno diventando sempre più ricche delle applicazioni che vedi sui tuoi desktop. Con MVC, ti dà la possibilità di integrarti con tali toolkit (come jQuery) con maggiore facilità e più fluidità rispetto ai Web Form.
• Ottimizzazione dei motori di ricerca (SEO) Friendly / Stateless • Gli URL sono più amichevoli con i motori di ricerca (ad es. Mywebapplication.com/users/ 1 - recupera l'utente con un ID 1 rispetto a mywebapplication / users / getuser.aspx (ID passato nella sessione)). Allo stesso modo, poiché MVC è senza stato, questo rimuove il mal di testa degli utenti che generano più browser Web dalla stessa finestra (collisioni di sessione). Sulla stessa linea, MVC aderisce al protocollo web senza stato piuttosto che "combattere" contro di esso.
• Funziona bene con gli sviluppatori che necessitano di un alto grado di controllo • Molti controlli nei moduli Web ASP.NET generano automaticamente gran parte del codice HTML non elaborato che viene visualizzato durante il rendering di una pagina. Ciò può causare mal di testa agli sviluppatori. Con MVC, si presta meglio ad avere il controllo completo di ciò che viene reso e non ci sono sorprese. Ancora più importante, è che i moduli HTML sono in genere molto più piccoli dei moduli Web che possono equivalere a un aumento delle prestazioni - qualcosa da considerare seriamente.
• Test Driven Development (TDD) • Con MVC, è possibile creare più facilmente test per il lato web delle cose. Un ulteriore livello di test fornirà un ulteriore livello di difesa contro comportamenti imprevisti.

Autenticazione, autorizzazione, configurazione, compilazione e distribuzione sono tutte caratteristiche condivise tra i due framework Web.

Chiunque sia abbastanza grande da ricordare ASP classico ricorderà l'incubo di aprire una pagina con codice mescolato con html e javascript - anche la pagina più piccola è stata una seccatura per capire cosa diavolo stesse facendo. Potrei sbagliarmi, e spero di si, ma MVC sembra tornare a quei brutti vecchi tempi.

Quando è arrivato ASP.Net, è stato salutato come il salvatore, separando il codice dal contenuto e permettendoci di fare in modo che i web designer creassero l'html e i programmatori lavorassero sul codice sottostante. Se non volevamo usare ViewState, lo disattivavamo. Se non volessimo usare il codice dietro per qualche motivo, potremmo inserire il nostro codice all'interno dell'html proprio come il classico ASP. Se non volevamo utilizzare PostBack, reindirizziamo a un'altra pagina per l'elaborazione. Se non volevamo usare i controlli ASP.Net, abbiamo usato i controlli html standard. Potremmo anche interrogare l'oggetto Response se non volessimo usare ASP.Net runat = "server" sui nostri controlli.

Ora qualcuno nella loro grande saggezza (probabilmente qualcuno che non ha mai programmato ASP classico) ha deciso che è tempo di tornare ai giorni in cui mescoliamo il codice con il contenuto e lo chiamano "separazione delle preoccupazioni". Certo, puoi creare HTML più pulito, ma puoi farlo con ASP classico. Dire "non stai programmando correttamente se hai troppo codice all'interno della tua vista" è come dire "se hai scritto codice ben strutturato e commentato in ASP classico è molto più pulito e migliore di ASP.NET"

Se volessi tornare a mescolare il codice con il contenuto, guarderei allo sviluppo usando PHP che ha un ambiente molto più maturo per quel tipo di sviluppo. Se ci sono così tanti problemi con ASP.NET, allora perché non risolverli?

Ultimo ma non meno importante, il nuovo motore Razor significa che è ancora più difficile distinguere tra HTML e codice. Almeno potremmo cercare tag di apertura e chiusura, ad esempio <% e%> in ASP, ma ora l'unica indicazione sarà il simbolo @.

Potrebbe essere il momento di passare a PHP e attendere altri 10 anni affinché qualcuno separi di nuovo il codice dal contenuto.

Se stai lavorando con altri sviluppatori, come PHP o JSP (e sto indovinando le rotaie), avrai un tempo molto più semplice per convertire o collaborare alle pagine perché non avrai tutti quegli ASP.NET "cattivi" eventi e controlli ovunque.

Il problema con MVC è che anche per gli "esperti" si guadagna molto tempo prezioso e richiede molto sforzo. Le aziende sono guidate dalla cosa base "Soluzione rapida che funziona" indipendentemente dalla tecnologia che sta dietro. WebForms è una tecnologia RAD che consente di risparmiare tempo e denaro. Tutto ciò che richiede più tempo non è accettabile per le aziende.

1. AJAX corretto, ad esempio JSON, non restituisce nessuna assurdità di postback parziale della pagina.
2. nessuna visualizzazione +1
3. Nessuna ridenominazione degli ID HTML.
4. HTML pulito = senza gonfia e con un tiro decente nel rendering di XHTML o pagine conformi agli standard.
5. Niente più javascript AXD generato.

Il più grande vantaggio per me sarebbe la netta separazione tra i livelli Model, View e Controller. Aiuta a promuovere un buon design sin dall'inizio.

Non ho visto NESSUN vantaggio in MVC su ASP.Net. 10 anni fa Microsoft ha ideato UIP (User Interface Process) come risposta a MVC. È stato un flop. All'epoca abbiamo realizzato un grande progetto (4 sviluppatori, 2 designer, 1 tester) con UIP ed è stato un vero incubo.

Non limitarti a saltare sul carro per il bene di Hype. Tutti i vantaggi sopra elencati sono già disponibili in Asp.Net (con ulteriori modifiche [ Nuove funzionalità in Asp.Net 4 ] in Asp.Net 4).

Se il tuo team di sviluppo o una singola famiglia di sviluppatori con Asp.Net si attiene a questo e crea rapidamente splendidi prodotti per soddisfare i tuoi clienti (che pagano per le tue ore di lavoro). MVC consumerà il tuo tempo prezioso e produrrà gli stessi risultati di Asp.Net :-)

Francis Shanahan,

1. Perché chiamate il postback parziale come "assurdità"? Questa è la caratteristica principale di Ajax ed è stata utilizzata molto bene nel framework Atlas e in meravigliosi controlli di terze parti come Telerik

2. Accetto il tuo punto in merito al punto di vista. Ma se gli sviluppatori stanno attenti a disabilitare viewstate, questo può ridurre notevolmente la dimensione dell'HTML che viene reso così la pagina diventa leggera.

3. Solo i controlli del server HTML vengono rinominati nel modello ASP.NET Web Form e non i controlli html puri. Qualunque cosa possa essere, perché sei così preoccupato se la ridenominazione è stata fatta? So che vuoi gestire molti eventi javascript sul lato client, ma se progetti le tue pagine web in modo intelligente, puoi sicuramente ottenere tutti gli ID che desideri

4. Anche i moduli Web ASP.NET soddisfano gli standard XHTML e non vedo alcun gonfiore. Questa non è una giustificazione del perché abbiamo bisogno di un modello MVC

5. Ancora una volta, perché sei infastidito da AXD Javascript? Perché ti fa male? Questa non è di nuovo una giustificazione valida

Finora sono un fan dello sviluppo di applicazioni utilizzando i classici moduli Web ASP.NET. Ad esempio: se si desidera associare un elenco a discesa o una visualizzazione griglia, è necessario un massimo di 30 minuti e non più di 20 righe di codice (minimo ovviamente). Ma nel caso di MVC, parla con gli sviluppatori di quanto sia doloroso.

Il più grande svantaggio di MVC è che stiamo tornando ai tempi di ASP. Ricorda il codice spaghetti di mescolare codice server e HTML ??? Oh mio Dio, prova a leggere una pagina aspx MVC mista a javascript, HTML, JQuery, CSS, tag Server e cosa no .... Qualcuno può rispondere a questa domanda?

I moduli Web ottengono anche da una maggiore maturità e supporto da parte di fornitori di controllo di terze parti come Telerik.

Nei webform puoi anche eseguire il rendering di quasi interamente html a mano, ad eccezione di alcuni tag come viewstate, eventvalidation e simili, che possono essere rimossi con PageAdapters. Nessuno ti obbliga a utilizzare GridView o altri controlli lato server che hanno un output di rendering HTML non valido.

Direi che il più grande vantaggio di MVC è SPEED!

Il prossimo è la separazione forzata delle preoccupazioni. Ma non ti proibisce di inserire tutta la logica BL e DAL all'interno del Controller / Azione! È solo una separazione della vista, che può essere eseguita anche in moduli web (modello MVP per esempio). Molte cose che la gente menziona per mvc possono essere fatte in moduli web, ma con qualche sforzo aggiuntivo.
La differenza principale è che la richiesta arriva al controller, non alla vista, e quei due livelli sono separati, non collegati tramite classe parziale come nei moduli web (aspx + codice dietro)

I miei 2 centesimi:

• I moduli ASP.net sono ideali per lo sviluppo rapido di applicazioni e per l'aggiunta rapida di valore aziendale. Lo uso ancora per la maggior parte delle applicazioni Intranet.
• MVC è ottimo per l'ottimizzazione dei motori di ricerca poiché controlli l'URL e l'HTML in misura maggiore
• MVC generalmente produce una pagina molto più snella, senza HTML viewstate e più pulito = tempi di caricamento rapidi
• MVC semplifica la memorizzazione nella cache di parti della pagina. -MVC è divertente scrivere: - opinione personale ;-)

MVC ti consente di avere più di un modulo in una pagina, una piccola funzionalità che conosco ma è utile!

Anche il modello MVC che ritengo facilita la manutenzione del codice, esp. quando lo rivisiti dopo pochi mesi.

Controller MVC:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

Vista MVC:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

Quanto è difficile? Nessun ViewState, nessun ciclo di vita della pagina BS ... Solo codice puro ed efficiente.

Vedo che i soli due vantaggi per i siti più piccoli sono: 6) URL RESTful che consentono la SEO. 7) Nessun evento ViewState e PostBack (e maggiori prestazioni in generale)

Il test per siti di piccole dimensioni non è un problema, né i vantaggi di progettazione quando un sito è codificato correttamente comunque, MVC in molti modi offusca e rende le modifiche più difficili da apportare. Sto ancora decidendo se valgono questi vantaggi.

Riesco a vedere chiaramente il vantaggio di MVC nei siti multi-sviluppatore più grandi.

Il vantaggio principale che trovo è che forza il progetto in una struttura più testabile. Questo può essere fatto abbastanza facilmente anche con i moduli web (modello MVP), ma richiede allo sviluppatore di capirlo, molti non lo fanno.

Webform e MVC sono entrambi strumenti praticabili, entrambi eccellenti in aree diverse.

Personalmente utilizzo i moduli Web mentre sviluppiamo principalmente app B2B / LOB. Ma lo facciamo sempre con un modello MVP con il quale possiamo ottenere una copertura del codice del 95% in più per i nostri test unitari. Questo ci consente anche di automatizzare i test sulle proprietà del valore della proprietà di webcontrols che viene esposto attraverso la vista, ad es

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) Non credo che questo livello di test sia raggiunto facilmente in MVC, senza inquinare il mio modello.

Non ti senti più male nell'utilizzare i "controlli non post-back" e nel pensare a come trasferirli in un ambiente asp.net tradizionale.

Ciò significa che i moderni controlli javascript (gratuiti da usare) come questo o questo o questo possono tutti essere utilizzati senza che si cerchi di inserire un piolo tondo in un buco quadrato.

I moderni controlli javascript e le richieste JSON possono essere gestiti molto facilmente utilizzando MVC. Lì possiamo usare molti altri meccanismi per pubblicare dati da un'azione a un'altra. Ecco perché preferiamo MVC ai moduli web. Inoltre possiamo costruire pagine leggere.

La mia opinione personale è che, il più grande svantaggio dell'utilizzo di ASP.Net MVC è quello CODE BLOCKSmischiato con HTML...
inferno HTML per gli sviluppatori che lo mantengono ...