[.NET Framework/Windows API]Gerarchia .NET Framework

[Stobby]

Ciao a tutti,
per motivi di lavoro, sto approcciando da qualche mese alla programmzione in ambiente Windows attraverso il .NET framework, tuttavia, mi sono reso conto che, al di là della immensità del mondo in questione, questo è suddiviso in moltissime sottorealtà che nel tempo sono andate ad essere o rimpiazzate da altre o inglobate da maggiori.

Nella fattispecie, partendo alla ricerca di alcune API di windows ho scoperto che il mondo MS è suddiviso in

- Windows API
- ATL
- Microsoft MFC
- Microsoft Presentation Classes
- altro...

Da quello che ho capito, alcune di queste librerie sono state inglobate/sostituite da altre, altre percorrono vie parallele.
Ora, da programmatore C++ (anche se per poco ancora, il C# arriverà presto), la cosa che sono riuscito a chiarirmi, per il momento, è la differenza di codice gestito (C++\CLI) e non gestito. Avrei tuttavia bisogno di mettere ordine, almeno gerarchico, tra le varie categorie, in modo da poter approfondire in maniera coerente la conoscenza di questo ambito, poiché mi sono reso conto che Visual Studio consente di mescolare C++ gestito e non gestito unitamente ad API, MFC e altro..
Avete qualche link (MSDN parte molto dal presupposto che i rapporti tra le librerie siano già chiari al lettore) da suggerirmi?

Ciao e grazie!

[Kralizek]

non mi sono mai spinto sulla programmazione basso livello di windows anche perchè, se vuoi usare le WinAPI, la portabilità non è un tuo requisito. A questo punto fai di puro .NET e vai con dio :)

O forse ho saltato qualcosa? :)

[Stobby]

L'applicazione funzionerà esclusivamente sotto windows (è un applicativo di test interno), tanto vale che usi il .NET allora..

[DioBrando]

http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/fbd98b43-6f5e-4775-86ba-302df98e0454/

sostanzialmente puoi wrappare le librerie .NET e riutilizzarle in un contesto C++ Managed/MFC ma ormai, davvero, se non ti interessa lavorare a basso livello e non hai requisiti di retrocompatibilità ante litteram, farei direttamente lo switch a .NET.

Windows Forms per la parte grafica e poi boh dipende da che versioni del framework puoi utilizzare. Per la parte di servizi WCF sarebbe tanta roba ma devi avere accesso almeno alla 3.0

[Kralizek]

se deve sviluppare ex-novo, via di .NET 4, WCF + WPF inclusi :)

[Ludo237]

se deve sviluppare ex-novo, via di .NET 4, WCF + WPF inclusi :)

e qualche bella bibbia di Wrox editore :read: :read: ho comprato un manuale su c# 4 che era favoloso!

[DioBrando]

se deve sviluppare ex-novo, via di .NET 4, WCF + WPF inclusi :)

sì ma un po' troppa roba assieme forse? :D

Da MFC/C++ passare allo XAML ed i controlli WPF mi sembra complesso.
Io studierei di più la parte dei servizi con WCF e LINQ poi per carità... :)

[tomminno]

e qualche bella bibbia di Wrox editore :read: :read: ho comprato un manuale su c# 4 che era favoloso!

I libri della Wrox hanno il difetto di essere spesso una enciclopedia di tutti i possibili metodi e proprietà esposti dalla tecnologia trattata.
Praticamente illeggibili e tutto sommato non molto istruttivi.

[tomminno]

Io studierei di più la parte dei servizi con WCF e LINQ poi per carità... :)

Certo che WCF ancora devo capire se hanno senso. Non sono interoperabili se non nei casi veramente basilari.
Se vuoi fare una Soap Authentication si tirano per forza dietro tanti di quegli standard WS-* che nessun altro riesce a dialogarci.
Io tutte le volte che ho dovuto fare un webservice sono dovuto tornare ai cari vecchi asmx, altrimenti gli utilizzatori potevano essere solo client .Net.

Hanno più senso forse i WCF DataService, ma sono praticamente una interfaccia verso i singoli elementi di un db, insomma devi replicare la logica di gestione su tutti i chiamanti, che non ha molto senso, tanto vale usare i tradizionali webservice.

[Kralizek]

Certo che WCF ancora devo capire se hanno senso. Non sono interoperabili se non nei casi veramente basilari.
Se vuoi fare una Soap Authentication si tirano per forza dietro tanti di quegli standard WS-* che nessun altro riesce a dialogarci.
Io tutte le volte che ho dovuto fare un webservice sono dovuto tornare ai cari vecchi asmx, altrimenti gli utilizzatori potevano essere solo client .Net.

Hanno più senso forse i WCF DataService, ma sono praticamente una interfaccia verso i singoli elementi di un db, insomma devi replicare la logica di gestione su tutti i chiamanti, che non ha molto senso, tanto vale usare i tradizionali webservice.

non é colpa di WCF se gli altri non implementano gli standard :D

[Stobby]

Grazie delle molteplici risposte.
Non sono un neofita della programmazione, vengo dalla programmazione in C sui microcontrollori / DSP e ho sempre usato il C++ per la gestione della controparte PC degli hardware implementati.
Generalmente la gestione che utilizzo è legata fondamentalmente all'utilizzo di porte seriali, connessioni TCP/IP, USB e GPIB.. niente di particolarmente complesso.
La scelta di migrare verso il .net è molto legata alla necessità di sviluppare, rapidamente, software di interfaccia compatibile con windows 7 cercando di ridurre il più possibile la stratificazione dei framework utilizzati (no National Instruments, utilizzo di VISA limitato allo stretto indispensabile).

[tomminno]

non é colpa di WCF se gli altri non implementano gli standard :D

Si possono sempre implementare gli standard in maniera da non farsi capire dagli altri ;)