Suggerimenti per evitare una grande palla di fango con ASP.NET WebForms

Question

Sebbene ASP.NET MVC sembri avere tutto il clamore in questi giorni, WebForms è ancora abbastanza pervasivo. Come mantieni sano il tuo progetto? Raccogliamo alcuni suggerimenti qui.

Answer 1

• Crea controlli utente web per tutto ciò che verrà mostrato su più di una pagina che non fa parte del contenuto del tipo di pagina master. Esempio: se l'applicazione visualizza le informazioni sul prodotto su 10 pagine, è meglio avere un controllo utente che viene utilizzato su 10 pagine anziché tagliare il codice di visualizzazione 10 volte.
• Inserisci la minima logica di business nel codice dietro possibile. Il codice dietro dovrebbe differire al livello aziendale per eseguire il lavoro che non è direttamente correlato all'inserimento di oggetti nella pagina e all'invio di dati dal livello aziendale.
• Non reinventare la ruota. Un sacco di code scarse che ho visto sono costituite da codice che sta facendo cose che il framework fornisce già.
• In generale, evita i blocchi di script nell'html.
• Non avere una pagina per fare troppe cose. Qualcosa che ho visto più volte è una pagina che dice ha modalità di aggiunta e modifica. Va bene. Tuttavia, se hai molte modalità secondarie da aggiungere e modificare, è meglio avere più pagine per ciascuna modalità secondaria con il riutilizzo tramite i controlli utente. Hai davvero bisogno di evitare di andare su un mucchio di IF nidificati per determinare cosa sta cercando di fare il tuo utente e quindi mostrare le cose corrette a seconda di ciò. Le cose vanno fuori controllo rapidamente se la tua pagina ha molti stati possibili.
• Impara / Grok il ciclo di vita della pagina e utilizzalo a tuo vantaggio. Molte brutte pagine di codice che ho visto potrebbero essere più pulite se il programmatore capisse meglio il ciclo di vita della pagina.

Answer 2

In genere cerco di starne alla larga ... ma quando uso WebForms, seguo questi precetti:

1. Mantieni pulito il codice HTML risultante : solo perché non stai scrivendo a mano ogni <div> non significa che il codice generato debba diventare un incubo illeggibile. Evitare i controlli che producono codice brutto può ripagare in tempi di debug ridotti in un secondo momento, rendendo i problemi più facili da vedere.
2. Riduci al minimo le dipendenze esterne : non ti viene pagato per eseguire il debug del codice di altre persone. Se fai scegli di affidarti a componenti di terze parti, ottieni la fonte in modo da non dover perdere insolitamente grandi quantità di tempo a correggere i loro bug.
3. Evita di fare troppo in una pagina : se ti accorgi di implementare " mode " per una data pagina, prendi in considerazione l'idea di suddividerla in più pagine a modalità singola, magari utilizzando le pagine mastro per valutare gli aspetti comuni.
4. Evita il postback : questa è sempre stata un'idea terribile e non è diventata meno terribile. I mal di testa che risparmierai non usando i controlli che dipendono dal postback sono un bel bonus.
5. Evita VIEWSTATE : vedi i commenti per # 4.

Answer 3

Con progetti di grandi dimensioni il miglior suggerimento che posso darti è quello di seguire un modello di progettazione comune che tutti i tuoi sviluppatori sono ben addestrati e ben consapevoli. Se hai a che fare con ASP.NET, le due migliori opzioni per me sono:

o Model View Presenter ( sebbene questo sia ora Supervisor Controller e Vista passiva ).   Questo è un modello solido che spinge la separazione tra l'interfaccia utente e il modello aziendale che tutti gli sviluppatori possono seguire senza troppi problemi. Il codice risultante è molto più verificabile e gestibile. Il problema è che non viene applicato e che è necessario scrivere un sacco di codice di supporto per implementare il modello.

o ASP.NET MVC   Il problema con questo è che è in anteprima. Ho parlato con Tatham Oddie e mi è stato detto che è molto stabile e utilizzabile. Mi piace, impone la separazione delle preoccupazioni e lo fa con un codice aggiuntivo minimo per lo sviluppatore.

Penso che qualunque sia il modello che scegli, la cosa più importante è avere un modello e garantire che tutti i tuoi sviluppatori siano in grado di attenersi a quel modello.

Answer 4

Inizia con le pagine mastro il primo giorno - è un dolore tornare al retrofit.

Answer 5

Seguendo quello che ha detto Odd, sto provando una versione di MVP chiamata Model Presentation che finora funziona bene per me. Lo sto ancora capendo e lo sto adattando al mio uso, ma è rinfrescante dal codice che ho usato per scrivere.

Dai un'occhiata qui: Modello di presentazione

Answer 6

Utilizza il controllo versione e una struttura di cartelle per evitare che troppi file si trovino tutti nella stessa cartella. Non c'è niente di più doloroso che aspettare che Windows Explorer carichi qualcosa perché ci sono più di 1.000 file in una cartella e deve caricarli tutti quando la cartella viene aperta. Una convenzione sulla denominazione di variabili e metodi è anche utile avere un anticipo, se possibile, in modo che non ci sia questo miscuglio di codice in cui diversi sviluppatori mettono tutti i loro tocchi unici e lo dimostra dolorosamente.

L'utilizzo di modelli di progettazione può essere utile per organizzare il codice e ridimensionarlo correttamente, ad es. un modello di strategia può portare a un momento più facile in cui si deve aggiungere un nuovo tipo di prodotto o dispositivo che deve essere supportato. Simile per l'utilizzo di alcuni modelli di adattatori o di facciate.

Infine, sai quali standard verranno rispettati dai tuoi moduli: è solo per gli utenti IE o qualcuno di IE, Firefox o Safari dovrebbe caricare facilmente il modulo e avere un bell'aspetto?