novembre 2004 Blog Posts
Inizialmente era dato per improbabile sino al'RTM, ma ecco che ci arriva l'annuncio. WSE2.0 SP2 funzionerà anche con Visual Studio .NET 2005 beta. Non è ancora previsto il supporto ai 64 bit.
Per molto tempo ho scritto le pagine ASP.NET definendo, pagina per pagina i margini della stessa:
<body topmargin="0" bottommargin="0" leftmargin="0" rightmargin="0">
Ormai, era divenuto meccanico. Un approccio migliore (e probabilmente più corretto) consiste nel definire lo style dell'elemento body comse segue:
body { margin: 0; }
Avendo, di base un CSS comune usato in tutto il sito, diventa chiara la convenienza :-)
La combinazione new virtual può creare un mix pericoloso, come evidenziato da questo post.
Nell'attuale implementazione ASP.NET dei Web Services (serializzazione XML per la precisione) il tipo gYearMonth è mappato sul tipo string. Questa mappatura è stata mantenuta anche nella prossima versione del Framework (2.0). A volte può essere utile mappare implicitamente gYearMonth su un tipo DateTime. In questo post si suggerisce un metodo.
La standardizzazione della codifica sta seguendo un percorso che, di fatto, è accallerato anche con l'avvento di nuovi (ormai non più di tanto nuovi) linguaggi, quali C#. Linguaggio nuovo, vita nuova :-)
Su internet troviamo alcuni documenti (qui, qui, qui e qui) che illustrano le regole che un programmatore dovrebbe seguire. In questo post ho deciso di soffermarmi sulla nomenclatura dei campi (ovviamente di classi) privati. Eccone alcuni esempi:
firstName
_firstName
m_firstName
_FirstName
FirstName
La mia preferenza (del tutto personale) è nella seconda in quanto posso evitare di sovrappormi ai parametri dei metodi (senza usare this). I programmatori C++ probabilmente si riconoscono maggiormente nella terza. La quinta ha...
Gaston Milano ha implementato un tool per Visual Studio .NET 2005 CTP che visualizza graficamente un documento XAML.
Scott spiega come mai la funzionalità del "Site Counter" sarà rimossa da Visual Studio.NET 2005.
Hervey annuncia la pre-release del service pack 2 di WSE 2.0.
La tecnologia principe per la comunicazione asincrona oggi è MSMQ. Ma cosa succederà nel futuro prossimo ?
Continueremo ad usare MSMQ (speriamo si superino presto i limiti dei 4MB)
Ci baseremo su MSMQT di Biztalk (oppure direttamente l'orchestration in casi più complessi)
Useremo Service Broker di SQL 2005
Tante alternative per contesti differenti. La cosa importante è che questi possano 'parlarsi'. E noi ? Stiamo alla finestra....
Martin Fowler, nel suo libro Patterns of Enterprise Application Architecture, parla delle varie possibilità di mappare il mondo OO con quello relazionale (DB). Uno dei punti interessanti riguarda l'identificazione univoca dell'oggetto vs quella dell'entità nel DB (sia essa una tabella oppure un insieme di tabelle - dovuto a forme di normalizzazione). Sostanzialmente, un oggetto viene univocamente identificato attraverso il suo indirizzo in memoria (puntatore), mentre nel database dalla sua chiave primaria (potrebbe anche essere una combinazione di campi). Martin, suggerisce di mantenere all'interno dell'oggetto i campi rappresentanti la chiave primaria nel database.
In C# 1.x questo verrebbe raggiunto attraverso un campo...
I Web Services hanno vissuto un momento (circa 1/2 anni fa) di grande gloria, si parlava praticamente solo di quello (articoli, workshop, ecc.). Dopo tanta euforia, guardando i numeri nel bel paese (sui newsgroups, forum, ecc.) sembra che non siano più così attraenti.
Mi piacerebbe capire (per chi ha voglia di scrivere) perchè, secondo voi, si non si usano i Web Services in molte realtà. Quali sono le perplessità ? E' un problema di infrastruttura ? Tecnologico ? Di conoscenza ? Di strumenti ?
Le specifiche che ruotano attorno al mondo dei web services non sono proprio poche, come si evice da questo articolo. I protocolli di base (come HTTP, XML, XML schema, ecc.) contano 19 specifiche. Quelle più specifiche dei web services sono 31 !
In più occasioni ho parlato di "contract-first" sui web services (fino alla noia). In tutte le occasioni ho tralasciato un'ipotesi che dovevo, invece, sottolineare. Contract-first significa iniziare dal contratto, che nei web services vien naturale pensare al WSDL. Per la precisione devo aggiungere che definire un contratto significa anche definire una interfaccia (con i necessari attributi), ala OOP.
Omissis ? Ebbè, direi proprio di si. Anche se per vedere veramente all'opera questo modello, dovremo, probabilmente, attendere Indigo.
Nella forma canonica, in ASP.NET, troviamo due message patterns:
One way: invio la richiesta ma non ho alcuna risposta
Request/Response: a seguito di una richiesta ho una risposta
Purtroppo, le due soluzioni non permettono un meccanismo 'asincrono' di comunicazione (duplex message pattern). L'unica asincronicità possibile (forse ;-)) è lato client (per non avere una chiamata bloccante - che blocca la GUI) oppure lato server (banalmente, multi-threading). Per il resto si è soggetti ai problemi classici di timeout.
La soluzione c'è, e bisogna lavorarci un pochetto (ma non è poi così difficile). Spero, a breve (e se interessa) di scriverci un articoletto.
Più volte ho parlato di contract-first, cioè di sviluppare Web Services iniziando dal contratto, aka WSDL. Avendo a disposizione il WSDL è possibile creare il codice della classe proxy con l'utility del framework wsdl.exe oppure la class (astratta) server sempre con la stessa utility (opzione /server). Se volete farlo dall'ambiente di sviluppo, potete scaricare gratuitamente il seguente Add-In.
Come la ncio è un pò vuoto, ma l'idea non è male: http://www.wsefaq.com/ e http://wiki.wsefaq.com/
Un interessante libro sui web service on-line.