A molti l'introduzione di WIN RT potrebbe suggerire un ritorno alle tanto famigerate COM, ma in realtà non è cosi... vediamo perchè...
WIN RT è l'acronimo di Windows Runtime ed è il nuovo framework introdotto da Microsoft per lo sviluppo di applicazioni per Windows 8.
In sostanza WIN RT si pome come obbiettivo quello di creare un layer per le app metro style sul quale si puó sviluppare utilizzando il lunguaggio preferito:
- C/C++
- C#/VB
- Javascript (Chakra)
Vi chiederete com'è possibile sviluppare con lunguaggi diversi sopra questo runtime.. beh dobbiamo dire grazie alle projections (il nuovo modo di Microsoft di chiamare il binding fatto quando invocavamo le nostre COM attraverso dllImport) che permottono a WINRT di esporre le proprie API ai diversi linguaggi di programmazione.
Le carattteristiche fondamentali di WIN RT sono:
- Le API sono state pensate per essere asincrone (vi ricordo che l'UI su WINRT è gestita da un unico thread che obbliga TUTTE le API con tempi di risposta superiori a 50 millisecondi ad essere eseguite in modo asincrono
- Le API sono esposte attraverso il formato ECMA 335 che vi ricordo è approvato come ISO/IEC 23271.
- Le API di WINRT sono epurate da tutte le problematiche avute in passato con COM in quanto ora vengono gestite localmente ad ogni applicazione.. quindi addio problemi di versionin, etc..
- WIN RT gestisce il sandboxing delle applicazioni che vengono eseguite in un'area confinata di memoria, quindi un crash di un'applicazione non inficerà mai il sistema operativo..
- Se sviluppiamo in C# / VB.NET ricordiamoci che avremo a disposizione un subset limitato delle BCL
- Le componenti sono salvate in file con estensione .winmd
Tutte queste caratteristiche ci consentono di realizzare applicazioni dove fluidità e sicurezza la fanno da padrone senza doverci preoccupare di come WINRT si interfaccia al sistema core (vi ricordo che WIN RT supporta sia piattaforme Intel x86/x64 che ARM)
Inoltre se da un lato WIN RT ci obbliga a dover scrivere applicazioni realizzando praticamente solo metodi asincroni ( e volenti o nolenti quest'obbligo prevede una rivisitazione del nostro stile di programmazione) il framework 4.5 ci viene incontro con l'implementazione di nuovi costrutti delle TPL (Task Paralle Library).
Questi costrutti ci consentono di scrivere codice leggibile grazie ai due nuovi operatori ASYNC e AWAIT che permettono a WINRT di comprendere che un metodo è asincrono e che la risposta della chiamata è asincrona.. facendoci dimenticare la difficoltà di lettura di un codice pieno di callback...
CONCLUSIONI FINALI:
Poiché la mia tesi si occupava dell'interoperabilità tra COM e .NET posso dire che COM ha poco o nulla a che vedere con la filosofia di WINRT anche se ne riprende alcuni aspetti.
Mi sento infine di tranquillizzare i DEV che ho sentito "impauriti" da questo approccio allo sviluppo di applicazioni native per windows 8.
P:S:
Ora non vi resta altro che prendere dimestichezza con questo nuovo approccio di sviluppo software.. e pubblicare la vostra prima app sullo store.. good luck !
Quando utilizziamo un approccio Model First, abbiamo a disposizione due differenti approcci per la gestione dell'ereditarietà delle nostre entità:
- Table-per-type: Vengono utilizzate differenti tabelle per ogni tipo nell'albero gerarchico dell'ereditarietà
- Table-per-hierarchy: Viene utilizzata una sola tabella per lo storage dei differenti tipi nell'albero gerarchico dell'ereditarietà.
Entity framework utilizza un approccio table-per-type e ovviamente la chiave primaria di una tabella che rappresenta un'entità derivata è anche foreign key nella tabella che rappresenta l'entità padre.
Utilizzando WCF in modo abbastanza spinto mi è capitato di dover sfruttare della memoria allocata in RAM cercando di annullare l'overhead del caricamento in RAM dei dati.
In questo caso mi è venuta in aiuto la classe ServiceBehaviour, in particolar modo decorando il mio servizio con l'attributo
[ServiceBehaviour(InstanceContextMode=InstanceContextMode.Single)] ho ottenuto il risultato desiderato, implementando il pattern Singleton.
Si devono fare alcune considerazioni su "InstanceContextMode.Single" , in primis per poterlo utilizzare in modo sensato è necessario un binding di tipo ws in quanto è necessario una comunicazione dual way tra service e chiamante, in particolar modo il nostro service necessita di riconoscere il chiamante, quindi scordiamoci (ma scordiamocelo anche in generale) di usare un binding di tipo basic.
Sono disponibili altri valori per l'enumeratore InstanceContextMode in particolare:
- InstanceContextMode.Single
- InstanceContextMode.PerSession
- InstanceContextMode.Per call
Se proprio volete usare un binding di tipo basic l'unico tipo di InstanceContextMode che ha senso è il PerCall.
E' facile intuire come nel caso del valore PerSession venga istanziata una classe del nostro servizio per ogni sessione
mentre nel caso del valore PerCall venga istanziata una classe del nostro servizio ad ogni chiamata.
(In realtà non è proprio così ma in soldoni succede questo...)
Quando impostate il valore dell' InstanceContextMode su Single fate molta attenzione poichè se non impostate il valore del parametro ConcurrencyMode su Multiple verrà processato un messaggio alla volta.
Alla prossima..
Erano circa cinque anni fa o forse piu' quando decisi che i database relazionali con l'evoluzione del concetto di dominio , domain model e programmazione ad oggetti mi stavano veramente stretti.
Così decisi di creare una sorta di mio database noSQL serializzando i miei oggetti e storandoli in db, piuttosto che in files.
Successivamente iniziai a creare un mio layer DAL notando che le performance una volta che l'oggetto era in RAM erano superiori a qualsiasi db relazionale e soprattutto la scalabilità orizzontale era senza limiti.
Ora noto con piacere che NoSql db stanno crescendo in modo esponenziale e sono sempre piu` convinto che avranno sempre maggior successo.
Ho portato questa mia esperienza anche in ambiente enterprise e con un notevole abbattimento dei costi HW/SW ho ottenuto risultati stratosferici..
Quest'anno lo dedichero` allo studio di Mongo , uno dei db noSQL che reputo di maggior qualità.
Vedremo...