Le cose che odiamo per il classico asp ma esistono ancora nei webforms oggi

Question

Sto lavorando a un elenco di ragioni per cui il mio team passa da Webform a MVC e ho pensato che un buon punto di partenza fosse il "perché dovremmo migrare "con un insieme di cose che hanno in comune sia l'asp classico che i webform.

Come ad esempio:

spaghetti code (violazione della SRP)

Classic ASP - ogni file asp sentiva come una grande palla di fango
Webforms - questo grande palla di fango è andato dal punto di vista al famigerato "codebehind"

Ricorda che i miei sviluppatori non sono il tipo per implementare qualcosa come MVP che non viene spinto e questo fa parte della r Eason mi piace MVC (pur mantenendo i controllori sottile sarà un'esperienza di apprendimento)

Aggiornamento Sono consapevole del fatto che è possibile creare un pasticcio in qualsiasi lingua su qualsiasi piattaforma. Sono anche consapevole del fatto che MVC non risolverà questo problema. Sono anche consapevole del fatto che è necessario fare un po 'di mentoring per far sì che una squadra scriva un casino per capire perché è difficile da mantenere. Tuttavia, ritengo che questa opportunità mi consenta di esprimere la necessità di un Design/Testabilità orientato al SOC/Responsabilità/ecc.

Informazioni sulla creazione di software più gestibile con WebForms: Dalla mia esperienza l'attuazione di un modello di presentazione come MVP in WebForms a rispettare SRP/aumentare la manutenibilità/abilitare unit testing/etc è molto più lavoro rispetto all'utilizzo di MVC fuori dalla scatola (e voi ottenere gli stessi risultati). Funziona - sì e ho avuto successo con questo approccio in passato. Ma se potessi sfruttare un approccio molto più naturale allo sviluppo web che è stato inserito nella piattaforma, lo farei.

Stavo cercando qualcuno che indicasse cose che lo sviluppatore medio di 9-5 "voleva" da cui allontanarsi quando scrivevano il classico asp ma dopo che erano entrati in webform con cui non si erano mai mossi. (anche in questo caso, la maggior parte degli sviluppatori con cui lavoro ha semplicemente preso il casino che si sono lamentati nel classico asp e lo ha spostato nel codice e "pensato" questo era un passo nella giusta direzione).

Answer 1

Parte del problema è che si può facilmente avere "Spaghetti Code" e "Grandi palle di fango" con visualizzazioni MVC scritte male - se si dice che sarà una "esperienza di apprendimento" mantenendo i controller sottili, allora si ' Avrai difficoltà a mantenere i tuoi punti di vista puliti e in ordine.

Vedere anche StackOverflow.com Search for "WebForms vs MVC" per altre domande simili con il tipo di argomenti che stai cercando.

---

Modifica in risposta alla domanda di modificare

Ok, le cose non mi piace in ASP.NET che sono stati rimossi/risolti da ASP.NET MVC:

1. dover ricordare di impostare ViewStateEnabled = false per ridurre le dimensioni della pagina.
2. Avendo un controllo limitato sull'id dei controlli del lato client (questo verrà risolto in ASP.NET 4.0, tuttavia, dove è possibile impostare ClientID).
3. Avendo poco controllo sul rendering HTML dei controlli (sebbene questo possa essere attenuato con gli adattatori di controllo CSS, che saranno incorporati in ASP.NET 4.0, e sono il comportamento predefinito che penso).

Queste sono le cose principali per me che apprezzo molto quando costruisco i miei siti basati su MVC.

Answer 2

Secondo la mia onesta opinione, stai guardando i motivi sbagliati per cambiare. Passare a ASP.NET MVC non risolverà nessuno di questi problemi. È ancora possibile avere una vista gigante con tanto, se non più, codice spaghetti (o palla di fango) come ASP classico o Webform.

I suoi punti di discussione dovrebbe essere più lungo le linee di separazione delle preoccupazioni, friendly URL (disponibile in Webforms anche), un maggiore controllo sulla pagina, ecc

È possibile controllare questo post del blog da Microsoft anche:

Web Forms vs. ASP.NET MVC

... prendono atto della frase sulla parte inferiore della pagina.

ASP.NET MVC non è l'anti-Web Forms

Entrambi hanno i loro usi propri. Passare a uno dall'altro a causa della scarsa codifica non aiuterà. È possibile farlo in uno dei due ...

Answer 3

ASP.NET/webforms sembra come (per prendere in prestito da Joel Spolsky) un "grande astrazione che perde" di stato su un mezzo sostanzialmente senza stato. Mentre questo (mi è stato detto) è stato grandioso per gli sviluppatori di WinForms che hanno iniziato lo sviluppo del web, "moduli Web" mi è sempre sembrato un paradigma fondamentalmente imperfetto per questo motivo.

Quando ho iniziato (di recente) a conoscere lo sviluppo web (proveniente da uno sfondo del desktop) mi è stato presentato attraverso Python/Django e RoR e non avevo alcuna esposizione a ASP.NET "classico", webforms, o J2EE. Immagino che nella mia ingenuità immagino di aver appena ipotizzato che tutto lo sviluppo web (o almeno tutto lo sviluppo web su larga scala) fosse basato sul pattern MVC, mi è sembrato così naturale per il web. Venendo contro ASP.NET "classico" in natura è stato .. aprendo gli occhi o_O

Supponendo di avere qualche scelta in materia, perché dovresti non voler utilizzare ASP.NET MVC?

Answer 4

maggior parte degli sviluppatori con cui lavoro hanno semplicemente preso il pasticcio si lamentavano in ASP classico e si è trasferito al codice alle spalle e "pensato" questo è stato un passo nella giusta direzione ).

Beh, è un passo nella giusta direzione - meglio di nessuna separazione a tutti. Sebbene, sì, è ancora spesso una grande palla di fango.

Durante i miei momenti ottimistici, penso che, beh, forse sposta semplicemente la palla-o-fango sul codebehind, ma forse pianta i semi di "hmm, forse il contenuto dovrebbe essere separato dalla presentazione!" in alcune menti. MVC o un modello simile è ovviamente la destinazione che alla fine raggiungeranno.

(non chiedetemi cosa penso durante i miei momenti NON ottimistiche ... haha.)

Answer 5

voglio avvertirvi che il problema centrale che si sta segnalando non è di natura tecnica. Con il tipo di sviluppatori che descrivi (immotivato, scarsamente istruito o incapace), ti suggerirei di prendere in considerazione il fatto di NON passare al framework asp.net MVC.

Il framework MVC non risolverà i problemi di un team che è lento nell'apprendere e utilizzare i principi del buon design nel proprio lavoro. Ma il framework MVC nel modulo attuale aggiungerà un LOI di apprendimento aggiuntivo ai propri piatti. Il framework MVC non ha molto a che fare con le funzionalità di RAD e utilizzarlo correttamente richiede una profonda comprensione della natura di Http stessa.

Un'applicazione MVC mal implementata sta per essere MOLTO peggio di un'applicazione Webforms mal implementata. Con le webform, è possibile ottenere non comprendendo molto sulle interazioni più profonde di Http e tali perché il framework gestisce la maggior parte della gestione dello stato stesso.

Con programmatori come quelli che descrivi probabilmente finirai per insegnare loro come progettare OO allo stesso tempo, mentre stai cercando di insegnare loro gli interni di Http e farli apprendere un tutto nuovo quadro anche.

Questo è abbastanza difficile con programmatori altamente motivati ​​e molto capaci.