it-swarm.it

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 .

Le discussioni e i commenti SO all'inizio del 2009 mi preoccupano molto di WPF quando si tratta di potenziali frustrazioni che potrebbero rovinare il mio codice di sviluppo dell'interfaccia utente di C #. D'altra parte, spendere un importo eccessivo di tempo l'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 l'uso di WPF sarà solo troppo frustrante o avrà altre importanti conseguenze negative per un impaziente RAD come me, allora continuerò con 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 programmazione con MFC, un Windows Libreria dell'interfaccia utente che molti sviluppatori hanno sofferto durante lo sviluppo delle prime app di Windows. Non mi sono mai pentito della mia fortuna nell'evitare 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.

38
Robert Oschler

Se hai un background di 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 correzione (perché le correzioni dei bug potrebbero interrompere la compatibilità con le versioni precedenti).
  • Molti controlli, ad es. TreeView, sono terribilmente mal funzionanti rispetto alle loro controparti VCL (dolorosamente lento, 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 articolo MVVM di Josh Smith - 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 sei abituato con OnUpdate).
  • Vuoi immagini sui menu? È integrato (e in nessun luogo vicino come buggy come in WinForms).
  • WinForms lascia il sorteggio del proprietario su alcuni controlli importanti, ma se usi invece WPF, non hai bisogno del sorteggio del proprietario - se vuoi che i tuoi nodi TreeView abbiano il testo nero seguito da un numero blu tra parentesi, lo inserisci semplicemente nel tuo DataTemplate e funziona, non è necessario alcun brutto codice di disegno del 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 es. " WPF 4 Unleashed "), ti aiuterà a superare il peggio - e sarai felice di lavorare con un framework che non ti ostacolerà come WinForms.

21
Joe White

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é l'apprendimento di 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 (sebbene questo punto possa 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.

13
Yogesh

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.
5
Eduardo Molteni

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 migliori pratiche di WPF. ”–Anders Hejlsberg, collega tecnico, Microsoft Corporation

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

4
Spooks

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.

2
3Dave

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 come è 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.

Si consiglia di esaminare i collegamenti seguenti per iniziare con:

2
Kumar

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 è solo "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 potrebbero 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.

1
MetalMikester

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.

1
RationalGeek

Un'ulteriore considerazione che dovrebbe essere menzionata è che non c'è nessun 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 in futuro (se vai con Winforms). Presumibilmente, arriverà il supporto per WPF in mono (o simile).

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

0
Argalatyr