Andrea Dottor – Microsoft MVP ASP.NET/IIS

IL BUON PROGRAMMATOREconsigli pratici per una vita felice

Esperienze personali Da anni lavoro come libero professionista, e

durante le consulenze/sviluppo/formazione sono incappato spesso in "errori" comuni

www.dottor.net

Altre fonti: Damian Edwards: Don’t do that, do this!

Recommendations from the ASP.NET team http://vimeo.com/68390507

What not to do in ASP.NET, and what to do instead http://www.asp.net/aspnet/overview/aspnet-45/what-

not-to-do-in-aspnet,-and-what-to-do-instead

Perché questa sessione?

Inesperienza Si crede di conoscere completamente una

tecnologia Non si conosce l'esistenza di particolari

funzioni/metodi

Fretta Un progetto "prototipo" sviluppato in

fretta, diventa la base per un "prodotto" Il budget/tempistiche non sono realistiche

Pigrizia Si sceglie la strada più breve, perché fare

le cose nel modo migliore richiederebbe qualche riga di codice in più

Da dove vengono gli errori?

Riuso e manutenzione del codice Configurazione Prestazioni Produttività

Cosa vedremo in questa sessione?

Riuso del codice e manutenzione

Framework Design Guidelines http://msdn.microsoft.com/en-us/library/ms229042.aspx

General Naming Conventions http://msdn.microsoft.com/en-us/library/vstudio/ms229045(v=vs.110).aspx

Namespace Naming Guidelines http://msdn.microsoft.com/en-us/library/893ke618(v=vs.71).aspx

C# Reference http://msdn.microsoft.com/en-us/library/vstudio/618ayhy6(v=vs.110).aspx

Non esistono line guida solo su come scrivere il codice Es: Visual Studio Team Foundation Server Branching

and Merging Guide http://vsarbranchingguide.codeplex.com/

E' importante che a livello aziendale venga deciso quali standard e naming-convention si debba adottare

Naming convention e linee guida

Separare in progetti/assembly separati la logica che può essere riutilizzata Helpers Accesso ai dati DTO

Scrivere tutto in un unico progetto significa dover riscrivere parte del codice nel caso di nuova applicazione (simile)

Dare nomi sensati agli assembly <Company>.<Component>.dll

Le Portable Class Library permettono di condividere codice tra progetti di tipo diverso

Come strutturare i progetti di un'applicazione

I namespace permettono di organizzare il codice all'interno di un assembly

Permettono di tenere separate classi che hanno compiti/scopi differenti All'interno dello stesso namespace non

possono esistere più classi con lo stesso nomeCompanyName.TechnologyName[.Feature][.Design]

Gli assembly separano il codice a livello fisico, i namespace invece a livello logico

Cosa sono i namespace? A che servono?

demo

Il riutilizzo del codice vale anche per gli stili, e per il codice JavaScript!!

Non settare gli stili nei controlli, ma bensì impostiamo delle classi css e usiamo i fogli di stile Riutilizzo degli stili

I file css vengono messi in cache dal browser Le pagine pesano meno

Facilità nel seguire i repentini cambi idea del cliente, senza doversi ripassare tutte le pagine

In WebForm "avevamo" i temi, non dimentichiamoci le buone abitudini

Centralizziamo gli stili

Fanno risparmiare un sacco di tempo Introduzione di funzionalità avanzate in tempi

ridotti Il costo dei controlli è sicuramente inferiore al

costo di uno sviluppatore (che implementi lo stesso controllo)

Ma non è tutto oro quello che luccica: se hanno un bug? se modificano il loro rendering? quanto JavaScript iniettano?

Utilizziamoli solo quando è realmente necessario

Controlli di terze parte

Una classe per file Se una classe ha molte righe di

codice, è preferibile utilizzare le partial class (e dividerla in più file) invece di nascondere il codice con le region

Cercate di essere il più "aderenti" possibile a quello che è lo standard della tecnologia che utilizzate Gli accrocchi, barbatrucchi, workaround

non sono sempre una soluzione ideale

Buone abitudini

demo

Configurazione

Permette di applicare modifiche/trasformazioni ai file di configurazione in fase di compilazione Centralizzazione dei settings nel progetto Si può creare una "traformazione" per ogni

ambiente di pubblicazione

Evitano allo sviluppatore il copia&incolla o la modifica della configurazione ad ogni pubblicazione Spesso capita che nuovi settings non vengono

riportati in produzione

Web.config transormation

Offrono la possibibilità di specificare dei parametri (key-value) che permettono di parametrizzare l'applicazione senza dover ricompilare Vengono letti come String Non sono validati Nessuno ci avvisa della mancanza di un

AppSettings

Attenzione a modificare/disabilitare parametri di sicurezza (in produzione) http://

msdn.microsoft.com/en-us/library/hh975440 ES:

<add key="aspnet:MaxHttpCollectionKeys" value="1000" /><add key="aspnet:MaxJsonDeserializerMembers" value="1000" />

Uso corretto degli AppSettings

Il framework permette di avere all'interno dei file di configurazione delle proprie sezioni di configurazione custom.

A differenza degli AppSettings, queste possono essere tipizzate, e validate Valori obbligatori Valori di default Limiti, min max

Sezioni di configurazione custom

Se i file di configurazione hanno grosse dimensioni, è possibile suddividerli in più file

E' utile quando si lavora in team Ad esempio, le ConnectionString possono

essere diverse per ogni dev

Suddivisione della configurazione in più file

<appSettings configSource="AppSettings.config" />

demo

prestazioni

Il Viewstate non è il male E' utile, ma va utilizzato con cognizione di causa

L'abuso del Viewstate causa un degrado delle performance della pagine Tempo di serializzazione/deserializzazione Dimensione della pagina Tempo di trasmissione della pagina

Invece di utilizzare EnableViewState="false", preferire ViewStateMode="Disabled" nella direttiva di pagina, e settare ViewStateMode="Enabled" solo nei controlli che lo richiedono EnableViewState=false disabilita la ViewState anche

per i controlli figlio

Viewstate

Da ASP.NET 4.0 è presente la funzionalità di bundle & minification

Permette di ottimizzare i file JavaScript e CSS presenti nell'applicazione Crea un file unico, che raggruppa più file js Lo riduce di dimensione, minimizzandolo

Viene applicato quando si esegue l'applicazione in Release Non deve essere presente Debug=true nel

web.config

ASP.NET bundle & minification

demo

Ricordarsi sempre di pubblicare in produzione compilando in modalità Release

Rimuovere dal Web.config l'attributo debug="true" (presente nell'elemento compilation) , oppure impostarlo a "false"

In Debug gli assembly vengono arricchiti di codice necessario al debug, che però causano rallentamenti nell'esecuzione

Il codice ritornato dagli handler axd non viene messo in cache dal browser

Compilare in release & debug=false

Il Trace raccoglie informazioni su ogni richiesta fatta all'applicazione Oltre al normale tempo di esecuzione della

richiesta, viene aggiunto il tempo necessario al Trace per loggare

Il Trace necessita di spazio in memoria per mantenere le informazioni

Abilitarlo solo in caso di debug Inserire una regola di

trasformazione che rimuova la sezione, oppure che lo disabiliti per default

ASP.NET Trace

produttività

Visual Studio permette di allineare/indentare in modo automatico il codice CTRL+K CTRL+D

Le regole di formattazione del codice HTML possono essere modificate dai settings di Visual StudioTOOLS -> Options -> Text editor -> HTML -> Formatting

Il codice allineato correttamente facilita la lettura del codice stesso

A colpo d'occhio si riesce a capire come gli elementi sono innestati

Regole di formattazione

Utilizzare la tastiera invece di cercare il commando nella toolbar è più veloce

Quelli più frequenti sono: Commentare il codice

CTRL+K CTRL+C

Togliere il commento CTRL+K CTRL+U

Formattazione del codice CTRL+K CTRL+D

Aprire menu SmartTag (create Class, import using, ….) CTRL+.

Selezione rettangolare ALT+selezione

Visual Studio 2010 Keybinding Posters http://www.microsoft.com/en-us/download/details.aspx?

id=13189

Scorciatoie da tastiera

demo

Il "var" non è il variant di Visual Basic 6

Il "var" viene sostitutito in fase di compilazione con il tipo corretto

Personalmente lo trovo molto utile quando utilizzo tipi (molto) complessi Es:

Non abbiate paura del "var"

List<Tuple<int, string, DateTime>> result = new List<Tuple<int, string, DateTime>>();

var result = new List<Tuple<int, string, DateTime>>();

Il Logging è FONDAMENTALE Quando si è in produzione (spesso) è

l'unica cosa che permette di identificare un problema e la sua causa

Bisogna saper loggare Troppe informazione a volte equivale a non averne

nessuna Usare differenti livelli di log: INFO, DEBUG, ERROR

Esistono librerie che ci aiutano in questo Log4net Enterprise Library Logging Application Block …

Logging

Chi utilizza WCF, oltre al proprio logging può abilitare il Diagnostic

Permette di loggare qualsiasi cosa passi attraverso le classi di WCF Compresi i messaggi in ingresso ed uscita Permette di identificare errori che

avvengono ancora prima che il messaggio arrivi al nostro codice

WCF diagnostic / logging

demo

Da ASP.NET 4.0 il SqlMembershipProvider è stato sostituito dal UniversalProvider

Supporta tutti i database supportati dall'Entity Framework SQL Server, SQL Azure, SQL Compact, MySQL, …

Disponibile su NuGet http

://www.nuget.org/packages/Microsoft.AspNet.Providers/

Utilizzabile per Session Membership Roles Profile

ASP.NET membership - UniversalProvider

Un source-control non è fatto solo per chi lavora in team

Tenere una copia del codice (solo) in locale è pericoloso

Avere lo storico dei cambiamenti è un aiuto da non sottovalutare

Esistono soluzione gratuite che si possono adottare http://tfs.visualstudio.com/ https://github.com/ http://subversion.tigris.org/ …

Controllo sorgente

Mantenere il codice semplice e pulito è la prima regola per facilitare il lavoro di manutenzione Ricordate sempre il "Principio KISS"

Non complicate le applicazioni con Pattern solo perché fanno figo/moda. Non servono sempre Sono fatti per risolvere determinate

problematiche

Over-ingegnerizzare una soluzione è il primo modo per farsi del male

Scrivete il codice come se lo doveste manutenere voi

Conclusioni

feedback

10

o feedback su:• http://xedotnet.org/feedback

• Codice: OCT68• Materiale:

http://slpg.org/xe102013

Email: andrea@dottor.netWebsite: http://www.dottor.net Blog: http://blog.dottor.netTwitter: http://twitter.com/dottor

feedback