Qualcuno accanto a me NON ha semplicemente ASP.NET MVC? [chiuso]

Ho armeggiato con ASP.NET MVC dal CTP, e mi piacciono molte cose che hanno fatto, ma ci sono cose che proprio non capisco.

Ad esempio, ho scaricato beta1 e sto mettendo insieme un piccolo sito / curriculum / blog personale. Ecco uno snippet dalla vista ViewSinglePost:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

Disgustoso! (Nota anche che nell'HTML esiste un segnaposto HTML temporaneo, realizzerò un vero progetto una volta che la funzionalità funzionerà) .

Sto facendo qualcosa di sbagliato? Perché ho trascorso molti giorni bui nell'ASP classico, e questa zuppa di tag me lo ricorda fortemente.

Tutti predicano come si può fare HTML più pulito. Indovina un po? L'1% di tutte le persone osserva l'HTML emesso. Per me, non mi interessa se Webforms incasina la mia rientranza nell'HTML renderizzato, purché abbia un codice che è facile da mantenere ... Questo non lo è!

Quindi, convertimi, un tipo di webform duro, perché dovrei rinunciare alle mie pagine ASPX ben formate per questo?

Modifica: Grassetto la linea "temp Html / css" in modo che la gente si stupisca.

Rispetto ai Web Form, MVC è contemporaneamente un approccio di livello inferiore alla generazione di HTML con un maggiore controllo sull'output della pagina e un approccio di livello superiore, più guidato dall'architettura. Consentitemi di acquisire Web Form e MVC e di mostrare perché penso che il confronto favorisca i Web Form in molte situazioni, purché non cadiate in alcune trappole di Web Form classici.

Moduli Web

Nel modello Web Form, le tue pagine corrispondono direttamente alla richiesta di pagina dal browser. Pertanto, se stai indirizzando un utente a un elenco di libri, probabilmente avrai una pagina da qualche parte chiamata "Booklist.aspx" a cui lo indirizzerai. In quella pagina, dovrai fornire tutto il necessario per mostrare tale elenco. Ciò include il codice per l'estrazione di dati, l'applicazione di qualsiasi logica aziendale e la visualizzazione dei risultati. Se c'è qualche logica architettonica o di routing che influenza la pagina, dovrai codificare anche la logica architettonica sulla pagina. Lo sviluppo di buoni moduli Web di solito comporta lo sviluppo di un insieme di classi di supporto in una DLL separata (testabile dall'unità). Queste classi gestiranno la logica aziendale, l'accesso ai dati e le decisioni di architettura / routing.

MVC

MVC ha una visione più "architettonica" dello sviluppo di applicazioni web: offre uno scaffold standardizzato su cui costruire. Fornisce inoltre strumenti per la generazione automatica di classi di modelli, viste e controller all'interno dell'architettura stabilita. Ad esempio, sia in Ruby on Rails (solo "Rails" da qui in avanti) che in ASP.NET MVC inizierai sempre con una struttura di directory che riflette il loro modello generale di architettura delle applicazioni web. Per aggiungere una vista, un modello e un controller, utilizzerai un comando come "Script Rails / generate scaffold {nome modello}" (ASP.NET MVC offre comandi simili nell'IDE). Nella classe di controller risultante, ci saranno metodi ("Azioni") per Index (mostra elenco), Show, New e Edit e Destroy (almeno in Rails, MVC è simile). Per impostazione predefinita, questi "

Il layout di directory e file è significativo in MVC. Ad esempio, in ASP.NET MVC, il metodo Index per un oggetto "Libro" avrà probabilmente solo una riga: "Return View ();" Attraverso la magia di MVC, questo invierà il modello del libro alla pagina "/View/Books/Index.aspx" dove troverai il codice per visualizzare i libri. L'approccio di Rails è simile sebbene la logica sia un po 'più esplicita e meno "magica". Una pagina Visualizza in un'app MVC è in genere più semplice di una pagina Web Form perché non devono preoccuparsi troppo di routing, logica aziendale o gestione dei dati.

Confronto

I vantaggi di MVC consistono in una netta separazione delle preoccupazioni e in un modello più pulito, più HTML / CSS / AJAX / Javascript per produrre il tuo output. Ciò migliora la testabilità, fornisce un design più standardizzato e apre le porte a un tipo di sito Web più "Web 2.0".

Tuttavia, ci sono anche alcuni svantaggi significativi.

Innanzitutto, mentre è facile avviare un sito dimostrativo, il modello architettonico complessivo presenta una curva di apprendimento significativa. Quando dicono "Convention Over Configuration" suona bene - fino a quando non ti rendi conto di avere un libro di convenzioni da imparare. Inoltre, è spesso un po 'esasperante per capire cosa sta succedendo, perché si sta contando sulla magia piuttosto che le chiamate esplicite. Ad esempio, "Return View ();" chiamare sopra? La stessa identica chiamata può essere trovata in altre azioni, ma vanno in luoghi diversi. Se capisci la convenzione MVCallora sai perché questo è fatto. Tuttavia, certamente non si qualifica come un esempio di buona denominazione o di codice facilmente comprensibile ed è molto più difficile da raccogliere per i nuovi sviluppatori rispetto ai Web Form (questo non è solo un parere: ho fatto un tirocinante estivo per imparare i Web Form l'anno scorso e MVC quest'anno e le differenze di produttività sono state pronunciate - a favore dei Web Form). A proposito, Rails è un po 'meglio in questo senso, anche se Ruby on Rails offre metodi con nomi dinamici che prendono anche un po' di tempo per abituarsi.

In secondo luogo, MVC presuppone implicitamente che si stia costruendo un classico sito Web in stile CRUD. Le decisioni sull'architettura e in particolare i generatori di codice sono tutti progettati per supportare questo tipo di applicazione web. Se stai creando un'applicazione CRUD e vuoi adottare un'architettura comprovata (o semplicemente non ti piace la progettazione dell'architettura), allora dovresti probabilmente considerare MVC. Tuttavia, se farai più di CRUD e / o sei ragionevolmente competente con l'architettura, MVC potrebbe sembrare una camicia di forza fino a quando non padroneggi davvero il modello di routing sottostante (che è considerevolmente più complesso del semplice routing in un'app WebForms). Anche allora, mi sono sentito come se stessi combattendo sempre il modello e preoccupato per risultati inaspettati.

In terzo luogo, se non ti interessa Linq (o perché hai paura che Linq-to-SQL scompaia o perché trovi Linq-a-Entità ridicolmente sovra-prodotto e sotto-alimentato), allora non vuoi nemmeno percorrere questo percorso poiché gli strumenti di ponteggio ASP.NET MVC sono costruiti attorno a Linq (questo è stato il killer per me). Il modello di dati di Rails è anche piuttosto goffo rispetto a quello che puoi ottenere se hai esperienza in SQL (e specialmente se sei esperto di TSQL e procedure memorizzate!).

In quarto luogo, i sostenitori di MVC sottolineano spesso che le viste MVC sono più vicine nello spirito al modello HTML / CSS / AJAX del web. Ad esempio, "HTML Helpers" - le piccole chiamate di codice nella tua pagina vew che cambiano contenuto e lo inseriscono nei controlli HTML - sono molto più facili da integrare con Javascript rispetto ai controlli Web Forms. Tuttavia, ASP.NET 4.0 introduce la possibilità di assegnare un nome ai controlli e quindi elimina ampiamente questo vantaggio.

In quinto luogo, i puristi MVC spesso deridono Viewstate. In alcuni casi, hanno ragione a farlo. Tuttavia, Viewstate può anche essere un ottimo strumento e un vantaggio per la produttività. A titolo di confronto, la gestione di Viewstate è molto più semplice rispetto al tentativo di integrare controlli Web di terze parti in un'app MVC. Mentre l'integrazione dei controlli può essere più semplice per MVC, tutti gli sforzi attuali che ho visto soffrono della necessità di costruire un codice (un po 'grodoso) per collegare questi controlli alla classe Controller della vista (ovvero - per aggirare il modello MVC ).

conclusioni

Mi piace lo sviluppo di MVC in molti modi (anche se preferisco Rails a ASP.NET MVC da tempo). Penso anche che sia importante non cadere nella trappola di pensare che ASP.NET MVC sia un "anti-pattern" di Web Form ASP.NET. Sono diversi ma non completamente alieni e sicuramente c'è spazio per entrambi.

Tuttavia, preferisco lo sviluppo di moduli Web perché, per la maggior parte delle attività , è semplicemente più semplice eseguire le attività (l'eccezione è la generazione di un set di moduli CRUD). Anche l'MVC sembra soffrire, in una certa misura, di un eccesso di teoria. In effetti, guarda le molte domande poste qui su SO da persone che conoscono ASP.NET orientato alla pagina ma che stanno provando MVC. Senza eccezioni, c'è molto digrignamento dei denti poiché gli sviluppatori scoprono che non possono svolgere compiti di base senza saltare attraverso i cerchi o sopportare un'enorme curva di apprendimento. Questo è ciò che rende Web Forms superiore a MVC nel mio libro: MVC ti fa pagare un prezzo reale al fine di ottenere un po 'più di testabilità o, peggio ancora, di essere semplicemente visto come fico perché stai usando illa più recente tecnologia.

Aggiornamento: sono stato pesantemente criticato nella sezione commenti, alcuni dei quali abbastanza onesti. Quindi, ho trascorso diversi mesi a studiare Rails e ASP.NET MVC solo per assicurarmi di non perdere davvero la prossima grande novità! Naturalmente, aiuta anche a garantire una risposta equilibrata e adeguata alla domanda. Dovresti sapere che la risposta di cui sopra è una riscrittura importante della mia risposta iniziale nel caso in cui i commenti sembrino non sincronizzati.

Mentre guardavo più da vicino in MVC ho pensato, per un po ', che sarei finito con un grande mea culpa. Alla fine ho concluso che, mentre penso che dobbiamo spendere molta più energia per l'architettura e la testabilità di Web Forms, MVC non risponde davvero alla mia chiamata. Quindi, un cordiale "grazie" alla gente che ha fornito critiche intelligenti alla mia risposta iniziale.

Per quanto riguarda coloro che hanno visto questo come una battaglia religiosa e che hanno progettato incessantemente inondazioni di downvote, non capisco perché ti disturbi (più di 20 voti negativi in ​​pochi secondi l'uno dall'altro in più occasioni non è certamente normale). Se stai leggendo questa risposta e ti chiedi se c'è qualcosa di veramente "sbagliato" nella mia risposta, dato che il punteggio è molto più basso di alcune delle altre risposte, ti assicuro che dice di più su alcune persone che non sono d'accordo con il senso generale di la comunità (nel complesso, questa è stata votata oltre 100 volte).

Il fatto è che molti sviluppatori non si occupano di MVC e, in effetti, questa non è una visione di minoranza (anche all'interno della SM come sembrano indicare i blog).

MVC ti offre un maggiore controllo sull'output e con questo controllo aumenta il rischio di scrivere HTML, tag soup, ecc.

Ma allo stesso tempo, hai diverse nuove opzioni che non avevi prima ...

1. Maggiore controllo sulla pagina e sugli elementi all'interno della pagina
2. Meno "spazzatura" nell'output, come ViewState o ID eccessivamente lunghi sugli elementi (non fraintendetemi, mi piace ViewState)
3. Migliore capacità di eseguire la programmazione lato client con Javascript (applicazioni Web 2.0 qualcuno?)
4. Non solo MVC, ma JsonResult è perfetto ...

Questo non vuol dire che non puoi fare nessuna di queste cose con WebForms, ma MVC rende tutto più semplice.

Uso ancora WebForms quando devo creare rapidamente un'applicazione Web poiché posso sfruttare i controlli del server, ecc. WebForms nasconde tutti i dettagli dei tag di input e dei pulsanti di invio.

Sia WebForms che MVC sono capaci di immondizia assoluta se si è trascurati. Come sempre, un'attenta pianificazione e una progettazione ben ponderata si tradurranno in un'applicazione di qualità, indipendentemente dal fatto che si tratti di MVC o WebForms.

[Aggiornare]

Se è anche una consolazione, MVC è solo una nuova tecnologia in evoluzione di Microsoft. Sono stati pubblicati molti post che WebForms non solo rimarrà, ma continuerà a essere sviluppato per ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... e così via...

Per coloro che sono preoccupati per il percorso che MVC sta prendendo, suggerirei di dare il tuo feedback a "ragazzi". Sembra che stiano ascoltando finora!

La maggior parte delle obiezioni a ASP.NET MVC sembra centrata attorno alle viste, che sono uno dei bit più "opzionali" e modulari nell'architettura. NVelocity , NHaml , Spark , XSLT e altri motori di visualizzazione possono essere facilmente sostituiti (ed è diventato più facile con ogni versione). Molti di questi hanno una sintassi MOLTO più concisa per eseguire la logica e la formattazione della presentazione, pur mantenendo il controllo completo sull'HTML emesso.

Oltre a ciò, quasi tutte le critiche sembrano dipendere dal <%%> nelle visualizzazioni predefinite e da quanto sia "brutto". Tale opinione è spesso radicata nell'uso dell'approccio WebForms, che sposta la maggior parte della classica bruttezza ASP nel file code-behind.

Anche senza fare code-behind "sbagliato", hai cose come OnItemDataBound in Repeaters, che è altrettanto brutto esteticamente, anche se in modo diverso, che "tag soup". Un ciclo foreach può essere molto più semplice da leggere, anche con incorporamento variabile nell'output di quel ciclo, in particolare se si arriva a MVC da altre tecnologie non ASP.NET. Google-fu richiede molto meno per capire il ciclo foreach che per capire che il modo di modificare quel campo nel tuo ripetitore è quello di confondere con OnItemDataBound (e il nido del topo di verificare se è l'elemento giusto da cambiare.

Il problema più grande con gli "spaghetti" basati su tag ASP è stato quello di spingere cose come connessioni al database tra l'HTML.

Il fatto che sia successo usando <%%> è solo una correlazione con la natura spaghetti dell'ASP classico, non causalità. Se mantieni la tua logica di visualizzazione su HTML / CSS / Javascript e la logica minima necessaria per eseguire la presentazione , il resto è sintassi.

Quando si confronta un dato bit di funzionalità con WebForms, assicurarsi di includere tutto il C # generato dal progettista e il codice C # dietro al codice .aspx per assicurarsi che la soluzione MVC non sia davvero molto più semplice .

Se combinato con un uso giudizioso di viste parziali per bit ripetibili di logica di presentazione, può davvero essere bello ed elegante.

Personalmente, vorrei che gran parte dei primi contenuti del tutorial si concentrassero più su questo fine delle cose piuttosto che quasi esclusivamente sul test-driven, sull'inversione del controllo, ecc. Mentre quella roba è ciò su cui gli esperti obiettano, i ragazzi nelle trincee sono più probabili opporsi al "tag soup".

Indipendentemente da ciò, questa è una piattaforma che è ancora in beta. Nonostante ciò, sta ottenendo MODO più distribuzione e sviluppatori non Microsoft che creano cose reali con la maggior parte della tecnologia Microsoft-beta. In quanto tale, il ronzio tende a far sembrare che sia più lungo di quanto non sia l'infrastruttura circostante (documentazione, schemi di guida, ecc.). Il fatto che sia veramente utilizzabile a questo punto amplifica questo effetto.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

Puoi fare un altro post chiedendo come farlo senza includere il CSS incorporato.

NOTA: ViewData.Model diventa Model nella prossima versione.

E con l'aiuto di un controllo utente questo sarebbe diventato

<% Html.RenderPartial("Pager", Model.PagerData) %>

dove PagerData è inizializzato tramite un costruttore anonimo nel gestore azioni.

modifica: Sono curioso di sapere come sarebbe la tua implementazione WebForm per questo problema.

Non sono sicuro a che punto la gente ha smesso di preoccuparsi del proprio codice.

L'HTML è il display più pubblico del tuo lavoro, ci sono MOLTI sviluppatori là fuori che usano Notepad, Notepad ++ e altri editor di testo semplice per creare molti siti Web.

MVC consiste nel riprendere il controllo dai moduli Web, lavorare in un ambiente senza stato e implementare il modello di progettazione di Model View Controller senza tutto il lavoro aggiuntivo che normalmente si svolge in un'implementazione di questo modello.

Se vuoi controllo, pulizia del codice e utilizzare modelli di progettazione MVC, questo è per te, se non ti piace lavorare con il markup, non preoccuparti di quanto il tuo markup sia deformato, quindi usa ASP.Net Web Forms.

Se non ti piace neanche, sicuramente farai altrettanto lavoro nel markup.

EDIT I Dovrei anche affermare che Web Form e MVC hanno il loro posto, non stavo affatto affermando che uno era migliore dell'altro, solo che ogni MVC ha la forza di riguadagnare il controllo sul markup.

Penso che ti manchino alcune cose. Innanzitutto, non è necessario per Response.Write, è possibile utilizzare i <%= %>tag. In secondo luogo, puoi scrivere le tue estensioni HtmlHelper per eseguire azioni comuni. Terzo, un po 'di formattazione aiuta molto. In quarto luogo, tutto ciò verrebbe probabilmente bloccato in un controllo utente per essere condiviso tra più viste diverse e quindi il markup complessivo nella vista principale è più pulito.

Ti garantirò che il mark up non è ancora pulito come si vorrebbe, ma potrebbe essere ripulito considerevolmente attraverso l'uso di alcune variabili temporanee.

Ora, non è così male e sarebbe ancora meglio se non dovessi formattarlo per SO.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

Il grosso problema con MVC è che si tratta di un framework concettuale che esiste da molto tempo e si è dimostrato un modo produttivo e potente per creare sia applicazioni Web che applicazioni workstation scalabili in orizzontale e verticale. Torna direttamente in Alto e Smalltalk. Microsoft è in ritardo alla festa. Quello che abbiamo ora con ASP.NET MVC è davvero primitivo, perché c'è così tanto da fare; ma dannazione, stanno lanciando nuove uscite in modo rapido e furioso.

Qual è stato il grosso problema con Ruby on Rails? Rails è MVC. Gli sviluppatori si sono convertiti perché, con il passaparola, è diventato il modo per i programmatori di essere produttivi.

È un affare enorme; MVC e l'approvazione implicita di jQuery sono punti chiave per Microsoft che accetta che la neutralità della piattaforma sia fondamentale. E ciò che è neutrale al riguardo, è che a differenza dei Web Form, Microsoft non può bloccarti concettualmente. Puoi prendere tutto il tuo codice C # e reimplementarlo in un'altra lingua (per esempio PHP o Java - lo chiami) perché è il concetto MVC che è portatile, non il codice stesso. (E pensa a quanto è enorme che puoi prendere il tuo design e implementarlo come app per workstation con poche modifiche al codice e nessuna modifica al design. Provalo con i Web Form.)

Microsoft ha deciso che Web Forms non sarà il prossimo VB6.

Dai un'occhiata al post di Rob Conery, I Spose, lo dirò semplicemente: dovresti imparare MVC

I due principali vantaggi del framework ASP.NET MVC rispetto ai moduli Web sono:

1. Testabilità : l'interfaccia utente e gli eventi nei moduli Web sono quasi impossibili da testare. Con ASP.NET MVC, le azioni del controller di unit testing e le visualizzazioni che rendono sono semplici. Ciò comporta un costo in termini di costi di sviluppo iniziali, ma gli studi hanno dimostrato che ciò ripaga a lungo termine quando arriva il momento di refactoring e manutenzione dell'app.
2. Migliore controllo sull'HTML renderizzato : dichiari che non ti interessa l'HTML renderizzato perché nessuno lo guarda. Questo è un reclamo valido se fosse l'unico motivo per avere un HTML formattato correttamente. Esistono numerosi motivi per volere un HTML formattato correttamente, tra cui: SEO, la possibilità di utilizzare più spesso selettori di ID (in CSS e JavaScript), impronte di pagine più piccole a causa della mancanza di ID viewstate e ridicolmente lunghi (ctl00_etcetcetc).

Ora, questi motivi non rendono ASP.NET MVC migliore o peggiore dei moduli Web in un modo in bianco e nero. ASP.NET MVC ha i suoi punti di forza e di debolezza, proprio come i moduli web. Tuttavia, la maggior parte delle lamentele su ASP.NET MVC sembra derivare da una mancanza di comprensione su come usarlo piuttosto che da vere imperfezioni nel framework. Il motivo per cui il tuo codice non è corretto o sembra corretto potrebbe essere perché hai diversi anni di esperienza nei moduli Web e solo 1-2 mesi di esperienza ASP.NET MVC.

Il problema qui non è tanto che ASP.NET MVC oscilla o fa schifo, è che è nuovo e c'è ben poco accordo su come usarlo correttamente. ASP.NET MVC offre un controllo molto più preciso su ciò che accade nella tua app. Ciò può rendere alcuni compiti più facili o più difficili a seconda di come li approcci.

Ehi, ho avuto delle difficoltà anche con il passaggio a MVC. Non sono assolutamente un fan del classico rendering ASP e MVC, mi ricorda molti di quei giorni. Tuttavia, più utilizzo MVC, più cresce su di me. Sono un tipo di webform (come molti altri) e ho passato diversi anni ad abituarmi a lavorare con datagrid, ecc. Con MVC che viene portato via. Le classi HTML Helper sono la risposta.

Di recente ho trascorso 2 giorni cercando di capire il modo migliore per aggiungere il paging a una "griglia" in MVC. Ora, con i moduli web sono riuscito a tirarlo fuori in pochissimo tempo. Ma lo dirò ... una volta che ho creato le classi di supporto per paging per MVC, è diventato estremamente semplice da implementare. Per me, ancora più facile dei moduli web.

Detto questo, penso che MVC sarà molto più amichevole per gli sviluppatori quando ci sono un set coerente di helper HTML. Penso che inizieremo a vedere un sacco di classi helper HTML spuntare sul web nel prossimo futuro.

È divertente perché è quello che ho detto la prima volta che ho visto i moduli web.

Devo ammettere che non ottengo ancora asp.net MVC. Sto cercando di usarlo in un progetto secondario che sto facendo, ma sta andando piuttosto lentamente.

Oltre a non essere in grado di fare cose così facili da fare nei moduli web, noto il tag soup. Sembra davvero fare un passo indietro da quella prospettiva. Continuo a sperare che man mano che imparerò andrà meglio.

Finora ho notato che il motivo principale per utilizzare MVC è ottenere il pieno controllo del tuo HTML. Ho anche letto che asp.net MVC è in grado di servire più pagine più velocemente dei moduli Web e probabilmente in relazione a ciò, la dimensione della singola pagina è inferiore a una pagina media dei moduli Web.

Non mi interessa che aspetto abbia il mio HTML purché funzioni nei principali browser, ma mi interessa quanto velocemente si caricano le mie pagine e quanta larghezza di banda occupano.

Mentre sono pienamente d'accordo sul fatto che si tratti di un brutto markup, penso che usare la brutta sintassi della vista per cancellare ASP.NET MVC nel suo insieme non sia giusto. La sintassi della vista ha ricevuto la minima attenzione da parte di Microsoft e mi aspetto completamente qualcosa da fare al riguardo.

Altre risposte hanno discusso i vantaggi di MVC nel suo insieme, quindi mi concentrerò sulla sintassi della vista:

L'incoraggiamento a usare Html.ActionLink e altri metodi che generano HTML è un passo nella direzione sbagliata. Questo puzza di controlli server e, per me, sta risolvendo un problema che non esiste. Se generiamo tag dal codice, allora perché preoccuparsi di usare l'HTML? Possiamo semplicemente usare DOM o qualche altro modello e creare i nostri contenuti nel controller. Ok, suona male, vero? Oh sì, separazione delle preoccupazioni, ecco perché abbiamo una visione.

Penso che la direzione corretta sia quella di rendere la sintassi della vista il più possibile simile all'HTML. Ricorda, un MVC ben progettato non dovrebbe solo darti la separazione del codice dal contenuto, ma dovrebbe permetterti di ottimizzare la tua produzione facendo in modo che le persone esperte nel layout lavorino sulle viste (anche se non conoscono ASP.NET), e poi in seguito come sviluppatore puoi intervenire e rendere la vista mockup effettivamente dinamica. Questo può essere fatto solo se la sintassi della vista assomiglia molto all'HTML, in modo che le persone del layout possano usare DreamWeaver o qualunque sia l'attuale strumento di layout popolare. Potresti costruire dozzine di siti contemporaneamente e devi ridimensionare in questo modo per l'efficienza della produzione. Vorrei fare un esempio di come ho potuto vedere la vista "lingua" funzionante:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Questo ha diversi vantaggi:

• sembra migliore
• più conciso
• nessun cambio di contesto funky tra tag HTML e <%%>
• parole chiave facili da capire che si spiegano da sole (anche un non programmatore potrebbe farlo - buono per il parallelismo)
• quanta più logica è tornata al controller (o modello) il più possibile
• nessun HTML generato - ancora una volta, questo rende molto facile per qualcuno entrare e sapere dove modellare qualcosa, senza dover fare confusione con HTML. metodi
• il codice contiene del testo di esempio che viene visualizzato quando si carica la vista come semplice HTML in un browser (di nuovo, buono per le persone di layout)

Quindi, cosa fa esattamente questa sintassi?

mvc: inner = "" - tutto ciò che è tra virgolette viene valutato e l'HTML interno del tag viene sostituito con la stringa risultante. (Il nostro testo di esempio viene sostituito)

mvc: outer = "" - tutto ciò che è tra virgolette viene valutato e il codice HTML esterno del tag viene sostituito con la stringa risultante. (Ancora una volta, il testo di esempio viene sostituito.)

{}: viene utilizzato per inserire l'output all'interno degli attributi, simile a <% =%>

mvc: if = "" - insde the qoutes è l'espressione booleana da evocare. La chiusura dell'if è dove viene chiuso il tag HTML.

MVC: altro

mcv: elseif = "" - ...

MVC: foreach

Ora posso solo parlare da solo qui:

IMO, se sei un duro (qualsiasi cosa), allora la conversione non fa per te. Se ami i Web Form perché è possibile realizzare ciò di cui hai bisogno, e anche questo è l'obiettivo.

Webforms fa un buon lavoro per sottrarre HTML dallo sviluppatore . Se questo è il tuo obiettivo, segui i moduli web. Hai tutte le meravigliose funzionalità "clicca e trascina" che hanno reso lo sviluppo desktop quello che è oggi. Esistono molti controlli inclusi (oltre a numerosi controlli di terze parti) che possono comportare funzionalità diverse. È possibile trascinare una "griglia" direttamente associata a un'origine dati dal database; viene fornito con inline editing, paging, ecc.

A partire da ora, ASP.NET MVC è molto limitato in termini di controlli di terze parti. Quindi, se ti piace Rapid Application Development, dove molte funzionalità sono cablate per te, non dovresti provare a convertirti.

Detto questo, è qui che ASP.NET brilla: - TDD. Il codice non è testabile, ha detto Nuff.

• Separazione degli interessi. Questa è la spina dorsale del modello MVC. Sono pienamente consapevole che è possibile ottenere questo risultato in Web Form. Tuttavia, mi piace la struttura imposta. In Web Form era troppo facile mescolare design e logica. ASP.NET MVC semplifica il lavoro di diversi membri di un team su diverse sezioni dell'applicazione.

• Provenendo da qualche altra parte: il mio background è CakePHP e Ruby on Rails. Quindi, è chiaro dove risiede il mio pregiudizio. Si tratta semplicemente di cosa ti senti a tuo agio.

• Curva di apprendimento: per espandere l'ultimo punto; Ho odiato l'idea di "templating" per cambiare la funzionalità di diversi elementi. Non mi è piaciuto il fatto che gran parte del design è stato realizzato nel codice dietro il file. Era un'altra cosa da imparare, quando conoscevo già intimamente HTML e CSS. Se voglio fare qualcosa in un "elemento" sulla pagina, inserisco un "div" o "span", schiaffo un ID su di esso e vado. In Web Forms dovrei andare alla ricerca su come farlo.

• Stato attuale del Web "Design": le librerie Javascript come jQuery stanno diventando sempre più comuni. Il modo in cui Web Form manipola i tuoi ID rende solo più difficile l'implementazione (al di fuori di Visual Studio).

• Più separazione (progettazione): poiché gran parte della progettazione è collegata ai controlli, sarebbe molto difficile per un progettista esterno (senza Web Form) lavorare su un progetto Web Form. Web Forms è stato creato per essere la fine di tutto ed essere tutto.

Ancora una volta, molte di queste ragioni derivano dalla mia scarsa familiarità con i moduli Web. Un progetto Web Form (se progettato correttamente) può avere "la maggior parte" dei vantaggi di ASP.NET MVC. Ma questo è un avvertimento: "Se progettato correttamente". E questo è solo qualcosa che non so fare nei moduli Web.

Se stai facendo un lavoro eccezionale in Web Form, sei efficiente e funziona per te, è lì che dovresti rimanere.

Fondamentalmente, fai una rapida revisione su entrambi (prova a trovare una fonte imparziale [buona fortuna]) con un elenco di pro e contro, valuta quale si adatta ai tuoi obiettivi e scegli in base a quello.

In conclusione, scegli il percorso di minor resistenza e maggior beneficio per raggiungere i tuoi obiettivi. Web Forms è un framework molto maturo e migliorerà solo in futuro. ASP.NET MVC è semplicemente un'altra alternativa (per disegnare gli sviluppatori di Ruby on Rails e CakePHP come me: P)

I JSP di Java EE apparivano così quando furono proposti per la prima volta - brutto codice di scriptlet.

Quindi hanno offerto librerie di tag per renderle più tag-ish HTML. Il problema era che chiunque poteva scrivere una libreria di tag. Alcuni dei risultati sono stati disastrosi, perché le persone hanno incorporato molta logica (e persino stile) nelle librerie di tag che hanno generato HTML.

Penso che la migliore soluzione sia la JSP Standard Tag Library (JSTL). È "standard", tag-ish HTML, e aiuta a impedire alle persone di inserire la logica nelle pagine.

Un ulteriore vantaggio è che conserva quella linea di demarcazione tra web designer e sviluppatori. I buoni siti che vedo sono progettati da persone con un senso estetico e progettando per usabilità. Distribuiscono pagine e CSS e li trasmettono agli sviluppatori, che aggiungono i bit di dati dinamici. Parlando come uno sviluppatore a cui mancano questi doni, penso che diamo qualcosa di importante quando chiediamo agli sviluppatori di scrivere pagine Web dalla zuppa alle noci. Flex e Silverlight soffriranno dello stesso problema, perché è improbabile che i progettisti conoscano bene JavaScript e AJAX.

Se .NET avesse un percorso simile a JSTL, consiglierei di esaminarlo.

Ho pensato di condividere l'aspetto di questo esempio con il nuovo brillante motore di visualizzazione Razor, predefinito da ASP .NET MVC 3.

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

Qualche problema con quello?
Inoltre, non dovresti davvero incorporare i tuoi stili CSS, vero? E perché controlli la nullità in tre posti anziché solo due? Un extra divfa male raramente. Ecco come lo farei:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Non posso parlare direttamente al progetto ASP.NET MVC, ma in generale i framework MVC sono arrivati ​​a dominare lo sviluppo di applicazioni Web perché

1. Offrono una separazione formale tra Operazioni su database, "Logica aziendale" e Presentazione

2. Offrono una flessibilità sufficiente nella vista per consentire agli sviluppatori di modificare il loro HTML / CSS / Javascript per funzionare su più browser e versioni future di tali browser

È quest'ultimo che è quello importante. Con i moduli Web e tecnologie simili, fai affidamento sul tuo fornitore per scrivere il tuo HTML / CSS / Javascript per te. È roba potente, ma non hai alcuna garanzia che l'attuale versione di Webform funzionerà con la prossima generazione di browser web.

Questo è il potere della vista. Ottieni il pieno controllo sull'HTML della tua applicazione. Il rovescio della medaglia è che devi essere abbastanza disciplinato per mantenere al minimo la logica nelle tue viste e mantenere il codice del modello il più semplice possibile.

Quindi, questo è il compromesso. Se i moduli web funzionano per te e MVC no, continua a utilizzare i moduli web

La maggior parte della mia frustrazione non è proprio sapere come fare le cose "correttamente". Da quando è stato rilasciato come anteprima, abbiamo avuto tutti un po 'di tempo per guardare le cose, ma sono cambiate un po'. All'inizio ero davvero frustrato, ma il framework sembra abbastanza fattibile da permettermi di creare un'interfaccia utente estremamente complessa (leggi: Javascript) abbastanza rapidamente. Capisco che puoi farlo con Webforms come facevo prima, ma è stato un dolore enorme nel culo cercare di ottenere tutto per renderlo correttamente. Molte volte finirei con un ripetitore per controllare l'esatto risultato e finirei con un sacco di pasticcio di spaghetti che hai anche sopra.

Nel tentativo di non avere lo stesso pasticcio, ho usato una combinazione di avere dominio, livelli di servizio e un dto per trasferire alla vista. Mettilo insieme a spark, un motore di visualizzazione e diventa davvero bello. Ci vuole un po 'di installazione, ma una volta che lo avessi fatto, ho visto un grande passo avanti nella complessità delle mie applicazioni visivamente, ma è così puzzolente semplice fare il codice.

Probabilmente non lo farei esattamente così, ma ecco il tuo esempio:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

È abbastanza gestibile, testabile e ha un sapore delizioso nella mia zuppa di codice.

L'asporto è che il codice pulito è davvero possibile, ma è un grosso cambiamento dal modo in cui stavamo facendo le cose. Tuttavia, non credo che tutti lo critichino ancora. So che lo sto ancora capendo ...

Il libro recentemente pubblicato da Steve Sanderson "Pro ASP.NET MVC" [1] [2] di Apress suggerisce un'altra alternativa: la creazione di un'estensione HtmlHelper personalizzata. Il suo esempio (dal capitolo 4 a pagina 110) utilizza l'esempio di un elenco di pagine, ma può essere facilmente adattato alla propria situazione.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Lo chiameresti a tuo avviso con un codice simile a questo:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Speravo di vedere un post di Phil Haack, ma non era qui, quindi ho appena tagliato e incollato da http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / nella sezione commenti

Haacked - 23 aprile 2009 - Rob, sei una rivolta! :) Lo trovo divertente quando le persone scrivono il codice spaghetti in MVC e poi dicono "guarda! Spaghetti!" Ehi, posso scrivere anche il codice spaghetti in Web Forms! Posso scriverlo su rotaie, PHP, Java, Javascript, ma non Lisp. Ma solo perché non riesco ancora a scrivere nulla in Lisp. E quando scrivo il codice spaghetti non guardo cupamente il mio piatto aspettandomi di vedere maccheroni. Il punto che le persone spesso sottolineano quando lo confrontano con l'ASP classico è che con l'ASP classico le persone tendevano a mescolare le preoccupazioni. Le pagine avrebbero una logica di visualizzazione con la gestione dell'input dell'utente mescolata con il codice modello e la logica aziendale tutte mescolate in una sola. Ecco di cosa parlavano gli spaghetti! Il mixaggio riguarda tutto in un unico grande casino. Con ASP.NET MVC, se segui il modello, hai meno probabilità di farlo. Si, potresti avere ancora un po 'di codice nella tua vista, ma speriamo che sia tutto il codice della vista. Il modello ti incoraggia a non inserire il codice di interazione dell'utente. Mettilo nel controller. Inserisci il codice del modello in una classe del modello. Là. Niente spaghetti. Adesso è O-Toro Sushi. :)

Anch'io; Trascorrerei il mio tempo su Silverlight piuttosto che su ASP.NET MVC. Ho provato MVC 1.0 e ho dato un'occhiata all'ultima versione 2.0 Beta 1 qualche giorno fa.

Non riesco a capire come ASP.NET MVC sia migliore di Webform. I punti di forza di MVC sono:

1. Unità (test)
   
2. Separare il design (vista) e la logica (controller + modello)
   
3. Nessuna viewstate e una migliore gestione dell'ID elemento
   
4. URL RESTful e altro ...

Ma webform, usando code-behind. Temi, skin e risorse sono già perfetti per separare il design e la logica.

Viewstate: la gestione dell'ID client è in arrivo su ASP.NET 4.0. Sono solo preoccupato per i test unitari, ma i test unitari non sono sufficienti per essere un motivo per trasformarmi in ASP.NET MVC dal modulo web.

Forse posso dire: ASP.NET MVC non è male, ma webform è già abbastanza.

Uso MVC da quando è uscita l'anteprima 3 e, sebbene abbia ancora dolori crescenti, aiuta un po 'nell'area dello sviluppo del team. Prova a far lavorare tre persone su una singola pagina di moduli web e poi capirai il concetto di sbattere la testa sul muro. Posso lavorare con uno sviluppatore che comprende gli elementi di progettazione nella pagina di visualizzazione e il nostro dio Linq residente nel far funzionare il modello mentre metto tutto insieme nel controller. Non sono mai stato in grado di svilupparmi in un regno in cui la separazione delle preoccupazioni fosse così facile da raggiungere.

Punto di vendita più grande di ASP.Net MVC - StackOverflow funziona nello stack MVC.

Detto questo ... il tuo codice è molto più bello di quello che faccio normalmente con la pagina di visualizzazione. Inoltre, uno dei ragazzi con cui lavoro sta lavorando sull'involucro dell'helper HTML in una libreria di tag. Invece di <% = Html.RandomFunctionHere ()%> funziona come

<hh: randomfunction />

Spero solo che il team MVC ci riesca ad un certo punto perché sono sicuro che farebbero un lavoro migliore.

Usa un modello di facciata per racchiudere tutta la logica per tutti i dati che devi visualizzare e poi usalo come tuo generico nella tua vista e poi .... niente più codice spaghetti. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Se hai bisogno di più aiuto cgardner2020@gmail.com

L'implementazione ASP.NET MVC è orribile. Il prodotto fa schifo. Ne ho visto diverse demo e mi vergogno di MSFT ... Sono sicuro che i ragazzi che l'hanno scritto sono più intelligenti di me, ma è quasi come se non sapessero cos'è il Model-View-Controller .

Le uniche persone che conosco che stanno cercando di implementare MVC sono persone a cui piace provare cose nuove da MSFT. Nelle demo che ho visto, il presentatore aveva un tono di scusa ...

Sono un grande fan di MSFT, ma devo dire che non vedo motivo di preoccuparsi della loro implementazione di MVC. Utilizza i moduli Web o usa jquery per lo sviluppo web, non scegliere questo abominio.

MODIFICARE:

L'intento del modello di progettazione architettonica Model-View-Controller è di separare il dominio dalla presentazione dalle regole aziendali. Ho usato il modello con successo in ogni progetto Web Form che ho implementato. Il prodotto ASP.NET MVC non si presta bene al modello di progettazione architettonica reale.