WPF vs. WinForms: la prospettiva di un programmatore Delphi?

Ho letto la maggior parte dei principali thread su WPF vs. WinForms e mi ritrovo bloccato nella sfortunata ambivalenza in cui puoi cadere quando decidi tra la tecnologia precedente collaudata e vera (Winforms), ed è il suo successore (WPF).

Sono un programmatore veterano di Delphi di molti anni che sta finalmente facendo il salto in C #. I miei colleghi programmatori Delphi là fuori capiranno che sono entusiasta di sapere che Anders Hejlsberg, di fama Delphi, era l'architetto dietro C #. Ho una forte dipendenza dai componenti personalizzati VCL di Delphi, in particolare quelli coinvolti nella creazione di procedure guidate e componenti multi-step che fungono da contenitore per i componenti figlio.

Con questo background, spero che quelli di voi che sono passati da Delphi a C # possano aiutarmi con la mia decisione WinForms vs. WPF per aver scritto le mie domande iniziali. Nota, sono molto impaziente quando la codifica e cose come il completo completamento automatico e il corretto supporto del debugger possono creare o distruggere un progetto per me, inclusa la possibilità di trovare informazioni prontamente disponibili sulle funzionalità e sulle chiamate dell'API e, ancora di più, soluzioni alternative per i bug .

I thread e i commenti SO all'inizio dell'intervallo di date del 2009 mi preoccupano molto di WPF quando si tratta di potenziali frustrazioni che potrebbero rovinare il mio codice di sviluppo dell'interfaccia utente C #. D'altro canto, dedicare una quantità eccessiva di tempo all'apprendimento di una tecnologia API che, anche se non viene abbandonata, sarà presto sostituita (WinForms), è ugualmente preoccupante e trovo allettante il supporto GPU in WPF.

Da qui la mia ambivalenza. Dato che non ho ancora imparato nessuna delle due tecnologie, ho una rara opportunità di ricominciare da capo e di non dover affrontare la grande curva del "disimparare" che ho visto menzionare in vari thread quando un programmatore di WinForms passa a WPF. D'altra parte, se usare WPF sarà troppo frustrante o avrà altre importanti conseguenze negative per uno sviluppatore RAD impaziente come me, allora continuerò a utilizzare WinForms fino a quando WPF raggiungerà lo stesso livello di supporto e facilità d'uso. Per darvi un esempio concreto della mia psicologia come programmatore, ho usato VB e successivamente Delphi per evitare del tutto il vero dolore della codifica con MFC, una libreria UI di Windows che molti sviluppatori hanno sofferto durante lo sviluppo di prime app di Windows. Non mi sono mai pentito della mia fortuna nell'evitare l'MFC.

Sarebbe anche confortante sapere se Anders Hejlsberg avesse una mano nell'architettura di WPF e / o WinForms e se ci fossero disparità nella visione creativa e nella facilità d'uso incorporate in entrambe le basi di codice. Infine, per i programmatori Delphi di nuovo, fammi sapere quanto "IDE schock" mi piace quando uso WPF rispetto a WinForms, specialmente quando si tratta di supporto per il debugger. Anche i commenti sul mercato del lavoro aggiornati per il 2011 sarebbero apprezzati.

Se hai un background in Delphi, rimarrai deluso da WinForms. Proverai a fare cose facili nel VCL, solo per scoprire che sono dolorosamente difficili o addirittura impossibili. WPF sarà molto meno limitato.

Ad esempio, ecco alcune delle limitazioni di WinForms che abbiamo riscontrato:

• WinForms non ha nulla di paragonabile a TAction, quindi se sei abituato a programmare con azioni, condividere 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 ... odierai WinForms, dove devi fare tutto ciò in modo duro e soggetto a errori.
• Il vecchio MainMenu di WinForms (.NET 1.0 vintage) non supporta le immagini accanto alle voci di menu e il nuovo MenuStrip (introdotto in .NET 2.0) è pieno di bug che Microsoft rifiuta di correggere (perché le correzioni potrebbero compromettere la compatibilità con le versioni precedenti).
• Molti controlli, ad esempio TreeView, sono dolorosamente mal funzionanti rispetto alle loro controparti VCL (dolorosamente lenti, nessun disegno del proprietario, molte opzioni di personalizzazione mancanti, ecc.)
• Non c'è niente 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 le paghi - offerte gratuite come VirtualTreeView non sono disponibili per WinForms.

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

• Vuoi qualcosa come TAction? WPF ha ICommand, che è altrettanto ricco di quello a cui sei abituato (ma assicurati di leggere l'articolo MVVM di Josh Smith - normalmente devi abilitare / disabilitare i comandi manualmente quando lo stato cambia, ma la sua versione attiva automaticamente il tuo codice di abilitazione sullo sfondo come se fossi abituato con OnUpdate).
• Vuoi immagini sui menu? È integrato (e in nessun luogo vicino come buggy come in WinForms).
• WinForms lascia il disegno del proprietario su alcuni controlli importanti, ma se invece usi WPF, non hai bisogno del disegno del proprietario - se vuoi che i tuoi nodi TreeView abbiano il testo nero seguito da un numero blu tra parentesi, devi solo inseriscilo nel tuo DataTemplate e funziona, non è necessario alcun brutto codice per il proprietario.
• Desideri controlli di terze parti? In molti casi, non ne hai bisogno, perché puoi estendere ciò che è lì in modi WinForms e, sì, gli sviluppatori VCL possono solo sognare.

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

Di solito sono molto sorpreso dalle persone che affermano di non aver 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é imparare XAML non è molto semplice, ma una volta acquisito, è una tecnologia fantastica. 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 a una sola interfaccia utente. È davvero 100 volte migliore di WinForms secondo me in termini di facilità di progettazione dell'interfaccia utente, ma ci sono molte altre ragioni per cui adorerai usare WPF:

1. UI, ovviamente.
2. Attacchi. Solo pura magia. La funzionalità più potente dopo l'interfaccia utente. Le applicazioni LOB ne traggono maggiori vantaggi.
3. Comandi.
4. Separazione degli interessi. I designer lavorano alla progettazione, al programma dei programmatori.
5. Proprietà associate. È possibile estendere la funzionalità dei controlli di terze parti senza codice sorgente (anche se questo punto può far parte del primo punto).
6. Facile passaggio a Silverlight (sia Web che WP7)

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

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

Quindi, ti consiglio vivamente di seguire la strada del WPF.

Chiaramente WPF è la strada da percorrere per pensare in futuro. Padroneggiare è difficile, ma la piattaforma è molto ben progettata e flessibile.

Alcuni consigli:

• Inizia facilmente: non provare a implementare il tuo primo progetto usando solo MVVM o animazioni fantasiose. Inizia semplice con finestre, pulsanti ed elenchi.
• Approfitta di DataBinding.
• Acquista il libro WPF Unleashed di Adam Nathan.

Dovrei prima notare che sono principalmente uno sviluppatore asp.net, anche se ho già usato molte forme di win in precedenza. Il passaggio a WPF non è così grande come lo stai facendo (imo) dopo circa una settimana (oltre 40 ore), la maggior parte era di nuovo di 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 voglia comprendere i principi di progettazione e le migliori pratiche di WPF. "–Anders Hejlsberg, collega tecnico, Microsoft Corporation

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Winforms è quasi identico allo sviluppo di Delphi. E, naturalmente, c'è una ragione per questo. Proprio come il modello a oggetti Delphi / Object Pascal ha fortemente influenzato C #, così il sistema di forme ha influenzato Winforms.

WPF sembra essere la direzione in cui le cose sono dirette; è stato detto che la (splendida!) interfaccia utente VS2010 è basata su WPF, a differenza delle generazioni precedenti che sono state costruite su Winforms.

Se vuoi rimanere nella tua zona di comfort, scegli winforms. Se vuoi rimanere aggiornato sulle ultime novità, immergiti in WPF.

Non sono un programmatore Delphi, ma sì, ho lavorato sia su WinForm (pesantemente) che su WPF (meno che moderato). Concordo con te in una certa misura sul livello di frustrazione per qualcuno che passerebbe da WinForm a WPF visto che mi trovo in quella situazione, ma solo fino a quando non mi ci abituerò. Scopri quanto è meraviglioso e flessibile con WPF rispetto a WinForm. Ha una forte curva di apprendimento, almeno per qualcuno che proviene dal background di Delfi, e non da Winform. Per te, vale sicuramente la pena spostarsi verso WPF piuttosto che WinForm, e ne vale la pena.

Potresti voler esaminare i link sottostanti per iniziare con:

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

Avevo svolto alcuni lavori su Windows Form (principalmente su Pocket PC), oltre ad altri ambienti non.NET che utilizzavano gli stessi principi. Quando mi sono trasferito alla WPF circa tre anni fa, per i primi mesi lo stavo giurando. Alla fine ha semplicemente "cliccato" e non ho guardato indietro - in effetti sarei sconvolto se il mio prossimo progetto mi richiedesse di tornare a Windows Form.

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

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

Se hai intenzione di scrivere nuove applicazioni da zero, l'utilizzo di WinForms sarebbe un errore. È praticamente morto dal punto di vista degli investimenti. Microsoft lo manterrà a lungo, ma non otterrai nuove funzionalità, né nuovo supporto, ecc. WPF è la direzione chiara per le applicazioni desktop per il futuro sulla piattaforma MS.

Dal punto di vista della carriera, stai anche molto meglio conoscendo WPF vs. WinForms. Per le stesse ragioni sopra. Inoltre, avrai una buona conoscenza dell'apprendimento di Silverlight. C'è una tonnellata di sovrapposizioni tra queste due piattaforme.

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

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

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

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

Ero entusiasta quando ho saputo di WPF, l'idea suonava alla grande e tutto ciò in cui l'ho vista è stato bellissimo. Tuttavia, quando sono arrivato a usarlo in Visual Studio 2008 (è vero, una beta) ho trovato frustrante e bizzarro lavorare con il designer / IDE.

Ho pubblicato alcune informazioni sul mio blog al momento:
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

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 / stare meglio in WPF, ma penso anche che ci vorrà più tempo per la costruzione e ti sbatterai la testa molto lungo la strada.