DarioSantarelli.Blog("UgiDotNet");

[WPF] Un “generic” command

Dario Santarelli — Sat, 17 Oct 2009 09:41:24 GMT

Analizzando diverse soluzioni WPF che sfruttano l’architettura M-V-VM, mi è saltata all’occhio una strategia di implementazione dell’interfaccia ICommand semplice e potente a mio modo di vedere. Andiamo direttamente al codice:

public class GenericCommand<T> : ICommand
{
public Predicate<T> CanExecuteDelegate { get; set; }
public Action<T> ExecuteDelegate { get; set; }

public bool CanExecute(object parameter)
{
    if (CanExecuteDelegate != null) return CanExecuteDelegate((T)parameter);
    return true;
}

public event EventHandler CanExecuteChanged
{
    add { CommandManager.RequerySuggested += value; }
    remove { CommandManager.RequerySuggested -= value; }
}

public void Execute(object parameter)
{
    if (ExecuteDelegate != null) ExecuteDelegate((T)parameter);
}
}

Sostanzialmente l’obiettivo di questo GenericCommand è di permettere una “tipizzazione” dichiarativa del parametro gestito dall’ interfaccia ICommand, in modo tale da poter costruire ViewModel contenenti delegati che gestiscono il pattern CanExecute/Execute operando a nostro piacimento su parametri tipizzati passati magari direttamente dalla View. Ecco un esempio molto semplice di ViewModel...

public class ContactsViewModel
{
public ObservableCollection<string> Contacts { get; private set; }
public GenericCommand<string> AddContact { get; set; }
public GenericCommand<object> ClearContacts { get; set; }

public ContactsViewModel()
{
    Contacts = new ObservableCollection<string>();
    AddContact = new GenericCommand<string>();
    ClearContacts = new GenericCommand<object>();

    AddContact.CanExecuteDelegate += new Predicate<string>(AddContact_CanExecute);
    AddContact.ExecuteDelegate += new Action<string>(AddContact_Execute);

    ClearContacts.CanExecuteDelegate += new Predicate<object>(ClearContacts_CanExecute);
    ClearContacts.ExecuteDelegate += new Action<object>(ClearContacts_Execute);
}

bool AddContact_CanExecute(string contactName) { return (!string.IsNullOrEmpty(contactName)); }
void AddContact_Execute(string contactName) { Contacts.Add(contactName); }

bool ClearContacts_CanExecute(object parameter) { return (Contacts.Count > 0); }
void ClearContacts_Execute(object parameter) { Contacts.Clear(); }
}

...e per chiudere il cerchio riporto anche lo XAML saliente di una View di esempio.

<TextBox Name="txtContactName" ... />
<Button Command="{Binding AddContact}" CommandParameter="{Binding ElementName=txtContactName, Path=Text}" ...>Add Contact</Button>
<ListBox ItemsSource="{Binding Contacts}" ... />
<Button Command="{Binding ClearContacts}" ...>Clear Contacts</Button>

Cosa ne pensate?

Technorati Tag: WPF,ICommand,M-V-VM

[WPF] Window non rettangolari

Dario Santarelli — Sat, 26 Sep 2009 11:23:09 GMT

La possibilità di creare Window di forma irregolare costituisce a mio modo di vedere uno dei più divertenti nonché semplici vantaggi di WPF.
In genere, ogni tecnica di realizzazione di Window dalla forma completamente personalizzata si basa sulla valorizzazione preliminare di tre proprietà:

In questo modo siamo subito svincolati sia dalla forma rettangolare standard della nostra Window, che dalla barra standard del titolo. Si aprono quindi diverse possibilità di sviluppo. E’ possibile ad esempio sfruttare immagini semitrasparenti come background della Window (scelta semplice e di veloce realizzazione, ma non consigliabile in WPF dal momento che la Window subirebbe un rendering con più pixel in sistemi con maggiori DPIs). Una soluzione sicuramente più potente sfrutta invece il programming model che WPF ci mette a disposizione relativamente alla grafica vettoriale: in altre parole, per creare una Window dai bordi arrotondati basta partire dall’elemento Border.
Vorrei riportare un esempio che mi è rimasto impresso dopo aver letto il libro “Pro WPF in C# 2008” : creare una Window dalla forma irregolare, con bordi arrotondati.
N.B.: tralascio volutamente ogni questione di carattere architetturale ( es. realizzazione di custom control template per le nostre Window ).

Codice XAML:

Code-behind (interaction logic):

public partial class ShapedWindow : Window
{
private bool _isResizing = false;
public ShapedWindow()
{
    InitializeComponent();
    CommandBinding binding = new CommandBinding(ApplicationCommands.Close);
    binding.Executed += CloseWindow;
    this.CommandBindings.Add(binding);
}

private void CloseWindow(object sender, RoutedEventArgs e) { this.Close(); }

private void BeginWindowResize(object sender, MouseButtonEventArgs e) { _isResizing = true; }

private void EndWindowResize(object sender, MouseButtonEventArgs e)
{
    _isResizing = false;
    Rectangle rectangle = (Rectangle)sender;
    rectangle.ReleaseMouseCapture();
}

private void WindowResize(object sender, MouseEventArgs e)
{
    Rectangle rectangle = (Rectangle)sender;
    if (_isResizing)
    {
      rectangle.CaptureMouse();
      double newWidth = e.GetPosition(this).X + 5;
      if (newWidth > 0) this.Width = newWidth;
    }
   }

private void WindowDragMove(object sender, MouseButtonEventArgs e)
{
    if (e.ClickCount == 2) this.WindowState = (this.WindowState == WindowState.Maximized) ? WindowState.Normal : WindowState.Maximized;
    else this.DragMove();
}
}

Si nota subito che in una soluzione di questo tipo (non poteva essere altrimenti) è compito dello sviluppatore gestire sia il resize che il move della Window, dal momento che è assente la barra del titolo standard che l’utente usa comunemente per interagire con la finestra stessa.
Differentemente dal mondo Windows Forms, in WPF è possibile gestire la modalità di dragging della Window semplicemente invocando il metodo Window.DragMove() , che in questo caso specifico viene usato in corrispondenza dell’evento MouseLeftButtonDown scatenato sul TextBlock che funge da barra del titolo ( due click consecutivi invece “massimizzano” o “normalizzano” la finestra ;) ).
Per quanto riguarda invece il resize, la questione diventa un po’ più “complessa”. Anzitutto, impostare la proprietà Window.ResizeMode a CanResizeWithGrip significa far apparire il sizing grip nell’angolo in basso a destra assumendo che la window sia comunque rettangolare. Questo significa quindi che esso può apparire o troppo distante o addirittura sopra l’effettivo bordo della Window.
Se non si vuole scegliere questo tipo di approccio, bensì si desidera poter ridimensionare manualmente la finestra interagendo con i suoi bordi effettivi, esistono due strade: o si utilizzano P/Invoke che inviano messaggi Win32 per ridimensionare la window, oppure più semplicemente (come in questo caso) si gestisce la posizione e l’azione scatenata dal mouse in ogni bordo che si vuole utilizzare per ridimensionare la finestra, andando poi a gestire di conseguenza la proprietà Width.
Nell’esempio, si è scelto di posizionare un Rectangle trasparente di larghezza 5 in corrsipondenza del lato destro della finestra. In questo modo gli opportuni event handler (MouseLeftButtonDown, MouseLeftButtonUp, MouseMove) ci permettono di gestire il resize manuale della window ogni volta che il mouse interagisce con il bordo destro della stessa.

Technorati Tag: WPF

Screenshots di Forms, Windows e schermo

Dario Santarelli — Tue, 08 Sep 2009 21:29:44 GMT

Spesso in ambiente desktop può essere utile salvare degli screenshot relativi alla UI della nostra applicazione: in alcuni scenari ad esempio, oltre ai soliti log e trace, è molto comodo avere automaticamente lo screenshot dell’UI al momento dell’errore, magari come allegato di una email di report.
Una comune soluzione in Windows Forms è quella che sfrutta GDI+ tramite il metodo Graphics.CopyFromScreen(…) . In questo post vorrei mostrare come anche in WPF è possibile approfittare della stessa tecnica con il minimo sforzo: in particolare, nell’ helper class che segue sono presenti degli overload del metodo SaveScreenShot(…) per salvare su file system gli screenshot sia di singole Window (WPF) / Form (Windows Forms) che dell’intero schermo.

public class ScreenshotHelper
{
// Per Windows Forms...
public static void SaveScreenShot(Form form, string fileName, ImageFormat imageFormat)
{
    SaveScreenShot(form.Location, form.Size, fileName, imageFormat);
}

// Per WPF...
public static void SaveScreenShot(Window window, string fileName, ImageFormat imageFormat)
{
    SaveScreenShot(new System.Drawing.Point((int)window.Left, (int)window.Top),
                   new System.Drawing.Size((int)window.Width, (int)window.Height),
                   fileName, imageFormat);
}

private static void SaveScreenShot(System.Drawing.Point windowLocation, System.Drawing.Size windowSize,
                                     string fileName, ImageFormat imageFormat)
{
    using (Bitmap bitmap = new Bitmap(windowSize.Width, windowSize.Height))
    {
      using (Graphics graphics = Graphics.FromImage(bitmap))
      {
        graphics.CopyFromScreen(windowLocation, new System.Drawing.Point(0, 0), windowSize);
      }
      bitmap.Save(fileName, imageFormat);
    }
}

// Schermo intero...
public static void SaveScreenShot(string fileName, ImageFormat imageFormat)
{
     Rectangle bounds = Screen.GetBounds(System.Drawing.Point.Empty);
     using (Bitmap bitmap = new Bitmap(bounds.Width, bounds.Height))
     {
       using (Graphics graphics = Graphics.FromImage(bitmap))
       {
         graphics.CopyFromScreen(System.Drawing.Point.Empty, System.Drawing.Point.Empty, bounds.Size);
       }
       bitmap.Save(fileName, imageFormat);
     }
}
}

Nota: Questo metodo non riesce a catturare controlli trasparenti. Per gestirli occorre utilizzare altri metodi, nativi di GDI+, come mostrato in questo post.

Technorati Tag: WPF,Windows Forms,GDI+

[WPF] Application Shutdown

Dario Santarelli — Wed, 26 Aug 2009 12:08:06 GMT

In un’ applicazione WPF, per default la classe Application mantiene viva l’applicazione stessa finché almeno una finestra è ancora aperta. Se si vuole cambiare questo comportamento, è possibile utilizzare la proprietà Application.ShutdownMode direttamente dal markup XAML:
( ATTENZIONE: se si istanzia l’oggetto Application a mano, è obbligatorio impostare la proprietà ShutdownMode prima di invocare il metodo Run() )

I valori ammissibili per tale proprietà sono:

OnLastWindowClose (default): l’applicazione WPF rimane in vita fintantoché esiste almeno una Window attiva. Se si chiude la MainWindow, la proprietà Application.MainWindow continua a puntare alla MainWindow chiusa. In questo tipo di situazione, si può quindi scegliere di ri-assegnare da codice la proprietà MainWindow in modo tale che essa punti ad una Window differente.
OnMainWindowClose: l’applicazione WPF rimane viva fintantoché la MainWindow è aperta.
OnExplicitShutdown: L’applicazione WPF rimane viva fintantoché non viene chiamato esplicitamente il metodo Application.Shutdown(), anche se tutte le Window sono chiuse. E’ chiaro che questo approccio ha senso nel caso in cui occorra gestire una logica complessa per stabilire se e quando la nostra applicazione debba chiudersi.

Un paio di note:

Indipendentemente dal meccanismo di shutdown scelto, il metodo Application.Shutdown() è sempre valido per iniziare il processo di terminazione dell’applicazione: dietro le quinte, infatti, il metodo Application.Shutdown() non fa altro che scatenare l’uscita dal metodo Application.Run(), il che (occhio!) non preserva dall’esecuzione di eventuale codice aggiuntivo nel Main() o nel gestore dell’evento Application.Exit.
Quando ShutdownMode=”OnMainWindowClose” e viene chiusa la MainWindow, l’oggetto Application chiude automaticamente tutte le altre finestre prima che il contesto di esecuzione esca dal metodo Run(), analogamente a quanto avviene invocando il metodo Application.Shutdown().

Technorati Tag: WPF,Shutdown

LINQ to CSV

Dario Santarelli — Mon, 27 Apr 2009 14:35:37 GMT

Veramente utile!!! :D

http://www.codeproject.com/KB/linq/LINQtoCSV.aspx

Technorati Tag: LINQ,CSV

[WPF] ICommand e CanExecute

Dario Santarelli — Thu, 02 Apr 2009 18:18:39 GMT

Per chi sviluppa utilizzando il pattern M-V-VM l’interfaccia ICommand costituisce la base per costruire un’infrastruttura che permetta alla View di invocare comandi applicativi direttamente nel ViewModel. L’interfaccia mette a disposizione tre semplici membri: due metodi Execute(...), CanExecute(...) ed un evento CanExecuteChanged. E’ facile immaginare come in progetti di una certa consistenza sia necessario costruirsi delle implementazioni spesso particolari dell’interfaccia ICommand, cosa che da una parte implica tanta buona volontà, dall’altra ripaga quando si dormono sonni tranquilli pensando ad una View completamente svincolata dalla logica applicativa.
In genere un’ utile implementazione di ICommand poggia sull’ intercettazione dell’evento CanExecuteChanged in modo da poter esporre alla View informazioni sul fatto che il nostro command sia o meno eseguibile ( si pensi ad esempio ad un Button enabled o meno ). A mio modo di vedere, una limitazione dell’interfaccia ICommand risiede nel metodo CanExecute(…) , il quale appunto è un metodo ( con annesso parametro opzionale ) e non una proprietà, cosa che non mette a disposizione il classico pattern Property/PropertyChanged sfruttabile nei data binding tra ViewModel e View.
E’ semplice ovviare a questa situazione: ad esempio si può fare in modo che il nostro ICommand implementi una sorta di proprietà “wrapper” per esporre un sistema binding-friendly CanExecute/CanExecuteChanged.
Vediamo un esempio pratico. In una mia applicazione WPF avevo bisogno di realizzare un VM per una Window di Login e volevo “bindare” la proprietà CanLogin del VM ( che semplicemente ritorna true se UserName e Password sono entrambi valorizzati ) direttamente con il metodo CanExecute(…) del mio ICommand.

Ho quindi realizzato un’implementazione di ICommand (chiamata senza fantasia CanExecuteCommand) che accetta:

Un Delegate da eseguire all’interno dell’ Execute(…)
Un oggetto di tipo Binding che rappresenta il binding tra una proprietà “wrapper” per il metodo CanExecute(…) dell’ ICommand (nello specifico CanExecuteAction) e una proprietà del ViewModel (nello specifico CanLogin) in modo da poter scatenare l’evento CanExecuteChanged proprio al variare della proprietà CanLogin del ViewModel.

Difficile da spiegare, facile da implementare :D

Command:

public class CanExecuteCommand : DependencyObject, ICommand
{
   Action<object> _executeDelegate;
   public event EventHandler CanExecuteChanged;

   public bool CanExecuteAction
   {
     get { return (bool)GetValue(CanExecuteActionProperty); }
     set { SetValue(CanExecuteActionProperty, value); }
   }

   public static readonly DependencyProperty CanExecuteActionProperty =
          DependencyProperty.Register("CanExecuteAction", typeof(bool), typeof(CanExecuteCommand),
                                      new PropertyMetadata(OnCanExecuteActionChanged));

   public CanExecuteCommand(Action<object> executeDelegate) : this(executeDelegate, null) { }

   public CanExecuteCommand(Action<object> executeDelegate, Binding canExecuteActionBinding)
   {
      _executeDelegate = executeDelegate;
      if (canExecuteActionBinding != null) BindingOperations.SetBinding(this, CanExecuteActionProperty, canExecuteActionBinding);
   }

   #region ICommand Members

   public void Execute(object parameter) { _executeDelegate(parameter); }

   public bool CanExecute(object parameter) { return CanExecuteAction; }

   #endregion

   private void RaiseCanExecuteActionChanged()
   {
     if (CanExecuteChanged != null) CanExecuteChanged(this, new EventArgs());
   }

   static void OnCanExecuteActionChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs args)
   {
    (dependencyObject as CanExecuteCommand).RaiseCanExecuteActionChanged();
   }
}

ViewModel:

public class LoginViewModel : ILoginViewModel, INotifyPropertyChanged
{
private string _username;
private string _password;

public event PropertyChangedEventHandler PropertyChanged;

public ICommand ReadyCommand { get; private set; } // In Binding con la View

#region ILoginViewModel Members

public string UserName // In Binding con la View
{
    get { return _username; }
    set
    {
      if (_username != value)
      {
        _username = value;
        RaisePropertyChanged("UserName");
        RaisePropertyChanged("CanLogin");
      }
    }
}

public string Password // In Binding con la View
{
    get { return _password; }
    set
    {
      if (_password != value)
      {
        _password = value;
        RaisePropertyChanged("Password");
        RaisePropertyChanged("CanLogin");
      }
     }
   }

public bool CanLogin
{
    get { return !string.IsNullOrEmpty(UserName) && !string.IsNullOrEmpty(Password); }
}

public void Login()
{
    //... Do Login...
}

#endregion

public LoginViewModel()
{
    Binding binding = new Binding("CanLogin");
    binding.Source = this;
    ReadyCommand = new CanExecuteCommand((arg) => Login(), binding);
}

private void RaisePropertyChanged(string propertyName)
{
   if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}

Technorati Tag: WPF,ICommand

[Silverlight/WPF] Resource file e Access Modifier

Dario Santarelli — Thu, 19 Mar 2009 22:02:41 GMT

Più volte nello sviluppo Silverlight/WPF mi sono imbattuto nella necessità di utilizzare i file di risorsa (.resx) e devo dire che le prime volte mi sono trovato un po’ in difficoltà dal momento che non riuscivo a capire per quale arcano i miei binding dichiarativi nel codice XAML verso le mie risorse non funzionassero affatto. Andiamo per ordine: supponendo di definire un file di risorsa in questo modo ...

... in fase di design Visual Studio notifica uno “strano” errore,

indipendentemente dal fatto che si utilizzi Public o Internal come access modifier (più precisamente se si selezionasse Internal l’errore diverrebbe AG_E_PARSER_BAD_TYPE). Mantenendo l’access modifier come “Public” ed andando a vedere il codice autogenerato da Visual Studio ci si imbatte in questa piccola “finezza”:

Classe public e costruttore internal!!!

Personalmente ho sempre ovviato al problema nel modo più semplice, impostando il costruttore come public per ogni file di risorsa. Oggi invece mi imbatto in questo post che propone invece una soluzione più elegante a cui non avevo proprio pensato, ovvero realizzare semplicemente una classe pubblica con una singola proprietà che espone la classe associata al file di risorsa. SEMPLICE MA GENIALE!!!

Technorati Tag: Silverlight 2,WPF

[Silverlight 2] Visibility e VisualStateManager

Dario Santarelli — Mon, 16 Mar 2009 21:04:58 GMT

Una caratteristica di un controllo visuale che spesso e volentieri risulta gradevole è la possibilità di mostrare/nascondere il contenuto del controllo stesso tramite un effetto FadeIn/FadeOut. In genere, questo effetto è realizzato tramite una semplice animazione che lavora sull’Opacity del controllo (portandola da 1 a 0 e viceversa) e che magari imposta a Visible/Collapsed la proprietà Visibility subito dopo l’animazione in modo da riempire/liberare istantaneamente un’area specifica dello schermo. In molti casi risulta dunque utile legare l’ effetto FadeIn/FadeOut proprio alla proprietà Visibility del controllo, in modo da ottenere automaticamente le animazioni desiderate al momento della valorizzazione della proprietà (che altrimenti non effettuerebbe ovviamente alcun effetto visuale di transizione). Un modo che ritengo molto interessante per ottenere questo tipo di scenario sfrutta il VisualStateManager : nel seguente esempio vediamo come sia possibile effettuare l’override della proprietà Visibility di un UserControl per agganciare gli effetti di FadeIn/FadeOut agli stati Visible/Collapsed definiti tramite VisualStateManager.

MyControl.xaml

MyControl.xaml.cs

public partial class MyControl : UserControl
{
private Visibility _visibility;

public event EventHandler VisibilityChanged;

public MyControl() { InitializeComponent(); }

public new Visibility Visibility
{
     get { return _visibility; }
     set
     {
       if (_visibility != value)
       {
         _visibility = value;
         OnVisibilityChanged();
       }
      }
}

protected virtual void OnVisibilityChanged()
{
     if (this.Visibility == Visibility.Visible)
     {
       base.Visibility = this.Visibility;
       VisualStateManager.GoToState(this, "Visible", true);
     }
     else VisualStateManager.GoToState(this, "Collapsed", true);
}

private void CollapsedCompleted(object sender, EventArgs e)
{
     base.Visibility = this.Visibility;
     FireVisibilityChanged();
}

private void VisibleCompleted(object sender, EventArgs e) { FireVisibilityChanged(); }

private void FireVisibilityChanged()
{
     if (VisibilityChanged != null) VisibilityChanged(this, new EventArgs());
}
}

Come si può notare, nell’esempio si è voluto implementare anche un evento VisibilityChanged che viene scatenato ogni volta che l’animazione FadeIn/FadeOut ha terminato la propria esecuzione. Infatti, la transizione visuale da uno stato Visible ad uno stato Collapsed può essere relativamente lunga e di conseguenza potrebbe essere utile sapere esattamente quando il nostro controllo è completamente visibile/nascosto.

Technorati Tag: Silverlight 2

jQuery e ASP.NET Ajax: $(document).ready() VS asynchronous postback

Dario Santarelli — Mon, 09 Mar 2009 20:58:18 GMT

Molto spesso capita di dover integrare, anche solo per semplici miglioramenti grafici, dei plugin jQuery all’interno delle nostre pagine ASP.NET. Gran parte delle volte l’impatto è indolore mentre in alcuni casi specifici occorre far riferimento ad accorgimenti non banali, soprattutto quando c’è di mezzo ASP.NET Ajax.
Il classico esempio si verifica quando ci si aspetta che la funzione $(document).ready() venga chiamata correttamente anche dopo un asynchronous postback tramite UpdatePanel. Infatti, la funzione $(document).ready() permette di determinare il momento in cui il DOM della pagina è caricato dal browser. Tuttavia, in caso di asynchronous postback il DOM può essere eventualmente modificato e non ricaricato nuovamente. Quindi il nostro codice javascript nella forma:

$(document).ready(function()
{
// codice...
});

... non verrà eseguito!
Un workaround molto semplice per questo tipo di situazione è quello di sfruttare l’evento client-side endRequest generato dopo un postback asincrono, quando il controllo viene restituito al browser. Agganciando il nostro codice jQuery che usa $(document).ready() all’interno di un opportuno event Handler per tale evento possiamo risolvere il problema. Ecco un semplice esempio:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>jQuery .ready() function and asynchronous postback</title>
</head>
<body>
<form id="mainForm" runat="server">
<div>
    <asp:ScriptManager ID="scriptManager" runat="server">
      <Scripts>
       <asp:ScriptReference Path="http://code.jquery.com/jquery-latest.js" />
      </Scripts>
    </asp:ScriptManager>
    <asp:UpdatePanel ID="updatePanel" runat="server">
      <ContentTemplate>
         <asp:Button ID="btnTest" runat="server" Text="Do Async PostBack" />
      </ContentTemplate>
    </asp:UpdatePanel>
   </div>
</form>

Technorati Tag: jQuery,ASP.NET,Ajax,DOM

[Entity Framework] Disabilitare il change tracking dell’ObjectStateManager

Dario Santarelli — Tue, 03 Mar 2009 20:31:15 GMT

(da MSDN) ObjectStateManager tracks query results, and provides logic to merge multiple overlapping query results. It also performs in-memory change tracking when a user inserts, deletes, or modifies objects, and provides the change set for updates. This change set is used by the change processor to persist modifications.

La classe ObjectStateManager in generale gestisce lo stato dei nostri EntityObject. In quei casi in cui i nostri dati devono essere semplicemente presentati in modalità read only può essere utile disabilitare il change tracking dell’ ObjectContext, ottenendo un incremento di performance talvolta significativo.
In particolare, per disabilitare il change tracking occorre utilizzare l’opzione MergeOption.NoTracking dell’enumeration MergeOption, che permette di lavorare con Entità aventi EntityState ‘Detached’. Fondamentalmente esistono due modi per disabilitare il change tracking:

Utilizzando l’oggetto ObjectQuery. Esiste infatti un overload del costruttore che permette di specificare l’opzione MergeOption desiderata.
A livello di EntitySet

Vediamo entrambi gli esempi:

Caso 1

using (NorthwindObjectContext context = new NorthwindObjectContext())
{
ObjectQuery<Customer> queryCustomers = new ObjectQuery<Customer>("SELECT VALUE c FROM NorthwindObjectContext.Customers AS c", context, MergeOption.NoTracking);
foreach (Customer customer in queryCustomers)
{
Console.WriteLine("{0} - {1}", customer.ContactName, customer.EntityState.ToString());
}
}

Caso 2

using (NorthwindObjectContext context = new NorthwindObjectContext())
{
context.Customers.MergeOption = MergeOption.NoTracking;
foreach (Customer customer in context.Customers)
{
    Console.WriteLine("{0} - {1}", customer.ContactName, customer.EntityState.ToString());
}
}

Technorati Tag: Entity Framework

Da WindowsForms a WPF via MVP

Dario Santarelli — Fri, 27 Feb 2009 18:43:19 GMT

Qualche giorno fa mi sono imbattutto in una simpatica applicazione Windows Forms che permette di disegnare su una lavangna virtuale il posizionamento in campo di due squadre di calcio. Un'applicazione per allenatori insomma :D. In breve, il funzionamento è semplicemente basato sull'aggiunta e sullo spostamento di pedine (rosse o blu) su un campo di calcio virtuale con eventuale possibilità di ingrandirne/rimpicciolirne le dimensioni.
Guardando il sorgente ho osservato come l’intera applicazione fosse stata concepita e sviluppata "alla Windows Forms" con l'intera logica piazzata all'interno di ciascun event handler dei vari elementi dell'UI.
Ho quindi pensato di esercitarmi nel fare un po' di refactoring, ma soprattutto di analizzare alcuni aspetti prettamente grafici nel porting di una applicazione WindowsForms ad una versione WPF.
Dal punto di vista architetturale, prima di passare alla versione MVVM ho anzitutto ritenuto opportuno inserire un “passaggio intermedio” nel refactoring, soffermandomi su una versione MVP. Il tutto per mettere sostanzialmente in risalto al mio cervello i principali punti di differenza tra i due pattern. Inoltre, come già accennato, la fase di analisi ha toccato alcune potenzialità grafiche di WPF, come il Drag & Drop/Move e lo Zoom.

In questo post vorrei condividere con voi come mi sono mosso, sperando di ricevere magari qualche utile consiglio ;D

Anzitutto sono partito definendo un mini-core, ovvero un'interfaccia "marker" IView per le View

public interface IView { }

ed una classe generica astratta per il presenter:

public abstract class PresenterBase<T> where T : IView
{
public T View { get; set; }
}

A questo punto ho iniziato il porting della Form principale dell'applicazione di partenza (che si chiamava SoccerBlackBoardForm) realizzando la corrispondente Window WPF (SoccerBlackBoardWindow) che implementa un'interfaccia IBlackboardView dedotta analizzando il codice dell'applicazione originale. Infine ho realizzato una classe presenter BlackboardPresenter per le View che implementano IBlackboardView. Il tutto è rappresentato sinteticamente nel seguente class Diagram:

Omettendo per brevità il codice dell'interfaccia IBlackboardView, riporto direttamente lo scheletro del mio refactoring dal momento che si tratta di codice abbastanza autoesplicativo:

1. La costruzione della Window SoccerBlackBoardWindow ha letteralmente svuotato di logica la corrispondente versione Windows Forms fino ad avere la seguente forma:

SoccerBlackBoardWindow.xaml

<Grid>

<Grid.ColumnDefinitions>

</Grid.ColumnDefinitions>

<ListBox.ItemTemplate>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

<Button Content="Add Image >>" Click="AddImageClick" ...></Button>

</StackPanel>

<Canvas.Background>

</Canvas.Background>

</Canvas>

</Grid>

</Window>

SoccerBlackBoardWindow.xaml.cs

public partial class SoccerBlackBoardWindow : Window, IBlackboardView
{
private BlackboardPresenter _presenter;

#region IBlackboardView Members

public Panel DrawingArea
{
    get { return drawingArea; }
}

public Point MousePosition
{
    get { return Mouse.GetPosition(drawingArea); }
}

public IList<BitmapSource> AvailableImages
{
    get { return (IList<BitmapSource>)lstImages.ItemsSource; }
    set { lstImages.ItemsSource = value; }
}

public BitmapSource SelectedImage
{
    get { return (BitmapSource)lstImages.SelectedItem; }
    set { lstImages.SelectedItem = value; }
}

public void AttachPresenter(BlackboardPresenter presenter) { _presenter = presenter; }

#endregion

public SoccerBlackBoardWindow()

{

InitializeComponent();

_presenter = new BlackboardPresenter(this);

_presenter.LoadImages();
}

protected void AddImageClick(object sender, RoutedEventArgs e) { _presenter.DrawImage(SelectedImage, new Size(100, 100), 0, 0, 0); }

protected void ClearClick(object sender, RoutedEventArgs e) { _presenter.ClearDrawingArea(); }

}

2. Il presenter BlackboardPresenter è stato quindi realizzato per aggiornare la View sia in base agli eventi utente e l'interazione con il model, che in questo caso è dato da una banale collezione readonly di immagini che l'utente ha a disposizione per l'inserimento nella area di disegno (DrawingArea)
Notare come sia semplice realizzare un meccanismo di Drag & Move :D.

BlackboardPresenter.cs

public class BlackboardPresenter : PresenterBase<IBlackboardView>
{
private Point _tmpPosition;
private const int ZOOMDELTA = 10;

public BlackboardPresenter(IBlackboardView view) { View = view; }

public void LoadImages()
{
    IList<BitmapSource> availableImages = new List<BitmapSource>();
    availableImages.Add(new BitmapImage(new Uri("Resources/SoccerBall.png", UriKind.Relative)));
    availableImages.Add(new BitmapImage(new Uri("Resources/blueBall.png", UriKind.Relative)));
    availableImages.Add(new BitmapImage(new Uri("Resources/redBall.png", UriKind.Relative)));
    View.AvailableImages = availableImages;
}

public void ClearDrawingArea(){ View.DrawingArea.Children.Clear(); }

public Image DrawImage(ImageSource source, Size size, int canvasLeft, int canvasTop,int zIndex)

{

Image image = new Image();

image.Source = source;

image.Height = size.Height;

image.Width = size.Width;

image.Cursor = Cursors.Hand;

Canvas.SetLeft(image, canvasLeft);

Canvas.SetTop(image, canvasTop);

Panel.SetZIndex(image, zIndex);

image.MouseMove += delegate(object o, MouseEventArgs args) { MoveImage(image); };

image.MouseWheel += delegate(object o, MouseWheelEventArgs args) { ZoomImage(image, args.Delta); };

image.MouseDown += delegate(object o, MouseButtonEventArgs args) { CaptureImage(image); };

image.MouseUp += delegate(object o, MouseButtonEventArgs args) { ReleaseImage(image); };

View.DrawingArea.Children.Add(image);

return image;

}

public void ReleaseImage(Image image) { image.ReleaseMouseCapture(); }

public void CaptureImage(Image image)

{

image.CaptureMouse();

_tmpPosition= View.MousePosition;

}

public void MoveImage(Image image)

{

if (Mouse.LeftButton == MouseButtonState.Pressed)

{

Canvas.SetLeft(image, Canvas.GetLeft(image) + (View.MousePosition.X - _tmpPosition.X));

Canvas.SetTop(image, Canvas.GetTop(image) + (View.MousePosition.Y - _tmpPosition.Y));

}

_tmpPosition= View.MousePosition;

}

public void ZoomImage(Image image, int amount)

{

if (amount > 0)

{

image.Height += ZOOMDELTA;

image.Width += ZOOMDELTA;

}

else

{

if ((image.Height - ZOOMDELTA > ZOOMDELTA) && (image.Width - ZOOMDELTA > ZOOMDELTA))

{

image.Height -= ZOOMDELTA;

image.Width -= ZOOMDELTA;

}

Il risultato ottenuto è raffigurato qua sotto: non vi dico quanto è stato divertente usare questa app per spiegare alla mia compagna la tattica del fuorigioco :D.

Technorati Tag: MVP, WPF

[WCF] IOperationBehavior e IParameterInspector

Dario Santarelli — Tue, 24 Feb 2009 14:02:08 GMT

Dal punto di vista della flessibilità, ritengo che WCF sia una delle tecnologie più potenti attualmente disponibili per lo sviluppo di applicazioni orientate ai servizi. In particolare, una delle caratteristiche che apprezzo maggiormente è la facilità di personalizzazione del comportamento runtime degli OperationContract sia client-side che service-side ( pratica per altro molto usata nel WCF REST Starter Kit :D ).
In questo post volevo soffermarmi proprio su questo aspetto, mostrando un semplice esempio di implementazione dell’interfaccia IOperationBehavior, che per l'appunto definisce quattro metodi finalizzati all'estensione del runtime behavior di un'operation:

AddBindingParameters : serve per aggiungere nuovi elementi di binding utilizzabili dall'operation in fase di esecuzione.
ApplyClientBehavior : viene chiamato client-side
- prima che il contenuto della richiesta sia serializzato e inviato al service
- dopo che la risposta è stata deserializzata ma prima che i valori restituiti vengano forniti al metodo proxy
ApplyDispatchBehavior : viene chiamato service-side dopo la deserializzazione dei parametri, ma prima che essi siano forniti all'operation del service.
Validate : permette di verificare che l'operation soddisfi dei criteri custom ( es. autorizzazioni ).

Vediamo ora una semplice implementazione che mette in evidenza come sia veramente semplice agganciare un OperationBehavior ad un OperationContract tramite un attributo. Gli ambiti di applicazione sono veramente tanti: ad esempio potremmo usare questa tecnica service-side per eseguire della logica custom prima e dopo l’invocazione di un’operation da parte di un client. Nello specifico, supponiamo di voler scrivere in un file di log sul server sia i parametri di input passati all'operation che il risultato dell'invocazione. Per ottenere questo scenario necessitiamo anzitutto della definizione di un oggetto che sia in grado di ispezionare i parametri dell'operation sia prima che dopo la chiamata: in altre parole abbiamo bisogno di un IParameterInspector. Questa interfaccia definisce due metodi, BeforeCall(…) e AfterCall(…), che ci permettono di inserire della logica custom ( sempre sia client-side che service-side ) per accedere alle informazioni inerenti una operation ed i relativi parametri di input/output nelle fasi immediatamente precedenti e successive all’invocazione.
Partiamo dunque dal nostro IParameterInspector:

public class ParameterLogInspector : IParameterInspector
{
   private FileInfo _logFileInfo;

   public ParameterLogInspector(string fileName)
   {
     _logFileInfo = new FileInfo(fileName);
     if (!_logFileInfo.Exists) _logFileInfo.Create();
   }

   #region IParameterInspector Members

   public object BeforeCall(string operationName, object[] inputs)
   {
     StringBuilder sb = new StringBuilder();
     foreach (object input in inputs) sb.AppendFormat("{0};", input.ToString());
     this.Log(string.Format("Operation \"{0}\" is calling... inputs: {1}", operationName, sb.ToString()));
     return null;
   }

   public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
   {
     this.Log(string.Format("Operation \"{0}\" called. returnValue: {1}",operationName,returnValue.ToString()));
   }

   #endregion

   private void Log(string message)
   {
     using (StreamWriter sw = _logFileInfo.AppendText())
     {
       sw.WriteLine(string.Format("{0}> {1}", DateTime.Now.ToString(), message));
     }
   }
}

Quindi, ci posizioniamo all'interno del metodo ApplyDispatchBehavior(...) semplicemente per aggiungere il nostro IParameterInspector alla collection ParameterInspectors dell'oggetto DispatchOperation (che rappresenta l'operation service-side) :

public class ParametersLog : Attribute, IOperationBehavior
{
public string FileName { get; set; }

#region IOperationBehavior Members

...

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
{
dispatchOperation.ParameterInspectors.Add(new ParameterLogInspector(this.FileName));
}

...

#endregion
}

Il gioco è fatto: non rimane che decorare l'OperationContract di interesse con il nostro attributo ParametersLog per ottenere l' estensione del runtime che ad ogni chiamata scriverà in un file di log i valori dei parametri di input/output .

[ServiceContract]
public interface IAuthentication
{
[OperationContract]
[ParametersLog(FileName="C:/log.txt")]
UserInfo Login(string userName, string password);

[OperationContract]
void Logout(string userName);
}

Technorati Tag: WCF

Pong con il designer WindowsForms

Dario Santarelli — Sat, 21 Feb 2009 19:27:43 GMT

Clamoroso :D

http://blogs.msdn.com/mitsu/archive/2009/02/13/coding4fun-understanding-winforms-designmode.aspx

EntityObject e DTO: copiare proprietà comuni via extension method

Dario Santarelli — Sat, 21 Feb 2009 00:33:29 GMT

Quando si sviluppano architetture N-tier che prevedono uno o più service layer è sempre consigliabile l’utilizzo di DTO per scambiare dati tra livelli, indipendentemente dal (fuorviante) fatto che ogni DataContract esposto da un servizio (es. WCF) possa essere in mapping 1:1 con i business objects (es. EntityObject). Un DTO infatti è solitamente un POCO le cui proprietà in molti casi si possono mappare sia nel nome che nel tipo in un sottoinsieme di quelle di uno o più oggetti di business.
Ad ogni modo, al fine di aumentare la produttività nel valorizzare un DTO che possiede proprietà in comune nel nome e nel tipo con uno o più EntityObject, può avere senso implementare un extension method che via reflection copi il valore delle proprietà di un oggetto sorgente nelle proprietà di un oggetto destinazione appunto qualora tali proprietà abbiano stesso nome e tipo.

public static void CopyProperties<T1, T2>(this T1 source, T2 destination)
{
   if (source == null) throw new ArgumentNullException("Source object can’t be null.");
   if (destination == null) throw new ArgumentNullException("Destination object can’t be null.");

   PropertyInfo[] destinationPropertyInfos = destination.GetType().GetProperties();
   foreach (PropertyInfo propertyInfo in destinationPropertyInfos)
   {
     if (propertyInfo.CanWrite)
     {
       source.GetType().GetProperties()
           .Where(p => p.CanRead && (p.Name == propertyInfo.Name && p.PropertyType == propertyInfo.PropertyType))
           .ToList()
           .ForEach(p => propertyInfo.SetValue(destination, p.GetValue(source, null), null));
     }
   }
}

Quindi, supponendo di avere il seguente object model di partenza...

...è possibile scrivere qualcosa del genere, al fine di evitare la noiosa scrittura delle solite righe di inizializzazione della classe DTO partendo dall’ Entity Objecy:

Customer customerEntity = null;
using (NorthwindEntities entities = new NorthwindEntities())
{
customerEntity = entities.Customers.First(c => c.CustomerID == "ALFKI");
}

CustomerDTO customerDTO = new CustomerDTO();
customerEntity.CopyProperties(customerDTO);

Technorati Tag: Reflection,Extension Method

[Entity Framework] EntityClient

Dario Santarelli — Sun, 15 Feb 2009 23:03:52 GMT

EntityClient (namespace System.Data.EntityClient) è un provider che l’EntityFramework mette a disposizione per accedere ai dati descritti da unEntity Data Model (EDM), ovvero una sorta di gateway per query sul modello concettuale e non sulla relativa rappresentazione fisica.
Le query invocabili dall’ EntityClient vanno dunque scritte in un dialetto di SQL chiamato “EntitySQL”: a runtime, la pipeline compila il testo EntitySQL in un command tree che viene passato al data provider sottostante per la generazione del comando SQL nativo. Dietro le quinte, infatti, EntityClient utilizza i provider ADO.NET per accedere alle sorgenti dati ( es. SqlClient per SQL Server ). L’aspetto interessante è che i risultati di una query EntitySQL possono non limitarsi a semplici tabelle, bensì possono contenere anche gerarchie complesse.
In generale, l’uso di EntityClient è consigliabile in applicazioni model-based che richiedono particolari performance nella misura in cui non si necessita della materializzazione delle Entities a partire da resultset, bensì di un IDataReader consumabile direttamente magari per materializzazioni di oggetti specifici.
In qualità di provider ADO.NET a tutti gli effetti, EntityClient segue i soliti pattern Connection-Command-Parameter-DataReader, etc. dove le suddette classi sono precedute dal prefisso “Entity”. Ecco un esempio di paginazione dati usando EntityClient:

public List<string> GetProductNames(int pageNumber, int pageSize)
{
List<string> productNames = new List<string>();
using (EntityConnection conn = new EntityConnection("name=NorthwindEntities"))
{
    string cmdText = string.Format("SELECT VALUE v FROM NorthwindEntities.Products AS v ORDER BY v.ProductName SKIP {0} LIMIT {1}", (pageNumber * pageSize).ToString(), pageSize);

    using (EntityCommand cmd = new EntityCommand(cmdText, conn))
    {
      conn.Open();
      using(EntityDataReader reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess))
      {
        while (reader.Read()) productNames.Add(reader["ProductName"].ToString());
      }
    }
   }
   return productNames;
}

Technorati Tag: Entity Framework

Caricamento dinamico di JavaScript con jQuery AJAX

Dario Santarelli — Fri, 13 Feb 2009 15:30:28 GMT

Una delle tecniche che permettono di aumentare le performance di un' applicazione web si basa sul caricamento "on-demand" di javascript via Ajax. In questo modo si possono ridurre le latenze di precaricamento di troppe librerie javascript alla prima GET di una pagina. Infatti, in alcuni scenari specifici risulta più consigliabile scaricare "pezzi" di script solo quando se ne ha bisogno. Fino a non molto tempo fa ho avuto modo di testare alcune librerie free come Include e AJILE che permettono di raggiungere questo obiettivo senza troppi problemi. Ma da quando sono passato a jQuery le cose sono cambiate :D.
Vorrei semplicemente mostrare un paragone tra l'utilizzo classico di XMLHTTP e l'utilizzo di Ajax/jQuery.getScript.
Supponiamo di voler caricare dinamicamente ed eseguire una function javascript "HelloWorld()"che si trova in un file HelloWorld.js

function HelloWorld() { alert( 'Hello World!' ); }

al click di un button nella nostra pagina.

1. Esempio con XMLHTTP

<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

function CallExternalScriptMethod(scriptUrl, targetCall)

{

var AJAX = null;

if (window.XMLHttpRequest) AJAX = new XMLHttpRequest();

else AJAX = new ActiveXObject("Microsoft.XMLHTTP");

AJAX.onreadystatechange = function() {

if (AJAX.readyState == 4 && AJAX.status == 200) {

eval(AJAX.responseText);

eval(targetCall);

}

AJAX.open("GET", scriptUrl, true);

AJAX.send(null);

}

</script>

</head >

<body>

<div>

</div>

</body>

</html>

2. Esempio con Ajax/jQuery.getScript

<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

function CallExternalScriptMethod(scriptUrl, targetCall)
{

$.getScript(scriptUrl, function() {

eval(targetCall);
});

}

</script>

</ head >

<body>

<div>

</div>

</body>

</html>

Come si può notare la facilità e l'eleganza di realizzazione con jQuery è disarmante. Inoltre, a partire dalla v1.2 abbiamo gratuitamente un nuovo enanchement riguardante le possibili problematiche relative a richieste cross-domain che limiterebbero l'utilizzo dell'esempio con XMLHTTP sopra riportato:

Before jQuery 1.2, getScript was only able to load scripts from the same domain as the original page. As of 1.2, you can now load JavaScript files from any domain.

Technorati Tag: Ajax,jQuery

XPUG Marche.... Chi è interessato?

Dario Santarelli — Tue, 10 Feb 2009 15:57:46 GMT

Segnalo questa importante iniziativa che sta partendo su agilemovement.it : XPUG Marche.
Lo scopo è la creazione di una community attenta nel promuovere le metodologie "agili" sul territorio marchigiano.
Chi è interessato a dare il proprio contributo può rispondere a questo appello:

http://www.agilemovement.it/forum/topics/xpug-marche-chi-e-interessato

Per ora ci stiamo contando in modo da organizzare un incontro prima possibile , per decidere sul da farsi.

[WCF] Operazioni asincrone client-side

Dario Santarelli — Mon, 09 Feb 2009 22:24:15 GMT

WCF è un framework concepito per sviluppare scenari di comunicazione completamente disaccoppiati sotto ogni punto di vista. In particolare, per quanto riguarda la sincronizzazione dei messaggi, è prevista internamente una rigida implementazione di pattern asincroni per ottenere chiamate non bloccanti tra i vari livelli strutturali. Esternamente, invece, WCF espone possibilità di programmazione asincrona sia client-side che server-side. L'aspetto interessante da approfondire in merito è come il programming model asincrono client-side non abbia nulla a che vedere con quello server-side: ovvero, un client può sostanzialmente invocare in modo asincrono un servizio indipendentemente dal fatto che esso sia implementato con un pattern sincrono piuttosto che asincrono.
Il disaccoppiamento avviene infatti a livello di trasporto quando i dati vengono serializzati/deserializzati.
Per capire l’importanza di tale feature pensiamo semplicemente ad un’ architettura N-tier che poggia su WCF: potremmo avere diverse “operation” che a loro volta utilizzano proxy client verso altre operation WCF, rendendo vitale l’utilizzo di pattern di comunicazione asincroni.
Vediamo un semplice esempio. Supponiamo di avere il seguente ServiceContract:

[ServiceContract]
public interface IAuthentication
{
[OperationContract]
UserInfo Login(string username, string password);

[OperationContract]
void Logout(string username);
}

Se lato client utilizzassimo Svcutil ( con gli opportuni parametri ) o il solito “Add Service Reference” di VisualStudio, otterremmo la generazione automatica del seguente object model:

Come si può osservare abbiamo una versione asincrona client-side del ServiceContract (IAuthentication), un' interfaccia <ServiceContract>Channel (IAuthenticationChannel) ed una classe Client (AuthenticationClient) che espone metodi di invocazione sia asincroni che sincroni. Nello specifico, si prospettano due possibili modalità di invocazione asincrona client-side di un’ operation:

1. Invocazione asincrona “event-based” (o “event-driven”)
E' la modalità più semplice e raccomandata poiché richede solamente l’aggiunta di un EventHandler per ricevere una notifica all’occorrenza di una risposta. Questa modalità ( disponibile solo nel framework 3.5 e comunque solo per questo tipo di invocazione ) permette di sfruttare l’approccio asincrono event-based tramite un metodo nella forma <operationName>Async e l’intercettazione di un evento <operationName>Completed al cui interno si ha accesso al risultato dell’invocazione <operationName>CompletedEventArgs.

...

ServiceReference.AuthenticationClient client = new ServiceReference.AuthenticationClient();
client.LoginCompleted += new EventHandler<ServiceReference.LoginCompletedEventArgs>(client_LoginCompleted);
client.LoginAsync("dario.santarelli", "password");

Console.ReadLine();

client.Close();

...

protected void client_LoginCompleted(object sender, ServiceReference.LoginCompletedEventArgs e)
{
UserInfo info = e.Result as UserInfo;
Console.WriteLine(string.Format("UserName: {0} - Password: {1}",info.UserName,info.Email));
}

2. Invocazione asincrona via ChannelFactory
Il pattern asincrono previsto in questa modalità è quello classico previsto a partire dal framework 1.1: tramite lo split di un operation in due metodi ( Begin<operationName> e End<operationName> ), si sfruttano oggetti che implementano l’interfaccia System.IAsyncResult per rappresentare lo stato di una operazione asincrona.

...

EndpointAddress endpointAddress = new EndpointAddress("http://.../AuthenticationService.svc");
ServiceReference.IAuthenticationChannel channelClient = ChannelFactory<ServiceReference.IAuthenticationChannel>.CreateChannel(new BasicHttpBinding(), endpointAddress);
IAsyncResult result = channelClient.BeginLogin("dario.santarelli", "password", LoginCallBack, channelClient);

Console.ReadLine();

channelClient.Close();
channelClient.Dispose();

...

protected void LoginCallBack(IAsyncResult ar)
{
UserInfo result = ((ServiceReference.IAuthenticationChannel)ar.AsyncState).EndLogin(ar);
Console.WriteLine("Result: {0}", result.UserName);
}

Conclusioni
In entrambe le soluzioni presentate, una nostra application può invocare un’operazione in maniera asincrona anche se il servizio è implementato in maniera sincrona, allo stesso modo con cui una applicazione può usare lo stesso pattern per invocare in maniera asincrona un metodo sincrono locale. “Come” è poi implementato l’ OperationContract è assolutamente insignificante per il client.

Risorse MSDN:

Technorati Tag: WCF,Async

Visual Studio Testing Extensions

Dario Santarelli — Tue, 03 Feb 2009 19:22:57 GMT

Segnalo il progetto “Visual Studio Testing Extensions” su CodePlex. Si tratta di una library concepita principalmente per migliorare la creazione di UnitTest nell’ambiente di Testing di Visual Studio. In breve, la library introduce due feature:

La possibilità di migliorare sensibilmente la leggibilità di uno unit test grazie all’introduzione di opportuni extension methods ( es. myInt.ShouldEqual(5); invece di Assert.AreEqual(myInt, 5); )
La possibilità di asserire exception multiple nei risultati attesi di un singolo TestMethod. Il tutto sfruttando un delegate Action(). Ad esempio:

Testing.ShouldThrowException<ArgumentNullException>(() => { … something throws ArgumentNullException … });

Technorati Tag: UnitTest

[WCF] Esempio di Integration Test

Dario Santarelli — Sat, 31 Jan 2009 15:22:29 GMT

Esistono molti strumenti e tecniche per effettuare un integration test di servizi WCF. Un modo che ho trovato molto semplice ed utile si ottiene sruttando il framework di unit testing di Visual Studio: infatti, utilizzando due metodi decorati rispettivamente con ClassInitialize e ClassCleanup possiamo gestire il ciclo di vita di un ServiceHost, evitando così il deploy preventivo (es. Cassini, IIS etc.) del servizio.
Nel seguente esempio viene mostrata questa tecnica supponendo di voler testare un servizio di autenticazione AuthenticationService che implementa un service contract IAuthentication, il quale definisce due metodi: Login(…) e Logout().

[TestClass]
public class AuthenticationUnitTest
{
private static ServiceHost _serviceHost;
private static string _address = "AuthenticationService";
private static string _baseAddress = "http://127.0.0.1:5656/";

[ClassInitialize]
public static void ServiceHostInitialize(TestContext testContext)
{
    _serviceHost = new ServiceHost(typeof(AuthenticationService), new[] { new Uri(_baseAddress) });
    _serviceHost.AddServiceEndpoint(typeof(IAuthentication), new WSHttpBinding(), _address);
    _serviceHost.Open();
}

[ClassCleanup]
public static void ServiceHostCleanup() { _serviceHost.Close(); }

[TestMethod]
public void AuthenticateUser()
{
    string userName = "dario.santarelli";
    string password = "password";

    EndpointAddress endpointAddress = new EndpointAddress(string.Format("{0}{1}", _baseAddress,_address));
    IAuthentication proxy = ChannelFactory<IAuthentication>.CreateChannel(new WSHttpBinding(), endpointAddress);

    UserInfo userInfo = proxy.Login(userName, password);

    Assert.IsNotNull(userInfo);
    Assert.AreEqual(userInfo.Username, userName);

    proxy.Logout(userName);
   }
}

Update: con questa tecnica non si intende sostituire il test in ambiente di produzione, bensì fornire un modo “base” per verificare il funzionamento di una WCF Service Library. Infatti, come si può notare, in questo caso sia lo UnitTest che il ServiceHost girano nello stesso AppDomain, il che NON garantisce by design il corretto comportamento del test come se fosse in produzione. Per avere test maggiormente efficaci, si consiglia l’utilizzo di soluzioni più “evolute” come WcfSvcHost o, meglio, direttamente un ambiente di test dedicato su IIS :D.

Technorati Tag: WCF,Testing