Office 2010

Ho provato stasera la technical preview di Office 2010 e sono devvero stupito per la quantità di cose che in Microsoft hanno aggiunto. Ciò che mi è piaciuto è che ho voluto iniziare l’installazione alla grande facendo un update da Office 2007 e come per magia l’installazione è andata importando tutto quello che già avevo a buon fine ma ho dovuto rimuovere i Pin dalla taskbar di windows 7 in quanto i collegamenti sono cambiati.

Sono stato impressionato da Outlook 2010 che ha un interfaccia devvero divertentente mi propongo dunque di pubblicare un video con una anteprima

Perchè è stato fatto un progetto apposito di unity per silverlight? La risposta è semplicissima non esiste il supporto a System.Configuration quindi voilà il team di P&P ha confezionato una versione di unity in un unico assembly che con un unica referenza possiamo configurare la nostra dependency injection per MVVM.

Il futuro dell’AOP

L’inversion of Control è gettonata da un paio d’anni e si vedono in produzione sistemi che usano estensivamente questo tipo di pattern, analogamente, però l’interception con Unity fa la sua sporca figura perchè è possibile con pochissime linee di codice wrappare completamente il policy application block e definire i CallHandler (ICallHandler) e impostare le posi di interception mediante attributi.

Ormai ci siamo i paradigmi stanno cambiando velocemente e con EL 5 le novità non mancano e probabilmente sarà anche da valutare l’ipotesi di adottare nuovi approcci architetturali il futuro è alle porte e su codeplex già esiste un progetto fantastico il Common Service Locator

http://www.codeplex.com/CommonServiceLocator

Le differenze nel paradigma stanno in questi spezzoni di codice

Oggi:

DatabaseFactory.CreateDatabase(“mia istanza”)

oppure

Container.Resolve<Database>(“mia istanza”)

Il futuro

   1: new TypeRegistration<Database>(

   2:     () => new SqlDatabase(

   3:                 ConnectionString,

   4:                 Container.Resolved<IDataInstrumentationProvider>(Name)))

   5:     {

   6:         Name = Name,

   7:         Lifetime = TypeRegistrationLifetime.Transient

   8:     };

oppure

   1: var configurator = new UnityContainerConfigurator(Container);

   2:

   3: EnterpriseLibraryContainer.ConfigureContainer(

   4:     configurator,

   5:     configurationSource);

Silverlight 3 altre novità (parte 3 di 6)

Una importante novità è nella versione 3 è la possibilità di fare dialogare diverse istanze del plugin con pochissime linee di codice, e a tale proposito di passare tra “sender” e “receiver” un semplice messaggio di testo in modo che vi sia uno scambio di messaggi tra istanze di plugin che risiedono nella stessa macchina, cioò di cui stiamo parlando sono le local connections.

 
 

Ciò che occorre è creare delle istanze di alcuni oggetti e assegnare un nome di tipo stringa alla nostra connessione e utilizzare il namespace System.Windows.Messaging , gli oggetti sono 2

 
 

LocalMessageReceiver per la parte server

LocalMessageSender per la parte client

 
 

Nell’esempio allegato si potrà vedere come ciò che scriviamo in un textbox è perfettamente visibile in un textblock in una istanza completamente diversa del plugin, vale anche nella modalità out of browser

 
 

Le porzioni di codice sono tutte nel costruttore

 
 

Parte clent

private readonly LocalMessageSender _sender;

 
 

public MainPage()

{

InitializeComponent();

_sender = new LocalMessageSender(“myreceiver”);

 
 

myTextBox.KeyUp += ((sender, args) =>

{

_sender.SendAsync(args.Key.ToString());

}

);

 

}

 
 

Parte server

_receiver = new LocalMessageReceiver(“myreceiver”);

_receiver.MessageReceived += ((sender, args) =>

{

myText.Text += args.Message;

}

);

try

{

_receiver.Listen();

}

catch (ListenFailedException exception)

{

MessageBox.Show(string.Format(“Il local connection receiver non può essere instanziato\n{0}”,

exception.Message));

}

 
 

 
 

Gli effetti che si possono effettuare sono notevoli con un codice banale. L’unica menzione è che la spedizione dei messaggi deve essere fatta in modalità asincrona altrimenti impatterebbe sull’istanza del browser.

 
 

 
 

Vediamo ora le novità per i DataBinding

 
 

Per prima cosa finalmente in Microsoft hanno implementato il supporto per il binding su elementi visuali

 
 

{Binding ElementName=mioElemento, Path=MiaProprietà} che già usiamo estensivamente in WPF e a cui siamo abbituati in ambito smart client.

 
 

Anche nel caso di Silverlight 3 è stato implementata la possibilità di collegare le fonti dati al CollectionViewSource che equivale al BindingNavigatore nelle applicazioni SmartClient in Windows Form, sacrificando la possibilità di effetuare il grouping. Anche in questo caso il codice è semplicissimo

 
 

myDataSource.Source = new DataProvider().Employees;

myDataSource.Filter += ((sender, args) =>

{

 
 

}

);

myListBox.ItemsSource = myDataSource.View.SourceCollection;

 
 

Naturalmente il codice del mio UserControl istanzia al suo interno una ClooectionView che effettua il dispatch degli elementi tramite la propria View, per fare questo ho ipotizzato anche un filtro che nel nostro esempio è vuoto in quanto suggerisco i video di Beth Massi su WindowsClient per approfondimenti sullaCollectionView e il databinding (consideriamo che il grouping non è supportato su Silverlight!)

 
 

Questo è il link del codice nell’esempio dove troviamo sia il binding che le local connections http://www.4shared.com/file/145868837/8115df4/SiverlightLocalConnections.html

 
 

Ricordo anche che per le cose rapidissime nel Silverlight toolkit è presente anche il mitico DataGrid, che personalmente non amo molto ma consente di sviluppare le cose con una rapidità impressionante.

 
 

In linea di massima mi chiedo, che senso ha sviluppare ancora applicazioni Windows Form? Secondo me per quando riguarda il codice nuovo, quindi quello prodotto da zero, la risposta è non ha alcun senso.

 
 

Ho fatto come Marzullo mi sono fatto una domanda e mi sono dato una risposta, va bè!

Aspect Oriented Programming AOP con c# ed Enterprise Library

L’AOP ha decisamente preso piede in tutti i contesti in cui sia necessario effettuare attività di sviluppo di livello enterprise , vuoi per la manutenibilità del codice prodotto, vuoi per la semplificazione delle operazioni di test e per la necessità di adottare soluzioni architetturali di una certa robustezza. Enterprise Library ci viene in aiuto fornendo 2 Application Block per queste esigenze: Policy Application Block e Unity AB. I layer architetturali forniscono sempre una grande scalabilità nelle struttura applicativa del codice con lo sforzo iniziale di stratificare correttamente le logiche e l’IO.

 
 

Per capire meglio di cosa stiamo parlando è opportuno fare un piccolo esempio introducendo appunto policy applcation block che ha anche un’età superiore di Unity, tale breve esempio anche se non fa parte delle più recenti tecnologie sarà moloto utile a scopo didattico.

 
 

Giusto per capire introdurre meglio l’ambito di discussione stiamo introducendo ciò che in gergo architetturale viene chiamato Separation of Concerns. Supponiamo dunque di avere un livello di business che deve semplicemente eseguire operazioni aritmetiche con due numeri.

 
 

public class MyAspectClass

{

public int Multiply(int a, int b)

{

try

{

return a + b;

}

catch (Exception e)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

 
 

public int Subtract(int a, int b)

{

try

{

return a – b;

}

catch (Exception ex)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

}

 
 

Come si può facilmente vedere è necessario ripetere la stessa gestione delle eccezioni in entrambi i metodi di moltiplicazione e sottrazione cioè è questo tipo di concern è chiamato comunemente aspect o cross-cutting concern.

 
 

Implementiamo dunque il Weaving cioè l’iniezione di codice nella nostra classe, che si può ottenere che differenti modalità cioè a compile time o a runtime. Questo tipo di comportamento con il più recente application block Unity viene chiamato Interception e probabilmente dedicherò un post apposito a unity per parlare dell’interception e come può essere utilizzato con davvero poche linee di codice.

Per prima cosa definimo il comportamento cioè quello che in gergo viene chiamato advice cioè
un intercettore che che sarà posto metà tra il chiamante e il chiamato e che effetturà delle azioniall’ingresso e all’uscita di quando un pezzo di codice viene processato.Modificheremo allora le policy sui due metodi che abbiamo scritto in prcedenza in modo tale da omettere la gestione delle eccezioni( naturalmente questo è solo un esempio di come tutti gli aspetti ripetitivi possano essere iniettati a livello applicativo). Andremo dunque a effettuare un Marshalling sulla nostra semplice classe e a decorare i metodi con alcune policy, la nostra classettina diventerà dunque:

 
 

public class MyAspectClass: MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

public int Multiply(int a, int b)

{

return a + b;

}

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

 
 

 
 

La decorazione dei metodi sarà configurata con una policy che si chiamaMyExceptionPolicy definita altrove e nella fattispecie configurata tramite file .config.

Ovviamente il codice risulta molto più sentetico e leggibile, ma scriveremo la regola di gestione delle eccezioni solo una volta con una netta facilità di manutenzione. Possiamo a questo punto individuare un problema, cioè che se per caso avremmo necessità di cambiare il nome della nostra policy di gestione dell’eccezione dovremmo andare a mano a modificare i punti in cui questa eccezione è richiamata con un notevole dispendio di tempo e la possibilità di perderci qualcosa per strada che non è detto che emerga nei test unitari.

Un’altro metodo decisamente più efficace è quello di intercettare gli handler su una classe in modo da non dover passare tramite l’uso di attributi questo metodo è chiamato interception e fa la parte del leone nel più recente application block che è Unity.

Per fare queste cose definendo dele policy che accppiano regole e handler, in modo che se una avviene una determinata regola viene scatenato l’handler relativo.

 
 

A questo punto per definire meglio le regole di applicazione delle policy come nella tabella che segue:

 
 

Regola	Descrizione
Assembly	consente di definire il target di una classe sulla base del nome dell’assembly
Custom Attribute	consente di definire il target di una classe sulla base del di un particolare tipo di attributo
Member name	consente il target di un particolare membro di classe
Method signature	target su un particolare metodo
Namespace	target di un namespace
Parameter Type	target su un singolo tipo di parametro
Property	target su una proprietà
Return Type	target sul valore di ritorno di un metodo
Tag attribute	Target sul nome di un attributo
Type	target su un tipo

 
 

 
 

Supponiamo di voler creare una regola che controlii l’espirazione di un oggetto, faremo così:

 
 

[ConfigurationElementType(typeof(CustomMatchingRuleData))]

public class MyTimeOfDayRule : IMatchingRule

{

private readonly DateTime _beginTimeSpan;

private readonly DateTime _endTimeSpan;

 
 

public MyTimeOfDayRule(NameValueCollection configValues)

{

_beginTimeSpan = DateTime.Parse(configValues["BeginTimeSpan"]);

_endTimeSpan = DateTime.Parse(configValues["EndTimeSpan"]);

}

 

#region IMatchingRule Members

 
 

bool IMatchingRule.Matches(MethodBase member)

{

DateTime currentTime = DateTime.Today;

return (currentTime >= _beginTimeSpan && currentTime <= _endTimeSpan);

}

 
 

#endregion

}

 
 

 
 

Naturalmente in casi reali spesso vengono definite molte regole che saranno testate a runtime mediante la seguente catena logica

 
 

 
 

 
 

Ora per utilizzare la nostra regola IMatchingRule dobbiamo configurare anche un handler che esegua delle operazione a fronte del match, EL fornisce anche una serie di handler predifiniti che sono in grado di comunicare con gli altri application block, essi sono:

 
 

Nome classe	Descrizione
AuthorizationCallHandler	Utilizza Security application Block come handler
CachingCallHandler	Utilizza Caching Application Block come handler
ExceptionCallHandler	Utilizza Exception Handling Application Block come handler
LogCallHandler	Utilizza Logging Application block
PerformanceCounterCallHandler	Consente la registrazione di dati di performance
ValidationCallHandler	Utilizza Validation Application Block come handler

 
 

Naturalmente è possibile definire il nostro handler e pertanto avremo dovremo implementare l’interfaccia ICallHandler per crere una classe che si comporti da da Handler, vediamone un esempio:

 
 

public class CreateFileHandler: ICallHandler

{

private readonly string _fileName;

 
 

#region ICallHandler Members

 
 

public CreateFileHandler(NameValueCollection configValues)

{

_fileName = configValues["FileName"];

}

 
 

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)

{

FileStream stream = File.Create(_fileName);

input.InvocationContext["CreatedFileStream"] = stream;

IMethodReturn msg = getNext()(input, getNext);

FileStream returnStream = msg.InvocationContext["CreatedFileStream"] as FileStream;

if (returnStream != null)

try

{ returnStream.Close();}

catch {}

if (stream != null)

try { stream.Close(); }

catch { }

return msg;

}

 
 

public int Order { get; set; }

 
 

#endregion

}

 
 

E’ abbastanza intuibile come venga collocato mediante l’interfaccia ICallHandler nella catena delle chiamate illustrata prima

 
 

Non ci resta che assemblare il tutto medinte il PolicyInjector

 
 

public class MyAspectClass : MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

[ValidationCallHandler]

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.") ]

public int Multiply(

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int a,

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int b

)

{

return a + b;

}

 
 

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

 
 

Ora configuriamo il tutto tramite l’utility di configurazione e provvediamo alla costruzione della nostra classe in questo modo

static void Main(string[] args)

{

MyAspectClass c = PolicyInjection.Create<MyAspectClass>();

c.Multiply(0, 5);

 
 

Console.ReadLine();

}

 
 

Il codice dell’esempio è scaricabile da qui: http://www.4shared.com/file/145800910/ef751dad/Policy_application_block.html

Abilitazione porta su servizi wcf in produzione

Abilitare l’ACL sulla porta tramite il comand

 
 

Netsh http add urlacl url=http://<mioserver>:8001/MioServizio

 
 

Analogamente è possibile seguire il comando remove per rimuovere dall’acl

 
 

In questo modo si possono mantenere le policy per consentire l’accesso in produzione al nostro servizio ospitato su IIS 7 o 7.5 vero è che che il programmatore solitamente no si preoccupa di tale feature in quanto in ambiente di sviluppo il problema non si pone

Daemon tools lite ora disponibile per windows 7

Quante volte devo installare i prodotti dalle immagini ISO e daemon tools è il prodotto che uso da sempre per fare queste attività, ma da quando uso Windows 7 l’installazione di daemon tools produceva un warning di compatibilità. Nonostamte tutto l’ho usato normalmente e non ho riscontrato problemi. Ora, comunque è stato sviluppato un aggiornamento che consente la piena compatibilità con Windows 7 e, tra ler caratteistiche di rilievo c’è questo bellissimo gadget sul destop che consente di comunicare con un oggetto COM e montare dal desktop le immagini ISO.

 
 

 
 

 
 

Al di la dell’aggiornamento il bello di tutto ciò e che COM vive ed è pienamente supportato e non fa parte solo del software “legacy”.

 
 

Per scaricare : http://www.daemon-tools.cc/eng/downloads

Intenti…

I temi che voglio affrontare sono i seguenti ma ultimamente il trading e gli Expert Advisor mi stanno davvero asciugando le forze, ricapitolando prossimamente affronterò i seguneti temi:

• Approfondimenti sulle novità di Silverlight 3
• Introduzione ai Servizi di Windows Workflow Foundation 4
• Uno sguardo ad Azure
• Uno sguardo a Sync Framework

In questo modo ricorderò anche io le cose che voglio proporre sul blog

Spero di ricordarmi e di non sparire

M-V-VM per Silverlight

Utilizzo M-V-VM da un po’ di tempo quando scrivo qualcosa in Silverlight o più in generale WPF ma in rete non avevo visto dei tutorial di semplice comprensione. Segnalo però questo facile articolo anche se su Silverlight 2.

http://msdn.microsoft.com/en-us/magazine/dd458800.aspx

Accorgimento per il DataContext di WPF

Sempre più spesso mi viene chiesto come si utilizza il Binding su WPF e nonostante le cose siano veramente semplici, non lo è così tanto quando si vogliono creare gli unit test, soprattutto in applicazioni ad elevata complessità, e, divente necessario disaccoppiare gli elementi architetturali del nostro lavoro.

Sempre più spesso è neccessario impostare i datacontext su cui effettuare il Binding al di fuori del markup ed eseguire una sorta di inizializzazione da codice come in questo caso:

<TextBlock Text=”{Binding Path=”MyProperty, Mode=TwoWay}” />

Nel momento in cui il DataContext viene inizializzato dal codice può capitare di incorrere in un piccolo errore dovuto a un probabile bug nella costruzione della gerarchia di oggetti in WPF, quindi se scrivo:

public class myClass()

{

public MyClass() {

DataContext = MyDataContextInstance;

}

}

Incapperò sicuramente in un errore, non visibile subito, ma sull’aggiornamento dei dati a fronte di un input utente, sarà dunque sufficiente tradurre il costruttore con l’inizializzazione del DataContext in

this.Loaded += new RoutedEventHandler(MyClass_Loaded);

e spostare di conseguenza l’assegnamento dell’oggetto del DataContext all’interno dell’evento.