ottobre 2003 Blog Posts
Leggendo i blog dei nostri (UGIdotNET) rappresentanti alla PDC si deduce che Longhorn è il nome principale della conferenza. Tutto ruota attorno al prossimo sistema operativo. E' allora interessante dare una prima occhiata di cosa si tratta attraverso il seguente sito: http://longhorn.msdn.microsoft.com/ interamente dedicato a Longhorn.
Nel precedente post ho illustrato un esempio di riusabilità di schemi XML. Se provate a generare la classe corrispondente con xsd.exe:
xsd /c Profile.xsd
riceverete un errore nel quale non trova il tipo PersonType. La soluzione consiste nel fornire entrambi gli schemi:
xsd /c Person.xsd Profile.xsd
Chi scrive scjemi XML si sarà posto il problema, probabilmente, di riusare i tipi creati in schemi esterni. Immaginiamo, a titolo di esempio, di aver creato uno schema XML come il seguente:
<?xml version="1.0" encoding="UTF-8"?><xs:schema targetNamespace="urn:peway:person" xmlns="urn:peway:person" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Person" type="PersonType"/> <xs:complexType name="PersonType"> <xs:sequence> <xs:element name="FirstName" type="xs:string"/> <xs:element name="LastName" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema>
Vogliamo usare il tipo PersonType senza riscriverlo (copy&paste) nel nuovo schema. Basterà importarlo:
<?xml version="1.0" encoding="UTF-8"?><xs:schema targetNamespace="urn:peway:profile" xmlns="urn:peway:profile" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:person="urn:peway:person"> <xs:import namespace="urn:peway:person" schemaLocation="Person.xsd"/> <xs:element name="Profile"> <xs:complexType> <xs:sequence> <xs:element name="Person" type="person:PersonType"/> <xs:element name="Person" type="person:PersonType"/> </xs:sequence> </xs:complexType> </xs:element></xs:schema>
Ovviamente, se dobbiamo leggere lo schema molte volte (in un processo di valiazione), potrebbe comunque essere utile avere...
Qualche giorno fa ho affrontato il problema dell'XmlSerializer quando si usa un web service. Bene, ho fatto alcune ricerche su Internet per verificare se vi era una soluzione già pronta all'uso; e ne ho trovate due interessanti.
La prima si basa su una SoapExtension (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031007XMLAS/manifest.xml e http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031016XMLAS/manifest.xml) la quale applica una validazione basata sullo schema XML del messaggio entrante. Benchè sia una soluzione funzionante non mi esalta al massimo in quanto lo schema XML deve prendere in considerazione tutto il messaggio entrante (SOAP) e non solamente alcuni elementi di questo (es. ordine, fattura, ecc.).
Una alternativa (a parer mio molto più valida),...
In questo periodo sto lavorando su un progetto (.NET) che fa un uso intenso di ottimizzatori lineari (soluzione di sistema di equazioni) unmanaged. La caratteristica degli ottimizzatori consiste nell'avere una serie di funzioni che valorizzano le variabili, costanti e vincoli, quindi una funzione di esecuzione (es. optimize).
Dato che le dichiarazioni delle funzioni da codice .NET sono statiche (non è possibile altrimenti) il problema sorge se si usa l'ottimizzatore in ambiente multi-threaded. Si finisce per incrociare le variabili dei problemi (mappati sui singoli thread) di ottimizzazione dando un risultato certamente errato.
Ho quindi avviato un confronto con Corrado Cavalli e Raffaele Rialdi....
Chi ha usato la classe XmlSerializer si sarà accorto di quanto questa sia flessibile e libertina. In pratica possiamo scrivere di tutto e lei continuerà a serializzare/deserializzare senza timori. Se trova l'elemento bene, altrimenti la inizializza in base al tipo base.
Se questo approccio funziona bene per serializzazioni di classi su files, può provocare non pochi grattacapo nel caso di web services. Prendiamo un esempio molto semplice (il più semplice) di WebMethod che somma due numeri:
<%@ WebService Language="c#" Class="Math" %>
using System.Web.Services;
[WebService(Namespace="urn:ugidotnet:org:services:tests")]public class Math{ [WebMethod] public int Add(int a, int b) { return a + b; }}
Prendiamo un qualsiasi client di web...
Questa mattina ho avuto un interessante dialogo (via messenger) con Corrado Cavalli il quale mi ha fatto notare una mancanza nel mio blog di ieri (quello sulle proprietà).
Mi ha detto che in senso generale in VB (non VB.NET) è possibile definire la visibilità di una proprietà distinguendo fra getter e setter. Dalla discussione ne è comunque uscito che ne VB.NET ne C# lo permettono, almeno sino ad oggi.
Ma questo è un limite dei linguaggi, non di .NET. Infatti, il managed C++ permette di fare il distinguo in quanto mappa il getter e setter su dei metodi:
__gc class Person{private: String* firstName;protected: __property void ...
Ieri ho avuto una interessante discussione con un collega in merito all'uso di proprietà o campi all'interno di classi .NET. Nel passato ho già affrontato il tema, anche se in altra veste (http://www.ugidotnet.org/myprofile/blog/BlogReader.aspx?MemberID=8#182).
Oggi vorrei focalizzarmi solamente su questo aspetto. Quali sono i vantaggi di usare una proprietà rispetto ad un campo ? Le proprietà permettono solamente due cose in più rispetto ai campi:
1. definire una modalità di lettura e scrittura (implementazione del getter e setter)2. definire la proprietà in sola lettura o sola scrittura
In base a queste differenze, penso che la scelta diviene molto semplice. Se non c'è bisogno...
Le regole di validazione non sono null'altro che un insieme di controlli, anche complessi, sui contenuti dei singoli attributi (proprietà o campi delle classi). Ci sono tanti modi per fare questi controlli, come usare attributi personalizzati .NET. Un'alternativa consiste nell'usare XPath (la dove c'è dell'XML....Web services) e Aaron Skonnard ne illustra uno scenario interessante con un appuntamento MSDN TV.
Chi ha affrontanto il tema dei web services si sarà trovato di fronte ad una miriade di specifiche. C'è veramente da perdersi. Roger Culter ha scritto una email nella mailing list W3C elencando una serie di specifiche del mondo web service. E' interessante vedere che, a volte queste specifiche si sovrappongano. Chi avrà ragione ?
Il naming convention è un aspetto fondamentale della produzione del software in quanto lo rende generalmente più manutenibile nel tempo.
E' comunque singolare vedere che l'attributo [CLSCompliant] non soddisfi i requisiti di naming convention. Infatti dovrebbe essere [ClsCompliant] !