BlogServiceHost.Create()

WCF & Azure - Il blog di Fabio Cozzolino

Recent Posts

Tags

My

Twitter

Community

Archives

Email Notifications

Social Bar Widget

October 2009 - Posts

Il rilascio di Windows Azure si avvicina …

A quanto pare il 17 Novembre, primo giorno di PDC 2009, verranno rilasciate una serie di nuove feature che si andranno ad aggiungere a quelle già esistenti. Il periodo di CTP si concluderà il 31 Dicembre. Da Gennaio 2010 quindi sarà possibile incominciare ad usufruire dei servizi di Windows Azure che diventeranno a pagamento (qui i prezzi) a partire dal primo Febbraio 2010. Quindi c’è il tempo di prepararsi e testare anche le nuove feature.

Chissà, forse facciamo in tempo a vederle per il Community Tour Big Smile

Posted: Oct 31 2009, 02:19 PM by Fabio.Cozzolino | with no comments
Filed under:
Automating Azure

Interessante set di Powershell cmdlets che “wrappano” le Windows Azure Service Management API, consentendo di gestire il deploy, l’upgrade oppure la modifica dei files di configurazione, rendendole operazioni automatizzate.

Disponibile su Code Gallery

fonte: http://blogs.msdn.com/innov8showcase/archive/2009/10/26/automating-azure.aspx

Posted: Oct 26 2009, 11:58 PM by Fabio.Cozzolino | with no comments
Filed under:
Bello…

…il nuovo look di MSDN !!! Ma soprattutto mi piace molto sia la versione lightweight sia quella scriptfree.

Posted: Oct 20 2009, 11:44 PM by Fabio.Cozzolino | with no comments
Filed under:
SQL Azure is now feature complete!!

Windows Azure Platform e SQL Azure saranno rilasciati il prossimo mese. SQL Azure, però, già nella CTP di Ottobre è Feature Complete. Questo significa che le attuali feature disponibili sono le stesse della release finale.

maggiori info: http://www.azurejournal.com/2009/10/new-ctp-for-sql-azure/

WCF Extensibility Guide

Riporto il post di Pablo Cibraro che annuncia la pubblicazione del primo capitolo della guida WCF Extensibility Guide da lui scritta a quattro mani con Jesus Rodriguez. Si tratta di una serie di capitoli, con pubblicazione scadenzata, che affrontano WCF dal punto di vista della sua estensibilità. Ho già detto più volte come l’architettura di WCF sia stata sviluppata nel modo migliore proprio perchè fornisce allo sviluppatore gli strumenti giusti per produrre un servizio funzionante in pochi semplici passaggi, o di personalizzare completamente l’infrastruttura per farla aderire alle esigenze della propria soluzione (altrimenti non lo si potrebbe definire framework per lo sviluppo di servizi).

I vari capitoli saranno:

Buona lettura Big Smile

Posted: Oct 18 2009, 08:21 AM by Fabio.Cozzolino | with no comments
Filed under: ,
Supporto tecnico per gli sviluppatori italiani

Da qualche tempo è attivo il blog Supporto Tecnico agli sviluppatori gestito interamente da Microsoft Italia e dal relativo team. Post davvero interessanti. Vi consiglio di seguirlo, sia per quello che riguarda WCF, che per il resto … da non perdere Smile.

Data Transfer Object, questo sconosciuto…

Molto spesso capitano domande, sui forum, via email o di persona, su come è possibile far viaggiare le proprie entity con WCF. Molti non sono disposti a marcare con gli attributi DataContract e DataMember, e direi anche giustamente. Il .NET Framework 3.5 consente anche di utilizzare oggetti senza la necessità di marcarli con gli appositi attributi.

Il punto però è un altro. Spesso la necessità non è quella di trasferire le entità, bensi un insieme probabilmente differente contenente informazioni specifiche e ben definite. Una ipotetica entità Book, nel nostro dominio, ha sicuramente un riferimento ad una entità Author. Probabilmente avremo qualcosa del tipo:

public class Book
{
    public string ISBN { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public int Pages { get; set; }
    public double Price { get; set; }
    public Author Author { get; set; }
}
public class Author
{
    public string Name { get; set; }
}

Abbiamo semplificato parecchio. Se il nostro servizio esponesse l’entità Book così com’è saremmo costretti a generare un messaggio con dati probabilmente non necessari per lo specifico contesto. Perchè trasferire tutto? E se la gerarchia fosse ancora più complessa? Performance, processo di serializzazione, dimensioni del messaggio, tutto ne pagherebbe le conseguenze, inutilmente.

Il Data Transfer Object

Ancora una volta i pattern ci vengono in aiuto. Il Data Transfer Object (DTO, talvolta conosciuto anche come Value Object) è un oggetto che non appartiene al nostro dominio, contenente solo proprietà e nessun metodo o logica, ma soprattutto è un oggetto serializzabile ed ottimizzato per il semplice scopo per cui è stato creato: trasferimento di dati.
Nel nostro esempio avremmo dunque qualcosa di simile:

public class BookDTO
{
    public string Title { get; set; }
    public string AuthorName { get; set; }
    public double Price { get; set; }
}

Semplicemente quello che deve essere trasferito. Niente di più. Di conseguenza il contratto del nostro servizio risulterebbe quindi questo:

[ServiceContract]
public interface BookService
{
    [OperationContract]
    public BookDTO RetrieveBook(string isbn);
}
L‘implentazione del servizio ed il mapping dei dati

A questo punto il servizio si dovrebbe semplicemente occupare di invocare lo strato successivo, recuperare l’istanza dell’oggetto Book e poi restituirla al chiamante:

public BookDTO RetrieveBook(string isbn)
{
    Book book = OtherLayer.GetBook(isbn);
    BookDTO bookDTO = Map(book);
    return bookDTO;
}

Generalmente preferisco avere un servizio WCF che si occupa semplicemente di trasformare o adattare le esigenze di integrazione del mio dominio con il mondo esterno. Quindi pochissima logica, solo validazione dei dati e generazione di eventuali eccezioni (scordatevi l’accesso al database direttamente dal servizio Smile). Nel servizio quindi viene fatto il mapping del dominio verso l’entità esterna utilizzando logiche ad-hoc oppure appositi mapper. Il pattern DTO, come definito da Martin Fowler, prevere la realizzazione di un apposito componente chiamato assembler che “assembla” le informazioni e crea il DTO (o l’entità, a seconda della direzione). L’assembler deve essere sviluppato appositamente per ogni oggetto del dominio.

Preferisco, invece, l’utilizzo di un mapper che automaticamente mappa le entità a seconda delle esigenze. AutoMapper è decisamente un’ottimo punto di partenza. Consente infatti di eseguire il mapping di oggetti utilizzando specifiche regole. Nel nostro caso la funzione Map sarebbe semplicemente così composta:

private BookDTO Map(Book sourceBook)
{
    Mapper.CreateMap<Book, BookDTO>();
    return Mapper.Map<Book, BookDTO>(sourceBook);
}

AutoMapper effettuerà per noi la creazione di un istanza di BookDTO mappando le proprietà Title e Price da Book, e la proprietà AuthorName dalla proprietà Name della classe Author. Questo perchè nel momento in cui non trova nessuna proprietà con il nome della proprietà di destinazione e nessun metodo chiamato GetNomeProprietà, tenterà di suddividere il nome della proprietà di destinazione utilizzando il PascalCase per trovare il valore da assegnare (spero di essere stato chiaro Big Smile, altrimenti ditemelo…).

Qual’è il vantaggio? Non devo scrivere quintali di righe di codice per ogni mapping che devo eseguire. E non è mica poco se il mio dominio è decisamente complesso.

Conclusioni

Sono uno dei fan del DTO. Collegandomi al post precedente, la sequenza ottimale da seguire per la realizzazione di un buon strato di servizi è questa:

  • Definizione degli schema XSD
  • Definizione dei messaggi
  • WSDL
  • Generazione del codice. Che si suddivide poi in:
    • Creazione dei DTO (partendo dagli XSD)
    • Creazione dell’interfaccia del servizio (in parole povere l’interfaccia che marcheremo con ServiceContract e OperationContract)
    • Collegamento con il layer successivo, che comunica utilizzando gli oggetti del dominio e quindi generazione del mapping bidirezionale DTO <—> Domain Object

Vedo in questo approccio un’ottima suddivisione della logica del mio dominio con la logica di integrazione con i sistemi esterni. Un sistema esterno non è solo e necessariamente un’applicazione sviluppata da terze parti, ma anche una qualsiasi applicazione sempre da noi sviluppata e che fa parte della nostra soluzione, come ad esempio può essere un’applicazione Silverlight.

Apertissimo alla discussione Big Smile

Contract-First development, una discussione ancora aperta…

Apprendo da Nicholas Allen la pubblicazione di un artticolo dal titolo: Schema-based Development with Windows Communication Foundation. L’articolo, davvero molto interessante, parla in soldoni dell’approccio Contract-First, cioè la definizione prima delle informazioni da trasferire ed utilizzare nel servizio (modello di dati espresso in XSD), poi dei messaggi che contengono le informazioni da scambiare, infine del documento che descrive l’intera interfaccia (WSDL/MEX). Da qui si deve poi partire per generare le interfacce server e client.

Il processo è sicuramente più articolato rispetto all’approccio Code-First (sviluppo prima del codice e poi generazione del WSDL), ma permette di avere il corretto controllo delle informazioni scambiate, con una più netta distinzione tra la fase di progettazione/contrattualizzazione e la fase di sviluppo.

Visual Studio segue esclusivamente l’approccio Code-First, ma esiste un tool sviluppato da un guru come Christian Weyer (co-autore dell’articolo), che consente di seguire l’approccio Contract-First: WSCF.blue. Qui l’annuncio della release 1.0.

Leggete l’articolo e provatelo.