BlogServiceHost.Create()

Il rilascio di Windows Azure si avvicina …

Fabio.Cozzolino — Sat, 31 Oct 2009 12:19:51 GMT

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 …

Automating Azure

Fabio.Cozzolino — Mon, 26 Oct 2009 21:58:14 GMT

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

Bello…

Fabio.Cozzolino — Tue, 20 Oct 2009 21:44:28 GMT

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

SQL Azure is now feature complete!!

Fabio.Cozzolino — Sun, 18 Oct 2009 21:09:56 GMT

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

Fabio.Cozzolino — Sun, 18 Oct 2009 15:21:46 GMT

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:

Introduction
Extending the WCF Channel Model
Extending the WCF Client-Dispatcher Runtimes
Extending the WCF Security Model
Extending the WCF Hosting Model
Extending the WCF Metadata Model
Extending the WCF Web Programming Model
Extending Dublin Application Server
Building Custom Binding Elements and Behaviors

Buona lettura

Supporto tecnico per gli sviluppatori italiani

Fabio.Cozzolino — Fri, 16 Oct 2009 21:37:05 GMT

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 .

Data Transfer Object, questo sconosciuto…

Fabio.Cozzolino — Sat, 10 Oct 2009 12:46:32 GMT

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 ). 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 , 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

Contract-First development, una discussione ancora aperta…

Fabio.Cozzolino — Mon, 05 Oct 2009 12:51:09 GMT

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.

Microsoft Forums in italiano

Fabio.Cozzolino — Tue, 22 Sep 2009 21:23:30 GMT

Da qualche giorno sono attive le sezioni italiane di alcuni forum di Microsoft: http://social.microsoft.com/Forums/it-IT/categories.

E’ uno spazio decisamente utile soprattutto perchè è possibile ricevere il supporto degli MVP italiani e degli altri utenti. Ottimo

Congratulazioni Simone!!!

Fabio.Cozzolino — Sun, 09 Aug 2009 16:29:43 GMT

Finalmente Beginning ASP.NET MVC 1.0 è disponibile su Amazon US e a breve anche su Amazon UK. Scrivere un libro non è per niente semplice, il lavoro è lungo e paziente, quindi davvero complimenti Simone per questo grande e meritatissimo traguardo .

Installing Windows 7…Done!!!

Fabio.Cozzolino — Sat, 08 Aug 2009 18:13:47 GMT

Fatto. Ho terminato da poco l’installazione di W7. Utilizzavo le versioni beta già da tempo, ma la prima differenza sostanziale che noto è un ulteriore, e prevedibile, miglioramento delle performance. Comunque, è assolutamente da provare.

Prima di installarlo, seguite i consigli di Lorenzo.

Unity Lifetime Managers e l’integrazione in WCF

Fabio.Cozzolino — Fri, 07 Aug 2009 06:00:00 GMT

Qualche tempo fa ho parlato dell’integrazione di Unity, il container di Microsoft per l’IoC. A completamento della serie di post, può essere associato anche questo post che spiega alcune problematiche che è possibile riscontrare quando il lifetime manager di Unity è per-thread e l’Instancing Mode di WCF è Per-Session.

E’ chiaro che, in questa situazione, verrà utilizzata la stessa istanza di Unity in una unica sessione di comunicazione tra client e server in WCF, che potenzialmente significa più di una invocazione. Talvolta non è questo il comportamento che ci aspettiamo e rischiamo di avere risultati strani come quelli riportati nel post di Drew.

fonte: Kirk Evans

Windows 7 RTM Day

Fabio.Cozzolino — Thu, 06 Aug 2009 06:00:00 GMT

A quanto pare oggi dovrebbe essere il W7Day . Mi preparo per il download …

Gli user group crescono…

Fabio.Cozzolino — Wed, 05 Aug 2009 06:00:00 GMT

Nell’ultimo periodo sono diverse gli user group nati in italia. L’ultimo arrivato in ordine di tempo è OrangeDotNet, UG siciliano al quale do il mio benvenuto .

Questo l’elenco degli attuali user group italiani su .NET (in ordine cronologico):

Scusatemi se ho dimenticato qualcuno, anzi fatemelo notare .

Bello il proliferare degli UG, un qualcosa che in italia fino a qualche anno fa mancava proprio sul fronte .NET. Portare avanti un progetto del genere non è assolutamente semplice, bisogna esserne consapevoli. Il mio benvenuto, quindi, ai nuovi arrivati, con l’augurio che possano portare avanti il proprio progetto con la forza ed il coraggio necessari per produrre qualcosa di importante nella propria terra.

Debugging WCF: Let’s go!!!

Fabio.Cozzolino — Tue, 04 Aug 2009 06:00:00 GMT

Debuggare il framework … non ha prezzo, dicevo qualche tempo fa. Purtroppo, però, non era disponibile il debug per WCF. Da qualche giorno, attraverso l’annuncio lasciato sul forum di WCF, è possibile eseguire il debug di WCF dopo aver installato l’apposito installer disponibile a questo indirizzo:

http://referencesource.microsoft.com/netframework.aspx

E’ inutile descrivervi l’importanza di questo rilascio. Ho passato ore con .NET Reflector alla mano nel tentativo di capire al meglio il comportamento di WCF nei scenari più disparati che mi sono capitati. E’ stata una scuola importante, senza dubbio, ma ne avrei fatto volentieri a meno .

Oltre a WCF, ce ne sono anche altri…

Buon debug !!!

Ps.: leggete il readme.txt per configurare correttamente Visual Studio…