Non è la prima volta che parlo di WPF davanti ad un po' di persone: c'è sempre curiosità durante i corsi ASP.NET, per cui qualche parola la spendo, anche per dire che no, il .NET Framework 3.0 in realtà non è niente di nuovo, è solo, per così dire, un po' di aggiunte alle 2.0. E poi l'ho fatto insieme a Cristian al Windows Development Day, però è la prima che faccio un corso organico. Ed un po' me ne meraviglio, visto che quasi tutti quelli con cui scambio opinioni lavorano su WPF, ma quasi nessuno in progetti reali, per clienti veri. Sono stato fortunato, ho trovato un cliente che vuole usarlo :)
E' vero che sono di parte perchè mi piace il web e quindi di riflesso ASP.NET, ma sono del parere che se c'è una cosa che non ha smosso di una virgola la penetrazione del .NET Framework sono le WinForms, per tantissimi motivi, non ultimo il fatto che generalmente se ne vedono meno i benefici rispetto a quanto c'è già. Non vederli non vuol dire che non ci siano, ovviamente.
WPF da questo punto di vista non può che trovare il mio favore. Ha un modello di sviluppo e di separazione del codice molto più vicino ad ASP.NET di quanto lo sia quello basato sulle WinForm. E' tanto vicino ad ASP.NET, che quando sbagliate a scrivere qualcosa, vi rallegra con un bel "Whooops", celebre grido di battaglia di ScottGu.
Ha un modello vettoriale che consente di creare GUI che si adattano alla risoluzione, utilizzando gli stili in maniera anche più potente di quanto un CSS possa mai consentire. Ed è tutto a markup, che per quanto mi riguarda è l'unico modo per fare quello che un designer spesso, per i propri limiti, nasconde.
Attached properties e property element, databinding e transformation sono tra le cose migliori che possano mai capitare ad uno sviluppatore che deve fare GUI dall'alto impatto grafico.
Fermo restando che a me WPF serve soprattutto nelle applicazioni per Media Center, che diventano semplicemente di un altro pianeta rispetto a quelle basate sulle hosted HTML app, dopo un po' di utilizzo ci si abitua. E sembra tutto abbastanza scontato.
La cosa su cui ho trovato più difficoltà è stato capire il modo in cui sfruttare al meglio il binding ed il fatto che in realtà è qualcosa di integrato rispetto ai controlli stessi, io abituato ai Data Controls di ASP.NET. Quando poi lo capisci e ti rendi conto che INotifyChanged è una cosa che ti semplifica la vita, ti sembra di aver utilizzato da sempre quella sintassi (e poi, in realtà, lo ripeto, come sviluppatore ASP.NET non è così diverso da quello che facciamo sempre).
Tutto bello, il dramma è essenzialmente la mancanza di un editor decente.
Expression Blend è fantastico, fa fare anche trasformazioni ed effetti animati senza conoscere XAML. L'interfaccia è ottima, ma non ha intellisense, è troppo pensato per un grafico (ed è normale, non è per uno sviluppatore...) ma è anni luce avanti rispetto a Cider.
Cider è l'estensione che si aggiunge a VS 2005, è praticamente inutile per lo sviluppo a design time (non supporta nemmeno gli stili definiti esternamente, cosa che Blend invece fa bene), ma è praticamente una specie di alpha, un contentino nell'attesa. Con VS Orcas credo che la parte di intellisense, che pure ha qualche limite quando si definiscono i DataTemplate, sarà affiancata dal designer di Blend: allora avremo un vero editor.
La verità è che perchè si diffonda, WPF dovrà aspettare ancora molto, quanto meno dovrà poter contare su un editor decente. Già il solo fatto che sia così complesso, incide nell'allontare lo sviluppatore medio, che tra l'altro generalmente viene da uno sviluppo caratterizzato da un approccio completamente diverso, che non sfrutta il markup, ma un designer.
Fino ad allora non ci meravigliamo troppo che WPF non si diffonde, se non in ambiti ben particolari, come appunto quello delle applicazioni per Windows Media Center. Ma le caratteristiche delle applicazioni WPF per MCE sono un buon argomento per il futuro ;)
Per ora, sono più che felice di aver investito il mio tempo su WPF, mi serviranno ancora un po' di mesi perchè tutto mi sia chiaro e familiare al 100%, ma per ora non può che farmi piacere questa nuova avventura.
Ciao Daniele,
il databinding delle custom entities nelle applicazioni smart client è più "interattivo" di quello relativo al mondo ASP.NET e come tale è normale che sia anche un po' più complesso.
Anche il binding delle collection di entities non scherza. In WPF bisogna utilizzare la classe base ObservableCollection<T>, una sorta di controparte (molto semplificata) di BindingList<T> del mondo winforms.
Modificato da Cradle il 11 gennaio 2007 14.34 -
Cradle ha scritto:
Ciao,
il databinding delle custom entities nelle applicazioni smart client è più "interattivo" di quello relativo al mondo ASP.NET e come tale è normale che sia anche un po' più complesso.
ma non parlo della complessità del codice, ma del motore di binding di WPF, non per forza limitato a custom entities, ma a qualsiasi informazioni.
parlo ad esempio della possibilità di fare molto più via markup di quanto si possa fare in altri ambiti (ad esempio, prendere e dare la dimensione ad un controllo specificando quella di un altro, dato il suo ID).
Anche il binding delle collection di entities non scherza. In WPF bisogna utilizzare la classe base ObservableCollection<T>, una sorta di controparte (molto semplificata) di BindingList<T> del mondo winforms.
certo, con ObservableCollection di fatto hai tutto quello che ti serve per automatizzare l'aggiornamento dell'interfaccia rispetto ai dati contenuti nella collection. ma, ripeto, non stavo parlando solo di data binding, ma più di binding in generale
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Daniele Bochicchio <Daniele_Bochicchio@aspitalia.invalid> ha scritto:
Quando riuscirò a dedicargli un po' di tempo?
Continua »»» | Rispondi »»»