Buongiorno a tutta la ML.
Sto cercando di capire la tecnologia che molti di voi sembrano aver già "sposato".
In effetti mi sembra un pò inutile continuare sulla linea WinForm e quindi eccomi a scrivere per avere qualche delucidazione.
A furia di leggere post, blog, esempi, ecc ho l'impressione di essermi perso, quindi riassumo ciò che mi sembra di aver capito fin ora.

-C'è una persona (che può essere anche il programmatore stesso), che con i tool di VS o Blend disegna il front-end dell'applicazione.
-C'è una parte "di mezzo" fra la grafica e l'applicazione.
-Alla fine c'è l'applicazione.

I dubbi mi nascono in ognuno di questi tre punti.
1) Come può il programmatore iniziare a programmare eventi/procedure legate agli eventi, comandi,ecc se non ha a disposizione la grafica? La grafica dev'essere già pronta prima di iniziare?
2) La parte di disconnessione fra grafica e applicazione è rappresentata da XAML o da MVVM?
Sui libri che ho letto non c'è nessun riferimento alla tecnologia MVVM, ma sembra linea comune "l'osannazione" al XAML per quanto concerne la disconnessione delle due parti. Sui vari blog/siti invece si parla solo di MVVM. Quale logica seguire?
3)L'applicazione che si crea può essere strutturata come nella tecnologia WinForm o segue regole diverse? Mi spiego, mentre con WinForm il codice che genero è facilmente scomponibele, per poterlo leggere/revisionare, con WPF, ad ogni singola finestra, corrisponde un solo file di codice nomeapp.XAMl.VB oppure è possibile scomporrlo in più files?

Spero di essere stato chiaro ad esporre i miei dubbi.

Ottimo spunto di riflessione. Queste domande mi piacciono dato che la tecnica si impara facilmente ma l'arte no... Quindi spero che gente del calibro di Alessandro dia una propria idea...

Provo a rispondere:

1) Credo che l'interfaccia il programmatore debba averla/farsela. Quindi un interfaccia stupida con bottoni grigi, combo grigie ecc ecc credo debba esistere. Del resto spesso parlo con persone che dicono "voglio un albero di elementi che ci clicco sopra poi appare di fianco una lista, seleziono gli oggetti e dal menu salvo gli oggetti" = interfaccia.
2) Xaml o MVVM... entrambi. Il fatto è che è XAML (e in genere WPF) che spinge verso l'utilizzo del pattern MVVM e MVVM si sposa molto bene con WPF.
3) Non ho ben capito la domanda. Se parli di MVVM succede spesso che xxxx.xaml.cs sia vuoto e che la maggior parte delle cose venga fatta a livello di ViewModel.

Come già detto, spero che persone più influenti intervengano in questa discussione.

Non sono sicuramente del calibro di Alessandro Del Sole, però proverò a rispondere ad una domanda.

1) Come può il programmatore iniziare a programmare eventi/procedure legate agli eventi, comandi,ecc se non ha a disposizione la grafica? La grafica dev'essere già pronta prima di iniziare?

- Con wpf si può scrivere una routine che risponda ad un evento senza specificare l'oggetto gestore di quell'evento, ad esempio posso scrivere una procedura dove al passaggio del mouse mi restituisca su quale oggetto effettivamente sono con il mouse, questo grazie eventi routed, e anche al fatto che posso in un secondo momento, sul lato xaml, decidere quali controlli debbano attivarsi all'evento da me scelto.

3) L'applicazione che si crea può essere strutturata come nella tecnologia WinForm o segue regole diverse? Mi spiego, mentre con WinForm il codice che genero è facilmente scomponibele, per poterlo leggere/revisionare, con WPF, ad ogni singola finestra, corrisponde un solo file di codice nomeapp.XAMl.VB oppure è possibile scomporrlo in più files?

- Onestamente non ho capito cosa intendi per scomporre il codice in più file... creare delle classi?

Allora, inizio col ringraziare entrambi per le risposte. Premetto che mi sono visto e rivisto codice e logica dei 4 articoli di Alessandro del Sole, che ho rifatto il tutto applicandolo ad un caso più o meno reale, che continuo a cercare di documentarmi su quale sia l'approccio migliore...considerando che su due sole risposte sole sia un pò inutile trarre conclusioni;

1) leggo che alla prima domanda avete opinioni diverse (quindi, sfortunatamente per me, siete in linea con quanto fin'ora ho trovato in rete!).Questo punto per fortuna rappresenta il minore dei miei mali! :-)

2) provando ad applicare il pattern MVVM alla mia situazione reale (ho una classe che fa una lettura in streaming da alcuni file), legare in binding proprietà grafiche a variabili che si compilano in run-time e con tempi non prevedibili fa si che la grafica dell'applicazione sia quantomeno penosa a livello di refresh. (Sicuramente sto sbagliando qualcosa nella filosofia...anche se devo ancora capire dove!).

3)Vediamo se riesco a spiegarmi...Ovviamente non mi riferisco alle classi qundo dico "scomporlo", in effetti la domanda è posta veramente male, scusate!
Le applicazione MDI, i plug-in negli assembly o più semplicemente le applicazioni a tre livelli in WPF sono realizzabili?

Ma non sono d'accordo con la tua conclusione sul punto 1... Secondo me le due risposte date si "assomigliano/completano". Io parlavo di interfaccia nel senso di "idea di interfaccia". Anche perchè MAX dice "al passaggio del mouse mi restituisce..." cosa??? dipende quello che devi fare. Ed è lì che io intendevo interfaccia grafica. Dopo, saputo che esiste il comando (=ICommand) per salvare, lego il mio comando ad un bottone, ad un elemento nel menu, ad un bottone nella ribbon, al mouse che esce dal form, alla nonna che fa gli gnocchi ecc ecc.
Per il punto 2 non saprei cosa dirti...
MDI non è "supportato" di default, però esistono molti articoli che ne parlano. Personalmente non mi piace... qui c'è un esempio: (http://wpfmdi.codeplex.com/)
Non capisco il significato di "plugin negli assembly".
Perchè non si possono fare? Vorrei far ricordare che MVVM non è un obbligo. E' possibilissimo continuare ad usare lo stesso metodo che si aveva con WinForm senza problemi; Basta mettere la proprietà x:Name a tutti i controlli e il gioco è fatto. MVVM è una opportunità e basta (se per questo a volte credo sia anche usata in modo eccessivo).

Penso che stiamo andando fuori rotta.
Il topic si introduce con:

-In effetti mi sembra un pò inutile continuare sulla linea WinForm e quindi eccomi a scrivere per avere qualche delucidazione.

Secondo me questo non è vero, infatti tutto dipende da quello che vuoi fare o che devi fare, infatti le wpf sono nate con l'intento di separare l'arte della grafica da quella della programmazione.
Infatti,la scrittura del codice, all'incirca non ha avuto grossi cambiamenti, apparte l'introduzione di alcune nuove utili classi.
Mentre la parte grafica è tutto un nuovo mondo, tanto è vero che microsoft ha messo a disposizione alcuni software per occuparsi esplicitamente e solamente di grafica(es. blend), in modo tale che una persona esperta di disegno grafico, sia capace di realizzare template o qualsivoglia e passarlo al programmatore, il quale si interfaccierà e realizzerà il programma seguendo o non seguendo la parte grafica.

Questo per dire che si può fare un programma in wpf senza realizzare la parte grafica e aspettare che una seconda persona ci passi i controlli disegnati a cui assegnare la parte dinamica. Quindi programmi e siti internet potranno essere sviluppati in parallelo.

Sicuramente le wpf usano classi per realizzare una grafica avanzata che si basa su directX, quindi si potrà realizzare con più semplicità e miglior risultati, lavori in 2D,3D,animazioni.

Questo è quello che ho capito io, da questa tecnologia.
Ora resta a te cercare di individuare se questa tecnologia fa al caso tuo.

Se per esempio devi realizzare programmi per i missili dei caccia, direi proprio che sbagli linguaggio e tecnologia

Se devi realizzare un programma standalone leggerissimo privo di grafica... ti consiglio qualcosa che non abbia il framework, oppure di usare le vecchie form che già conosci senza spendere troppo tempo in questa nuova tecnolgia.

Ricorda che passare ad una nuova tecnologia, vuol dire perdere molto tempo ad impararla, e altro tempo a fare esperienza per metterla in pratica. Se sei già ben avviato con le WinForm e non hai bisogno delle wpf, alleggerisci il carico di studio e continua a lavorare con la tecnolgia che più ti aggrada finchè potrai.

Ringrazio nuovamente i miei due interlocutori e mi scuso per il ritardo nella mia risposta.
Inizio quotando Roberto Sarati

Secondo me le due risposte date si "assomigliano/completano".

Si sono d'accordo, volevo solo sottolineare come in effetti non sia diffusa una metodica univoca, forse dipende anche dal fatto che la tecnologia è relativamente recente.
Grazie anche per il link sulle MDI app.

Max

Se per esempio devi realizzare programmi per i missili dei caccia, direi proprio che sbagli linguaggio e tecnologia

Ma dalle tue parti vanno a caccia con i missili????Poveri animali!
Ovviamente scherzo...lungi da me il voler far polemica...qui ho solo da imparare....

L'applicazione che vorrei realizzare si appoggia a diversi db (e in formato diverso fra loro), attraverso una serie di schermate (grafiche) configura un impianto di tipo siderurgico.L'applicazione dovrebbe essere localizzata, ma per questo mi sa che è meglio aprire un altro tread....Anche se questo argomento ho trovato numerose opinioni contrastanti...mha...staremo a vedere cosa combino...

Cmq per chiudere questo tread, dopo quasi tre settimane di lettura/studio,googleggiando qua e là, credo che sia la tecnologia da usare...Con questo non dico di aver sviscerato tutto l'argomento, ma almeno mi sono fatto un'idea.