.NET senza stereotipi http://blogs.ugidotnet.org/marcofarina/Default.aspx vediamoci chiaro.. it Marco Farina Subtext Version 2.6.0.0 .NET senza stereotipi http://blogs.ugidotnet.org/images/RSS2Image.gif http://blogs.ugidotnet.org/marcofarina/Default.aspx 77 60 WIN RT ritorno al passato?? no, salto nel futuro !! http://blogs.ugidotnet.org/marcofarina/archive/2013/02/12/win-rt-ritorno-al-passato-no-salto-nel-futuro.aspx <p>A molti l'introduzione di WIN RT potrebbe suggerire un ritorno alle tanto famigerate COM, ma in realtà non è cosi... vediamo perchè...</p> <p>WIN RT è l'acronimo di Windows Runtime ed è il nuovo framework introdotto da Microsoft per lo sviluppo di applicazioni per Windows 8.</p> <p>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: </p> <ul> <li>C/C++</li> <li>C#/VB</li> <li>Javascript (Chakra)</li> </ul> <p>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. </p> <p>Le carattteristiche fondamentali di WIN RT sono:</p> <ul> <li>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</li> <li>Le API sono esposte attraverso il formato ECMA 335 che vi ricordo è approvato come ISO/IEC 23271.</li> <li>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..</li> <li>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..</li> <li>Se sviluppiamo in C# / VB.NET ricordiamoci che avremo a disposizione un subset limitato delle BCL</li> <li>Le componenti sono salvate in file con estensione .winmd </li> </ul> <p>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)</p> <p>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).</p> <p>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...</p> <p><strong><u>CONCLUSIONI FINALI:</u></strong></p> <p>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.</p> <p>Mi sento infine di tranquillizzare i DEV che ho sentito "impauriti" da questo approccio allo sviluppo di applicazioni native per windows 8.</p> <p>P:S:</p> <p>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 !</p><img src="http://blogs.ugidotnet.org/marcofarina/aggbug/101439.aspx" width="1" height="1" /> Marco Farina http://blogs.ugidotnet.org/marcofarina/archive/2013/02/12/win-rt-ritorno-al-passato-no-salto-nel-futuro.aspx Tue, 12 Feb 2013 01:00:00 GMT http://blogs.ugidotnet.org/marcofarina/archive/2013/02/12/win-rt-ritorno-al-passato-no-salto-nel-futuro.aspx#feedback 397 http://blogs.ugidotnet.org/marcofarina/comments/commentRss/101439.aspx http://blogs.ugidotnet.org/marcofarina/services/trackbacks/101439.aspx Table Inheritance http://blogs.ugidotnet.org/marcofarina/archive/2012/02/08/table-inheritance.aspx <p>Quando utilizziamo un approccio Model First,  abbiamo a disposizione due differenti approcci per la gestione dell'ereditarietà delle nostre entità:</p> <ul> <li><strong>Table-per-type</strong>: Vengono utilizzate differenti tabelle per ogni tipo nell'albero gerarchico dell'ereditarietà</li> <li><strong>Table-per-hierarchy</strong>: Viene utilizzata una sola tabella per lo storage dei differenti tipi nell'albero gerarchico dell'ereditarietà.</li> </ul> <p>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.</p> <p> </p><img src="http://blogs.ugidotnet.org/marcofarina/aggbug/100762.aspx" width="1" height="1" /> Marco Farina http://blogs.ugidotnet.org/marcofarina/archive/2012/02/08/table-inheritance.aspx Wed, 08 Feb 2012 21:30:41 GMT http://blogs.ugidotnet.org/marcofarina/archive/2012/02/08/table-inheritance.aspx#feedback 1531 http://blogs.ugidotnet.org/marcofarina/comments/commentRss/100762.aspx http://blogs.ugidotnet.org/marcofarina/services/trackbacks/100762.aspx InstanceContextMode http://blogs.ugidotnet.org/marcofarina/archive/2012/01/24/instancecontextmode.aspx <p>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.</p> <p>In questo caso mi è venuta in aiuto la classe ServiceBehaviour, in particolar modo decorando il mio servizio con l'attributo </p> <p>[ServiceBehaviour(InstanceContextMode=InstanceContextMode.Single)] ho ottenuto il risultato desiderato, implementando il pattern Singleton.</p> <p>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 (<strong>ma scordiamocelo anche in generale</strong>) di usare un binding di tipo basic.</p> <p>Sono disponibili altri valori per l'enumeratore InstanceContextMode in particolare:</p> <ul> <li>InstanceContextMode.Single</li> <li>InstanceContextMode.PerSession</li> <li>InstanceContextMode.Per call</li> </ul> <p>Se proprio volete usare un binding di tipo basic l'unico tipo di InstanceContextMode che ha senso è il PerCall.</p> <p>E' facile intuire come nel caso del valore PerSession venga istanziata una classe del nostro servizio per ogni sessione</p> <p>mentre nel caso del valore PerCall venga istanziata una classe del nostro servizio ad ogni chiamata.</p> <p>(In realtà non è proprio così ma in soldoni succede questo...)</p> <p>Quando impostate il valore dell' InstanceContextMode  su Single fate molta attenzione poichè se non impostate il valore del parametro  <span xmlns="http://www.w3.org/1999/xhtml">ConcurrencyMode su Multiple verrà processato un messaggio alla volta.</span></p> <p><span xmlns="http://www.w3.org/1999/xhtml">Alla prossima..</span></p><img src="http://blogs.ugidotnet.org/marcofarina/aggbug/100727.aspx" width="1" height="1" /> Marco Farina http://blogs.ugidotnet.org/marcofarina/archive/2012/01/24/instancecontextmode.aspx Tue, 24 Jan 2012 15:41:29 GMT http://blogs.ugidotnet.org/marcofarina/archive/2012/01/24/instancecontextmode.aspx#feedback 540 http://blogs.ugidotnet.org/marcofarina/comments/commentRss/100727.aspx http://blogs.ugidotnet.org/marcofarina/services/trackbacks/100727.aspx No sql DB http://blogs.ugidotnet.org/marcofarina/archive/2012/01/19/no-sql-db.aspx <p>Erano circa cinque anni fa o forse piu'<font size="2"> quando decisi che i database relazionali con l'evoluzione del concetto di dominio , domain model e programmazione ad oggetti mi stavano veramente stretti.</font></p> <p><font size="2">Così decisi di creare una sorta di mio database noSQL serializzando i miei oggetti e storandoli in db, piuttosto che in files.</font></p> <p><font size="2">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.</font></p> <p><font size="2">Ora noto con piacere che NoSql db stanno crescendo in modo esponenziale e sono sempre piu` convinto che avranno sempre maggior successo.</font></p> <p><font size="2">Ho portato questa mia esperienza anche in ambiente enterprise e con un notevole abbattimento dei costi HW/SW ho ottenuto risultati stratosferici..</font></p> <p><font size="2">Quest'anno lo dedichero` allo studio di Mongo , uno dei db noSQL che reputo di maggior qualità.</font></p> <p><font size="2">Vedremo...</font></p><img src="http://blogs.ugidotnet.org/marcofarina/aggbug/100711.aspx" width="1" height="1" /> Marco Farina http://blogs.ugidotnet.org/marcofarina/archive/2012/01/19/no-sql-db.aspx Thu, 19 Jan 2012 11:34:16 GMT http://blogs.ugidotnet.org/marcofarina/archive/2012/01/19/no-sql-db.aspx#feedback 1766 http://blogs.ugidotnet.org/marcofarina/comments/commentRss/100711.aspx http://blogs.ugidotnet.org/marcofarina/services/trackbacks/100711.aspx