WPF vs WinForms - una prospettiva del programmatore Delphi?

Se hai uno sfondo di Delphi, rimarrai deluso da WinForms. Cercherai di fare cose facili con la VCL, solo per scoprire che sono dolorosamente difficili o addirittura impossibili. WPF sarà molto meno confinante.

Ad esempio, qui ci sono solo alcune delle limitazioni di WinForms in cui ci siamo imbattuti:

• WinForms non ha nulla che paragona TAction, quindi se sei abituato a codificare con azioni, condividendo lo stesso testo e icona tra una voce di menu e un pulsante della barra degli strumenti e un menu di scelta rapida, centralizzando la logica di abilitazione e aggiornando lo stato abilitato in background con OnUpdate ... odierà WinForms, dove devi fare tutto ciò che è difficile e soggetto a errori.
• Il vecchio menu di WinForms (.NET 1.0 vintage) non supporta le immagini accanto alle voci di menu e il nuovo (introdotto in .NET 2.0) MenuStrip è crivellato di bug che Microsoft si rifiuta di correggere (perché le correzioni dei bug potrebbero compromettere la compatibilità con le versioni precedenti).
• molti controlli, ad es. il TreeView, sono tristemente sottovalutati rispetto alle loro controparti VCL (dolorosamente lento, nessun disegno proprietario, molte opzioni di personalizzazione mancanti, ecc.)
• Non c'è nulla che assomigli alla vibrante comunità di sviluppatori di controlli di terze parti a cui sei abituato in Delphi. Ci sono librerie di controllo qualità là fuori, ma tu paghi per loro - offerte gratuite come VirtualTreeView non sono disponibili per WinForms.

WPF è un po 'più semplice per alcuni aspetti rispetto a WinForms, ma è immensamente più estensibile.

• Vuoi qualcosa come TAction? WPF ha ICommand, che è altrettanto ricco come sei abituato (ma assicurati di leggere MVVM di Josh Smith articolo - normalmente devi abilitare / disabilitare i tuoi comandi manualmente quando lo stato cambia, ma la sua versione attiva automaticamente il tuo codice di abilitazione in background come se fossi abituato a OnUpdate).
• Vuoi le immagini sui menu? Questo è integrato (e neanche lontanamente tanto buggato quanto in WinForms).
• WinForms lascia fuori il proprietario-disegnare su alcuni controlli importanti, ma se stai usando WPF invece, non hai bisogno di owner-draw - se vuoi che i tuoi nodi TreeView abbiano il testo nero seguito da un numero blu tra parentesi, è sufficiente inserirlo nel DataTemplate e funziona, non è necessario il brutto codice di proprietà del proprietario.
• Vuoi i controlli di terze parti? In molti casi, non ne hai bisogno, perché puoi estendere ciò che c'è in WinForms e, sì, gli sviluppatori VCL possono solo sognare.

WPF ha una curva di apprendimento molto ripida, ma se raccogli un buon libro (ad esempio " WPF 4 Unleashed "), ti aiuterà a superare il momento peggiore - e sarai felice di lavorare con un framework che non ti tratterrà come WinForms.

Di solito sono molto sorpreso quando le persone dicono che non hanno avuto una buona esperienza con WPF. Sono uno sviluppatore che è passato da C ++ / MFC a C # / WinForms a C # / WPF. Il passaggio da WinForms a WPF non è stato facile perché l'apprendimento di XAML non è molto semplice, ma una volta acquisito, è una tecnologia eccezionale. Io, per esempio, non posso tornare a WinForms. WPF è semplicemente fantastico.

L'altra cosa che mi dà fastidio è il modo in cui le persone normalmente associano WPF con la sola interfaccia utente. A mio parere è 100 volte migliore rispetto a WinForms in termini di facilità di progettazione dell'interfaccia utente, ma ci sono molti altri motivi per cui ti piacerà usare WPF:

1. UI, ovviamente.
2. Associazioni. Semplicemente magica. La funzione più potente dopo l'interfaccia utente. Le applicazioni LOB ne beneficiano di più.
3. Comandi.
4. Separazione delle preoccupazioni. I progettisti lavorano sul design, programma per programmatori.
5. Proprietà associate. Puoi estendere le funzionalità dei controlli di terze parti senza codice sorgente (sebbene questo punto possa far parte del primo punto).
6. Passaggio facile a Silverlight (sia web che WP7)

Potresti non essere d'accordo con me sull'ultimo punto come ragione per imparare WPF, ma se me lo chiedi, è uno dei più grandi. Si impara WPF, è possibile passare facilmente a Silverlight. Silverlight sta diventando grande ed è anche una tecnologia eccezionale.

E la ragione principale è, è il futuro. Potrebbe essere unito a Silverlight ma le abilità rimarranno le stesse.

Quindi ti consiglio caldamente di seguire la via WPF.

Chiaramente WPF è il modo di pensare in futuro. Padroneggiarlo è difficile, ma la piattaforma è molto ben progettata e flessibile.

Alcuni consigli:

• Inizia facile: non provare a implementare il tuo primo progetto usando solo MVVM o animazioni fantasiose. Inizia semplice con Windows, pulsante ed elenchi.
• Approfitta di DataBinding.
• Compra il libro WPF Unleashed di Adam Nathan.

Prima di tutto devo ricordare che sono principalmente uno sviluppatore di asp.net, anche se in passato ho già utilizzato molte winform. Il passaggio a WPF non è così grande come lo si sta facendo (imo) dopo circa una settimana (40+ ore), la maggior parte è stata di nuovo una seconda natura.

Comunque credo che Anders Hejlsberg sia uno degli architetti dietro WPF, almeno secondo gli editori di questo libro- >

" Come uno degli architetti dietro WPF, Chris Anderson spiega abilmente non solo il" come ", ma anche il" perché ". Questo libro è una risorsa eccellente per chiunque desideri comprendere i principi di progettazione e le migliori pratiche di WPF. " -Anders Hejlsberg, tecnico, Microsoft Corporation

link

Winforms è quasi identico allo sviluppo di Delphi. E, naturalmente, c'è una ragione per questo. Proprio come il modello di oggetti Delphi / Object Pascal ha influenzato pesantemente C #, quindi il sistema dei moduli ha influenzato Winforms.

WPF sembra essere la direzione verso cui vanno le cose; è stato detto che la (bellissima!) UI VS2010 è basata su WPF, a differenza delle generazioni precedenti create su Winforms.

Se vuoi rimanere nella tua zona di comfort, vai con winforms. Se vuoi essere catturato dalle ultime novità & il più grande, immergiti nella WPF.

Non sono un programmatore Delphi, ma sì, ho lavorato sia su WinForm (pesantemente) che su WPF (meno che moderato). Sono d'accordo con te in una certa misura sul livello di frustrazione per qualcuno che sta facendo un passaggio da WinForm a WPF come mi sono trovato in quella situazione, ma solo fino a quando non mi sono abituato. Scopri e vedi quanto è meraviglioso e flessibile con WPF rispetto a WinForm. Ha una pesante curva di apprendimento, almeno per qualcuno che proviene dallo sfondo di Delphi, e non da Winform. Per te, vale sicuramente la pena di passare a WPF piuttosto che a WinForm, e ne vale la pena.

Potresti esaminare i seguenti collegamenti per iniziare con:

• link
• link
• link

Avevo lavorato su Windows Form (principalmente su Pocket PC), oltre ad altri ambienti non.NET che utilizzavano gli stessi principi. Quando mi sono trasferito a WPF circa tre anni fa, per i primi mesi lo stavo giurando. Alla fine è solo "scattato" e non mi sono voltato indietro - anzi, sarei stato stanco se il mio prossimo progetto mi richiedesse di tornare a Windows Form.

L'ultima volta che Windows Form è stato aggiornato è stato nel 2005 (VS 2005.) È ancora lì, ma non viene più migliorato da Microsoft. WPF è il nuovo capretto sul blocco per le app desktop, quindi se hai intenzione di passare alla piattaforma .NET utilizzando gli strumenti di MS, allora direi che è una scommessa sicura. Alcune persone spingono Silverlight come soluzione desktop, ma quando l'ho esaminato come una possibilità, ho scoperto che aveva troppe limitazioni (che possono avere senso in un contesto web, ma non così tanto sul desktop.)

Bottom line: c'è una curva di apprendimento ripida e sto ancora imparando. Ma ne valeva assolutamente la pena. È molto divertente.

Se vuoi scrivere nuove applicazioni da zero, usare WinForms sarebbe un errore. È praticamente morto da una prospettiva di investimento. Microsoft lo manterrà a lungo, ma non avrai nuove funzionalità o nuovi supporti, ecc. WPF è la chiara direzione per le applicazioni desktop per il futuro sulla piattaforma MS.

Dal punto di vista della carriera, sei anche molto meglio di conoscere WPF contro WinForms. Per le stesse ragioni sopra. Inoltre, avrai un buon vantaggio nell'apprendimento di Silverlight. C'è una tonnellata di sovrapposizione tra queste due piattaforme.

E infine, WPF è semplicemente più divertente. E più potente.

La curva di apprendimento è più ripida, te lo concedo. Ma alla fine è più gratificante.

Un'ulteriore considerazione che dovrebbe essere menzionata è che non c'è nessun piano per il supporto WPF in mono . Mi rendo conto che non hai indicato alcun interesse nel supporto (mono) multipiattaforma, ma potrebbe esserci un'opportunità per questo nel tuo futuro (se vai con Winforms). Presumibilmente, il supporto per WPF in mono (o simili) arriverà.

modifica: come indicato dal link che ho fornito, e il commento di Gulshan ha evidenziato, Moonlight è uno sforzo open-source guidato dal team mono per fornire il supporto Silverlight multipiattaforma .

Ero emozionato quando ho sentito parlare di WPF, l'idea mi è sembrata fantastica, e tutto ciò che ho visto è stato bellissimo. Tuttavia, quando sono venuto a usarlo in Visual Studio 2008 (ammettiamolo, una beta) ho trovato frustrante e bizzarro lavorare con il designer / IDE.

Ho pubblicato alcune informazioni sul mio blog al momento:
link
link

Non l'ho provato nel 2010, anche se ho parlato con alcune persone che hanno, e sembra che sia ancora un po 'complicato / fastidioso da affrontare.

Penso che la tua applicazione sembrerebbe senza dubbio migliore in WPF, ma penso anche che ti ci vorrà più tempo per costruire e ti sbatterà la testa molto lungo la strada.