Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.1

2011-12-242016-01-31 TPodolakAuthentication, Authorization, MembershipProvider, Silverlight

W dzisiejszym wpisie postaram się przedstawić moją koncepcję logowania do aplikacji Silverlightowej z wykorzystaniem MembershipProviders oraz własnego AuthenticationService.
Zacznijmy od stworzenia bazy danych, w której będziemy przetrzymywać informacje o użytkownikach – hasła, role itp. Bazę danych stworzymy przy użyciu narzędzia aspnet_regsql.exe, które to wygeneruje schemat bazy danych dostosowany do możliwości SqlMembershipProvider-a. aspnet_regsql.exe znajduje się w katalogu C:WINDOWS\Microsoft.NET\Framework\wersjaFrameworka\aspnet_regsql.exe. Czyli w moim przypadku jest to C:WINDOWS\Microsoft.NET\Frameworkv\4.0.30319\aspnet_regsql.exe.

Klikając podwójnie na ikonę aplikacji pojawia nam się następujące okno

Klikamy w przycisk “Dalej”. W kolejnym oknie mamy do wyboru dwie opcje

Configure SQL Server for application services
Remove application services from an existing database

Pierwsza opcja odpowiedzialna jest za stworzenie struktury danych do naszego sytemu logowania, natomiast druga usuwa z bazy danych tabele służące do logowania itp. Wybieramy opcję bramkę nr 1. W kolejnym oknie musimy podać connection string do naszego serwera bazy danych oraz login i hasło. W moim przypadku wygląda to w następujący sposób:

Jeżeli wszystko pójdzie OK pokaże się nam następujące okno, w którym to możemy zobaczyć, że została stworzona baz danych aspnetdb

Ostatecznie klikamy na przycisk “Next”,a następnie w “Finish” aby dokończyć działanie kreatora

Mając gotową bazę danych możemy przystąpić do właściwego kodowania. Zacznijmy od stworzenia nowego projektu typu “Silverlight Application”

po kliknięciu przycisku “OK” włączamy WCF RIA Service

Mając stworzony szkielet aplikacji możemy zabrać się za napisanie własnego AuthenticationService. Do projektu webowego (nazwaprojektu.Web) dodajmy nowy element typu “Domain Service”. PPM na projekt, następnie “Add new item”, w oknie które się otworzy wybieramy “Domain Service”. Nadajemu mu nazwę CustomAuthenticationService.cs

Nasza właśnie dodana klasa powinna wyglądać mniej więcej w taki sposób

namespace MainModule.Web
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.ComponentModel.DataAnnotations;
    using System.Linq;
    using System.ServiceModel.DomainServices.Hosting;
    using System.ServiceModel.DomainServices.Server;

    // TODO: Create methods containing your application logic.
    [EnableClientAccess()]
    public class CustomAuthenticationService: DomainService
    {
    }
}

namespace MainModule.Web

{

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.ComponentModel.DataAnnotations;

using System.Linq;

using System.ServiceModel.DomainServices.Hosting;

using System.ServiceModel.DomainServices.Server;

// TODO: Create methods containing your application logic.

[EnableClientAccess()]

public class CustomAuthenticationService: DomainService

{

}

W następnym kroku zaimplementujmy w klasie CustomAuthenticationService interfejs
IAuthentication where T: IUser. Interfejs ten wygląda w następujący sposób:

public interface IAuthentication<T> where T: IUser
{
    T GetUser();
    T Login(string userName, string password, bool isPersistent, string customData);
    T Logout();
    void UpdateUser(UserDTO user);
}

public interface IAuthentication<T> where T: IUser

{

T GetUser();

T Login(string userName, string password, bool isPersistent, string customData);

T Logout();

void UpdateUser(UserDTO user);

}

Widzimy zatem, że zanim go zaimplementujemy musimy posiadać obiekt implementujący inny interfejs – IUser. Przystąpmy zatem do stworzenia naszej klasy modelującej użytkownika – nazwijmy ją UserDTO.Stwórzmy nowy projekt typu “Class library”. W projekcie tym stwórzmy klasę UserDTO, która będzie dziedziczyła po klasie UserBase znajdującej się w przestrzeni nazw System.ServiceModel.DomainServices.Server.ApplicationServices

public class UserDTO : UserBase
{
    public string Email { get; set; }
    public string DisplayName { get; set; }
}

public class UserDTO : UserBase

{

public string Email { get; set; }

public string DisplayName { get; set; }

}

Mając gotową klasę reprezentującą użytkownika zaimplementujmy w końcu w klasie CustomAuthenticationService interfejs IAuthentication. Po implementacji interfejsu nasz serwis wygląda w następujący sposób:

[EnableClientAccess()]
public class CustomAuthenticationService: DomainService, IAuthentication
{
    public UserDTO GetUser()
    {
        throw new NotImplementedException();
    }
    
    public UserDTO Login(string userName, string password, bool isPersistent, string customData)
    {
        throw new NotImplementedException();
    }
    
    public UserDTO Logout()
    {
        throw new NotImplementedException();
    }
    
    public void UpdateUser(UserDTO user)
    {
        throw new NotImplementedException();
    }
}

[EnableClientAccess()]

public class CustomAuthenticationService: DomainService, IAuthentication

{

public UserDTO GetUser()

{

throw new NotImplementedException();

}

public UserDTO Login(string userName, string password, bool isPersistent, string customData)

{

throw new NotImplementedException();

}

public UserDTO Logout()

{

throw new NotImplementedException();

}

public void UpdateUser(UserDTO user)

{

throw new NotImplementedException();

}

Pozostaje nam “tylko” zaimplementować odpowiednie metody. Funkcja która nas najbardziej interesuje to oczywiście funkcja logowania. Przy jej implementacji posłuży się mechanizmem znanym z ASP mianowicie z MembershipProviders. Klasa MembershipProvider jest to abstrakcyjna klasa posiadająca szereg funkcji mającej na celu walidowanie poprawnego użytkownika, rejestrację itp. Stwórzmy zatem własną klasę providera dziedziczącą po klasie MembershipProvicer. .NET dostarcza nam domyślny provider, którym jest SqlMembershipProvider, jest on napisany w taki sposób, aby mógł porozumiewać się z bazą, którą stworzyliśmy na początku. Aby wykorzystać wspomnianego wcześniej providera musimy odpowiednio zmodyfikować plik Web.config. Po pierwsze dodajemy do niego ConnectionString do naszej bazy danych, w moim przypadku będzie to wyglądało w następujący sposób

<connectionStrings>
    <add name="aspnetdbConnectionString" connectionString="Data Source=TOMEKKOMPUTERSQLEXPRESSRC2;Initial Catalog=aspnetdb;Integrated Security=True"
      providerName="System.Data.SqlClient" />
</connectionStrings>

<add name="aspnetdbConnectionString" connectionString="Data Source=TOMEKKOMPUTERSQLEXPRESSRC2;Initial Catalog=aspnetdb;Integrated Security=True"

providerName="System.Data.SqlClient" />

</connectionStrings>

Następnie musimy “pokazać” naszej aplikacji, że będziemy używać FormsAuthentication oraz MembershipProvider-ow. Dorzućmy zatem do config następujące rzeczy:(w sekcji system.web)

<authentication mode="Forms" />

1	<authentication mode="Forms" />

następnie dorzucamy do kolekcji providerów SqlMembershipProvider

<membership
            defaultProvider="PremiumHandsMembershipProvider"
            userIsOnlineTimeWindow="20">
      <providers>
        <clear/>
        <add name="PremiumHandsMembershipProvider"
             connectionStringName="aspnetdbConnectionString"
            type="System.Web.Security.SqlMembershipProvider"
            enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/" />
      </providers>
</membership>

<membership

defaultProvider="PremiumHandsMembershipProvider"

userIsOnlineTimeWindow="20">

<add name="PremiumHandsMembershipProvider"

connectionStringName="aspnetdbConnectionString"

type="System.Web.Security.SqlMembershipProvider"

enablePasswordRetrieval="false"

enablePasswordReset="false"

requiresQuestionAndAnswer="true"

passwordFormat="Hashed"

applicationName="/" />

</providers>

</membership>

We wpisach tych dorzuciliśmy możliwość autentykacji poprzez providery, ustawiliśmy SqlMembershipProvider jako domyślny provider, oraz dorzuciliśmy go do listy wszystkich providerów. W celu sprawdzenia czy nasza konfiguracja jest poprawna możemy posłużyć się mechanizmem dostarczonym nam przez Visual Studio. Klikamy “Projekt”, a następnie ASP.NET Configuration

Zostaniemy przeniesieni do domyślnej przeglądarki internetowej, a naszym oczom ukaże się następująca strona.

Z poziomu tej stronki możemy dodawać użytkowników, przydzielać im role itp, dzięki czemu możemy szybko sprawdzić czy podstawowe funkcje naszego providera działają, oraz czy nasza konfiguracja została przeprowadzona prawidłowo. Wracając natomiast do naszego systemu logowania, pozostało nam jedynie odpowiednio zmodyfikować funkcję odpowiedzialną za logowanie.Robimy to w następujący sposób:

protected  UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
{
    UserDTO user = null;
    userData = null;
    
    if (Membership.Provider.ValidateUser(name, password))
    {
        userData = name;
        user =  new UserDTO {DisplayName = name,Name = name,Email = name};
    }
    
    if (user != null) userData = name;
    
    return user;
}

public UserDTO Login(string userName, string password, bool isPersistent, string customData)
{
    string userData;
    UserDTO user = ValidateCredentials(userName, password, customData, out userData);
    
    if (user != null)
    {
        FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(/* version */ 1, userName,
                                                   DateTime.Now, DateTime.Now.AddMinutes(30),
                                                   isPersistent,
                                                   userData,
                                                   FormsAuthentication.FormsCookiePath);
                                                   
        string encryptedTicket = FormsAuthentication.Encrypt(ticket);
        HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
        HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));
        httpContext.Response.Cookies.Add(authCookie);
    }
    else
    {
        HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));
        httpContext.AddError(new FormsAuthenticationLogonException("Nieprawidłowy login lub hasło"));
    }
    return user;
}

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)

{

UserDTO user = null;

userData = null;

if (Membership.Provider.ValidateUser(name, password))

{

userData = name;

user = new UserDTO {DisplayName = name,Name = name,Email = name};

}

if (user != null) userData = name;

return user;

}

public UserDTO Login(string userName, string password, bool isPersistent, string customData)

{

string userData;

UserDTO user = ValidateCredentials(userName, password, customData, out userData);

if (user != null)

{

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(/* version */ 1, userName,

DateTime.Now, DateTime.Now.AddMinutes(30),

isPersistent,

userData,

FormsAuthentication.FormsCookiePath);

string encryptedTicket = FormsAuthentication.Encrypt(ticket);

HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);

HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));

httpContext.Response.Cookies.Add(authCookie);

}

else

{

HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));

httpContext.AddError(new FormsAuthenticationLogonException("Nieprawidłowy login lub hasło"));

}

return user;

}

W funkcji ValidateCredentials odbywa się sprawdzanie czy użytkownik podał właściwe hasło oraz login. Do walidacji wykorzystujemy dodany wcześniej SqlMembershipProvider – właściwość Membership.Provider zawsze zwraca obiekt domyślnie zdefiniowanego providera. W przypadku gdy walidacja się powiedzie tworzymy obiekt użytkownika, a następnie tworzymy i szyfrujemy FormsAuthenticationTicket oraz tworzymy ciasteczko (cookie), które przesyłamy w responsie wysyłanym przez serwer do klienta. Mechanizm logowania jest już prawie gotowy. Musimy jedynie zaimplementować jeszcze pozostałe funkcje interfejsu IAuthentication.Nie ma raczej w nich nic trudnego

public UserDTO Logout()
{
    FormsAuthentication.SignOut();
    return null;
}

public UserDTO GetUser()
{
    IPrincipal currentUser = ServiceContext.User;
    
    if ((currentUser != null) && currentUser.Identity.IsAuthenticated)
    {
        FormsIdentity userIdentity = currentUser.Identity as FormsIdentity;
        if (userIdentity != null)
        {
            FormsAuthenticationTicket ticket = userIdentity.Ticket;
            if (ticket != null && !ticket.Expired)
            {
                 return new UserDTO { DisplayName = currentUser.Identity.Name, Name = currentUser.Identity.Name };
            }
        }
    }
    
    return null;
}

public UserDTO Logout()

{

FormsAuthentication.SignOut();

return null;

}

public UserDTO GetUser()

{

IPrincipal currentUser = ServiceContext.User;

if ((currentUser != null) && currentUser.Identity.IsAuthenticated)

{

FormsIdentity userIdentity = currentUser.Identity as FormsIdentity;

if (userIdentity != null)

{

FormsAuthenticationTicket ticket = userIdentity.Ticket;

if (ticket != null && !ticket.Expired)

{

return new UserDTO { DisplayName = currentUser.Identity.Name, Name = currentUser.Identity.Name };

}

return null;

}

Funkcja Logout po prostu wywołuje funkcję SingOut z klasy FormsAuthentication. Natomiast funkcja GetUser zwraca zalogowanego użytkownika. W funkcji tej najpierw sprawdzamy czy użytkownik jest zalogowany (do tego celu używamy zmiennej IsAuthenticated), a następnie sprawdzamy czy przypadkiem jego sesja nie wygasła. W przypadku gdy wszystko jest OK zwracamy obiekt typu UserDTO,w przeciwnym razie zwracamy null.

Podsumowując, udało nam się stworzyć mechanizm logowania. Jak na razie gotowa jest strona serwera.
W następnym wpisie pokażę w jaki sposób należy wywołać logowanie od strony klienta. Przedstawię również pomysł w jaki sposób zmieniać providerów przez które użytkownik ma się logować. Może to być przydatne jeżeli chcielibyśmy logować się np. poprzez inne serwisy jak Google, Facebook itp.

Interactivity oraz Interaction

2011-11-292016-01-31 TPodolakBehavior, Interaction, Interactivity, Prism, Silverlight, WPF

Interactions oraz Interactivity są to dwie dll-ki, które poszerzają sposób komunikacji pomiędzy widokiem oraz ViewModelem. Wprowadzają one nowy typ EventTriggerów(w Silverlighcie nie ma triggerów, natomiast w WPF-ie event triggery można praktycznie używać jedynie do animacji) oraz dodatkowo wprowadzają ciekawe sposoby(funkcje) na interakcję widoku z ViewModelem. Pierwszym z tych sposobów jest użycie właściwości InvokeCommandAction.Jak sama nazwa wskazuje można wywołać komendę z ViewModelu. Jaka jest różnica między wywołaniem komendy poprzez InvokeCommandAction, a Command=”{Binding CommandName}” ? InvokeCommandAction ma tą przewagę nad normalnm bindowaniem do property Command,że pozwala wywołać daną komendę w odpowiedzi na zajście jakiegoś zdarzenia na widoku. Przykładowe użycie może wyglądać następująco:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
      <i:Interaction.Triggers>
        <i:EventTrigger EventName="MouseMove">
           <i:InvokeCommandAction Command="{Binding SubmitCommand}"/>
        </i:EventTrigger>
      </i:Interaction.Triggers>
</Button>

<i:Interaction.Triggers>

<i:EventTrigger EventName="MouseMove">

<i:InvokeCommandAction Command="{Binding SubmitCommand}"/>

</i:EventTrigger>

</i:Interaction.Triggers>

</Button>

Powyższy przykład działa w następujący sposób. Za każdym razem gdy zostanie wywołane zdarzenie MouseMove na przycisku, odpalona zostanie komenda SubmitCommand. Wadą używania InvokeCommandAction jest to, że sami musimy się martwić o wygaszenie kontrolki w przypadku gdy dana komenda nie może być wykonana. Dlatego też w pierwszej linii mamy bindowanie właściwości IsEnabled przycisku do właściwości CanSubmit z ViewModelu. Alias i: jest aliasen na namespace interactivity z dll-ki

System.Windows.Interactivity.xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity".

1	System.Windows.Interactivity.xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity".

Drugim sposobem powiadomiania ViewModelu o jakimś zdarzeniu w widoku jest użycie InvokeMethodAction. Dzięki tej właściwości możemy bezpośrednio z widoku (z XAML-a) wywołać funkcję w ViewModelu. Składnia przedstawia się w następujący sposób:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
     <i:Interaction.Triggers>
       <i:EventTrigger EventName="Click">
        <i:CallMethodAction TargetObject="{Binding}"      Method="Submit"/>
      </i:EventTrigger>
     </i:Interaction.Triggers>
</Button>

<i:Interaction.Triggers>

<i:EventTrigger EventName="Click">

<i:CallMethodAction TargetObject="{Binding}" Method="Submit"/>

</i:EventTrigger>

</i:Interaction.Triggers>

</Button>

TargetObject jest zbindowany do DataContextu, to właśnie tam będzie szukana funkcja Submit. Należy pamiętać, że właściwość CallMethodAction nie wspiera parametrów funkcji. Zatem jeżeli musimy wywołać jakąś funkcję z parametrami, należy opakować ją w funkcję bezparametrową, natomiast wszystkie parametry przekazać z właściwości ViewModelu.

Kolejnym ciekawym featurem Interactivity jest klasa Behavior. Jest niezastąpiona jeżeli potrzebujemy ingerować w działanie widoku po jakimś zdarzeniu. Nie musimy wówczas tworzyć obsługi eventów w code behind. Możemy wyłuskać daną funkcjonalność i zamknąć ją w klasie Behavior a następnie doczepić do wszystkich widoków danego typu. Załóżmy, że sterujemy ListBoxem z poziomu ViewModelu (przełączamy SelectedItem). Możemy zaznaczyć jakiś Item, co jednak jeżeli nasza lista jest bardzo długa,a zaznaczamy ostatni element. Na widoku element rzeczywiście się zaznaczył jednak lista się nie przewinęła. Przez co cały czas wiszą elementy z początku i nie widać czy któryś element jest zaznaczony. Dopiero gdy przeskrolujemy ręcznie ListBoxa widzimy, że rzeczywiście prawidłowo zareagował na zmianę property w ViewModelu. Jest to idealna sytuacja, aby stworzyć własny Behavior, który będziemy mogli podczepić do wszystkich listboxów w każdym widoku.

public class Behavior<ListBox>
{

protected override void OnAttached()
{
 AssociatedObject.SelectionChanged += ListBoxSelectionChanged;
}

protected override void OnDetaching()
{
  AssociatedObject.SelectionChanged -= ListBoxSelectionChanged;
}

private void ListBoxSelectionChanged(object sender, SelectionChangedEventArgs e)
{
         if (sender is ListBox && ((ListBox)sender).SelectedItem != null)
         {
             var listBox = sender as ListBox;
             listBox.ScrollIntoView(listBox.SelectedItem);
         }
  }
}

public class Behavior<ListBox>

{

protected override void OnAttached()

{

AssociatedObject.SelectionChanged += ListBoxSelectionChanged;

}

protected override void OnDetaching()

{

AssociatedObject.SelectionChanged -= ListBoxSelectionChanged;

}

private void ListBoxSelectionChanged(object sender, SelectionChangedEventArgs e)

{

if (sender is ListBox && ((ListBox)sender).SelectedItem != null)

{

var listBox = sender as ListBox;

listBox.ScrollIntoView(listBox.SelectedItem);

}

Metoda OnAttached odpala się w momencie, gdy behavior jest podpinany do kontrolki. W metodzie tej powinniśmy podpiąć się pod wszystkie eventy, które są dla nas istotne. W momencie, gdy widok jest niszczony wywołuje się metoda OnDetaching, w której powinniśmy odpiąć wszystkie metody od eventów.

Prism – CommandBehaviors

2011-11-292016-01-31 TPodolakCommandBehaviors, Prism, Silverlight, WPF

Analizując wcześniejsze przykłady pokazujące użycie DelegateCommand można odnieść wrażenie, że mimo tego iż są one bardzo użyteczne,ich użycie jest niestety bardzo ograniczone.
Jedynie niektóre komponenty WPF-a i Silverlight-a mają właściwość Command do której można zbindować nasz obiekt DelegateCommand.Ponadto właściwość ta reaguje jedynie na wybrane zahardcodowane w kontrolce zdarzenie (zdarzenie Click). Co w przypadku gdybyśmy chcieli zareagować np. na zdarzenie MouseMove za pomocą komendy? Nasz problem możemy rozwiązać poprzez:

Interactivity
Interactions
CommandBehaviors

W tym poście zostanie przedstawione rozwiązanie trzecie – CommandBehaviors

Pierwszą rzeczą jaką należy zrobić w celu stworzenia komendy reagującej na inne zdarzenie niż Click jest stworzenie klasy dziedziczącej po CommandBehaviorBase. Załóżmy, że zrobimy komendę reagującą na zdarzenie MouseMove

public class MouseMoveCommandBehavior : CommandBehaviorBase<Control>
{
    private MouseOutCommandBehavior(Control control) : base(control)
    {
        control.MouseMove += (sender, args) => 
        {
            this.ExecuteCommand();
        };
    }
}

public class MouseMoveCommandBehavior : CommandBehaviorBase<Control>

{

private MouseOutCommandBehavior(Control control) : base(control)

{

control.MouseMove += (sender, args) =>

{

this.ExecuteCommand();

};

}

Piersza część już za nami, ale pojawia się teraz pytanie jak z tego skorzystać. Żeby mieć możliwość użycia powyżej klasy wykorzytamy attached dependency property. Musimy sobie stworzyć pomocniczą statyczną klasę, w której to zarejestrujemy nasze właściwości. Zacznijmy od zarejestrowania dependency property o nazwie Command – do tego obiektu będziemy bindowali komendy z ViewModelu (komendy reagujące na zdarzenie MouseMove)

public static class MouseMove 
{
    public static ICommand GetCommand(DependencyObject obj)
    {
        return (ICommand)obj.GetValue(CommandProperty);
    }

    public static void SetCommand(DependencyObject obj, ICommand value)
    {
        obj.SetValue(CommandProperty, value);
    }

    public static readonly DependencyProperty CommandProperty =
            DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandCallback));
}

public static class MouseMove

{

public static ICommand GetCommand(DependencyObject obj)

{

return (ICommand)obj.GetValue(CommandProperty);

}

public static void SetCommand(DependencyObject obj, ICommand value)

{

obj.SetValue(CommandProperty, value);

}

public static readonly DependencyProperty CommandProperty =

DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandCallback));

}

zauważmy, że podłączyliśmy event handlera reagującego na zmianę naszej nowo stworzonej właściwości Command. Funkcja OnSetCustomCommandCallback wygląda następująco:

private static void OnSetCustomCommandCallback(DependencyObject dep, DependencyPropertyChangedEventArgs e)
{
    var control = dep as Control;
    if (control != null)
    {
        MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(control);
        behavior.Command = e.NewValue as ICommand;
    }
}

private static void OnSetCustomCommandCallback(DependencyObject dep, DependencyPropertyChangedEventArgs e)

{

var control = dep as Control;

if (control != null)

{

MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(control);

behavior.Command = e.NewValue as ICommand;

}

Funkcja ta po prostu w razie potrzeby tworzy nowy obiekt typu MouseMoveCommandBehavior (gdy ktoś zbinduje komende) i dopina go do naszej kontrolki. Pomocnicza funkcja GetorCreateMouseMoveBehavior wygląda tak:

private static MouseMoveCommandBehavior GetorCreateMouseMoveBehavior(Control listBox)
{
    var behavior = listBox.GetValue(MouseMoveBehaviorProperty) as
        MouseMoveCommandBehavior;
    if (behavior == null)
    {
        behavior = new MouseMoveCommandBehavior(listBox);
        listBox.SetValue(MouseMoveBehaviorProperty, behavior);
    }
    return behavior;
}

private static MouseMoveCommandBehavior GetorCreateMouseMoveBehavior(Control listBox)

{

var behavior = listBox.GetValue(MouseMoveBehaviorProperty) as

MouseMoveCommandBehavior;

if (behavior == null)

{

behavior = new MouseMoveCommandBehavior(listBox);

listBox.SetValue(MouseMoveBehaviorProperty, behavior);

}

return behavior;

}

Obiekt rejestrowany poprzez funkcję GetorCreateMouseMoveBehavior jest dopinany do kolejnej attached property, która również została zadeklarowana w tym pliku

public static MouseMoveCommandBehavior GetMouseMoveBehavior(DependencyObject obj)
{
    return (MouseMoveCommandBehavior)obj.GetValue(MouseMoveBehaviorProperty);
}

public static void SetMouseMoveBehavior(DependencyObject obj, MouseMoveCommandBehavior value)
{
    obj.SetValue(MouseMoveBehaviorProperty, value);
}

public static readonly DependencyProperty MouseMoveBehaviorProperty =
    DependencyProperty.RegisterAttached("MouseMoveBehavior", typeof(MouseMoveCommandBehavior), typeof(MouseMove), null );

public static MouseMoveCommandBehavior GetMouseMoveBehavior(DependencyObject obj)

{

return (MouseMoveCommandBehavior)obj.GetValue(MouseMoveBehaviorProperty);

}

public static void SetMouseMoveBehavior(DependencyObject obj, MouseMoveCommandBehavior value)

{

obj.SetValue(MouseMoveBehaviorProperty, value);

}

public static readonly DependencyProperty MouseMoveBehaviorProperty =

DependencyProperty.RegisterAttached("MouseMoveBehavior", typeof(MouseMoveCommandBehavior), typeof(MouseMove), null );

Mając zdefiniowane wszystkie powyższe właściwości możemy już wykorzystać naszą komendę. Jednakże przydałoby się dodać jeszcze jedną właściwość (opcjonalnie), mianowicie właściwość CommandParameters

public static object GetCommandParametr(DependencyObject obj)
{
    return (object)obj.GetValue(CommandParametrProperty);
}

public static void SetCommandParametr(DependencyObject obj, object value)
{
    obj.SetValue(CommandParametrProperty, value);
}

public static readonly DependencyProperty CommandParametrProperty =
    DependencyProperty.RegisterAttached("CommandParametr", typeof(object), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandParameterCallback));

public static object GetCommandParametr(DependencyObject obj)

{

return (object)obj.GetValue(CommandParametrProperty);

}

public static void SetCommandParametr(DependencyObject obj, object value)

{

obj.SetValue(CommandParametrProperty, value);

}

public static readonly DependencyProperty CommandParametrProperty =

DependencyProperty.RegisterAttached("CommandParametr", typeof(object), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandParameterCallback));

W tym propertisie również reagujemy na przypisnie obiektu.Handler OnSetCustomCommandParameterCallback wygląda następująco

private static void OnSetCustomCommandParameterCallback(DependencyObject dep,DependencyPropertyChangedEventArgs e)
{
    var listBox = dep as Control;
    if (listBox != null)
    {
        MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(listBox); ;
            behavior.CommandParameter = e.NewValue;
    }
}

private static void OnSetCustomCommandParameterCallback(DependencyObject dep,DependencyPropertyChangedEventArgs e)

{

var listBox = dep as Control;

if (listBox != null)

{

MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(listBox); ;

behavior.CommandParameter = e.NewValue;

}

Mając już zdefiniowane wszystkie niezbędne właściwości możemy użyć ich w XAML-u. Po pierwsze musimy dodać alias do namespaca gdzie znajduje się nasza statycza klasa MouseMove. W moim przypadku wygląda to następująco:

xmlns:AttachedCommands="clr-namespace:MainModule.Commands"

1	xmlns:AttachedCommands="clr-namespace:MainModule.Commands"

Następnie bindujemy jakąś kontrolkę do naszego attached property Command. Wygląda to w następujący sposób:

<Button Name="txtButton" Grid.Column="2" AttachedCommands:MouseMove.Command="{Binding SomeCommandFromViewModel}"></Button>

1	<Button Name="txtButton" Grid.Column="2" AttachedCommands:MouseMove.Command="{Binding SomeCommandFromViewModel}"></Button>

Od teraz za każdym razem jak najedziemy na txtButton wywoła się komenda SomeCommandFromViewModel.
Podsumowując trzeba się całkiem sporo napisać żeby zmusić do działania CommandBehaviors . W następnym poście przedstawię dwa sposoby na osiągnięcie tego samego efektu mniejszym kosztem.

Prism – Komendy

2011-11-292016-01-31 TPodolakCompositeCommand, DelegateCommand, Prism, Silverlight, WPF

1. DelegateCommands

DelegateCommands w Prismie są to obiekty, które implementują interfejs ICommand, służą one do interakcji widoku z ViewModelem. Korzystając z Prisma nie musimy już pisać własnej klasy implementującej ten interfejs (tak jak to zrobiliśmy tutaj). Konstruktor klasy DelegateCommand przyjmuje dwa parametry:

Action execteMethod – funkcja odpalania przy wywołaniu komendy,
Func canExecuteMethod – funkcja sprawdzająca czy daną komendę można wywołać

DelegateCommands z Prisma używamy w taki sam sposób w jaki używaliśmy komend w tym poście.

2. CompositeCommands

CompositeCommands są to obiekty, które przechowują kolekcją obiektów typu DelegateCommand. Tworzenie CompositeCommand jest bardzo proste.
Po pierwsze musimy stworzyć obiekt typu CompositeCommand

public CompositeCommand SomeCompositeCommand = new CompositeCommand();

1	public CompositeCommand SomeCompositeCommand = new CompositeCommand();

następnie rejestrujemy w tym obiekcie obiekt implementujący interfejs ICommand, czyli w naszym przypadku jakiś obiekt typu DelegateCommand. Robimy to w następujący sposób:

DelegateCommand DistributeCommand = new DelegateCommand(DistributeCards);
SomeCompositeCommand.RegisterCommand(DistributeCommand);

1 2	DelegateCommand DistributeCommand = new DelegateCommand(DistributeCards); SomeCompositeCommand.RegisterCommand(DistributeCommand);

w razie potrzeby możemy usunąć komendę z kolekcji komend przy pomocy następującej składni:

SomeCompositeCommand.UnregisterCommand(DistributeCommand);

1	SomeCompositeCommand.UnregisterCommand(DistributeCommand);

Mając już stworzony obiekt typu CompositeCommand oraz zarejestrowane w nim obiekty DelegateCommand możemy zastosować bindowanie.

<Button Command="{Binding SomeCompositeCommand}" Grid.Column="1">Rodzaj</Button>

1	<Button Command="{Binding SomeCompositeCommand}" Grid.Column="1">Rodzaj</Button>

Od teraz, w chwili naciśnięcia przycisku, najpierw sprawdzane jest czy dana CompositeCommand może zostać wykonana. CompositeCommand może zostać wykonana tylko wtedy, gdy wszystkie komendy do niej podpięte mogą zostać wykonane. Jeżeli warunek ten zostanie spełniony następuje wywoływanie po kolei wszystkich metod execute z komend podpiętych do danej CompositCommand. CompositeCommand znajduje zastosowanie w przypadku gdy pozwalamy użytkownikowi na edycję wielu elementów jednocześnie i potrzebujemy w prosty sposób przeprowadzić walidację na poszczególnych widokach.

CompositeCommand może również wykorzystana np. do zapisania tylko aktywnego widoku. Dzięki temu, że DelegateCommand implementuje interfejs IActiveAware, CompositeCommand wie, który widok jest aktualnie zaznaczony i zapisze tylko wybrany widok.

Interfejs IActiveAware wygląda w następujący sposób

public interface IActiveAware
{    
    bool IsActive { get; set; }
    event EventHandler IsActiveChanged;
}

public interface IActiveAware

{

bool IsActive { get; set; }

event EventHandler IsActiveChanged;

}

bool IsActive – wskazuje czy dana komenda jest aktualnie aktywna
event EventHandler IsActiveChanged – informuje o zmianie aktywności komendy

W celu wykorzystania tego interfejsu przez CompositeCommand należy skorzystać z drugiego dostępnego konstruktora tej klasy

CompositeCommand SomeCompositeCommand = new CompositeCommand(true);

1	CompositeCommand SomeCompositeCommand = new CompositeCommand(true);

Od teraz po naciśnięciu przycisku zbindowanego do tej komendy, wywołana zostanie jedynie aktywna komenda – czyli taka, której właściwość IsActive została ustawiona na true. Niestety o ustawianie aktywności danej komendy musimy zadbać sami.

Walidacja

2011-11-282016-01-31 TPodolakIDataErrorInfo, INotifyErrorInfo, Silverlight, Walidacja, WPF

Walidacja jest to technika sprawdzająca, czy dany obiekt spełnia pewne założenia poprawności danych. W WPF-ie oraz Silverlighcie istnieją trzy sposoby walidacji obiektów:

walidacja poprzez rzucanie wyjątków,
walidacja z użyciem interfejsu IDataErrorInfo,
walidacja z użyciem interfejsu INotifyDataErrorInfo

1. Walidacja poprzez rzucanie wyjątków

Walidacja poprzez rzucanie wyjątków odbywa się w następujący sposób. W seterze danej właściwości dodajemy warunek sprawdzający czy wpisane dane są poprawne. Jeżeli nie to najzwyczajniej w świecie rzucamy wyjątek, w którym podajemy komunikat błędu. Przykładowy properties z walidacją może wyglądać w ten sposób:

private string _name;
public string Name
{
    get { return _name; }
    set
    {
        _name = value;
        if (string.IsNullOrEmpty(_name))
            throw new Exception("Nazwa nei może być pusta");
    }
}

private string _name;

public string Name

{

get { return _name; }

set

{

_name = value;

if (string.IsNullOrEmpty(_name))

throw new Exception("Nazwa nei może być pusta");

}

W celu “wyłapania” tego wyjątku i pokazania odpowiedniego komunikatu,w bindingu musimy ustawić właściwość ValidatesOnExceptions na wartość true.

<TextBox Text="{Binding Name, ValidatesOnExceptions=True, Mode=TwoWay}" />

1	<TextBox Text="{Binding Name, ValidatesOnExceptions=True, Mode=TwoWay}" />

Taki sposób walidowania jest jednak rzadko stosowany i wielu programistów twierdzi, że rzucanie wyjątków powinno się odbywać tylko w przypadku nieprawidłowego działania aplikacji. Ponadto walidowane propertisy nie mogą być autopropertisami, co dodatkowo wydłuża czas tworzenia klas.

2. Walidacja z użyciem interfejsu IDataErrorInfo

public interface IDataErrorInfo
{
    string this[string columnName] { get; }
    string Error { get; }
}

public interface IDataErrorInfo

{

string this[string columnName] { get; }

string Error { get; }

}

W celu wyłapywania błędów w widoku, należy w bindingu ustawić ValidatesOnDataError = true

<TextBox Text="{Binding Name, ValidatesOnDataError=True, Mode=TwoWay}" />

1	<TextBox Text="{Binding Name, ValidatesOnDataError=True, Mode=TwoWay}" />

Przykładowa klasa implementująca interfejs IDataErrorInfo może wyglądać następująco:

public class Customer : IDataErrorInfo
{
    public string Name { get; set; }
    
    public string Error
    {
        get { return string.Empty; }
    }
    
    public string this[string propertyName]
    {
        get 
        {
            string result = string.Empty;
            if (propertyName == "Name")
            {
                if (string.IsNullOrEmpty(Name))
                    result = "Wartość nie moż być pusta";
            }
            
            return result;
        }
    }
}

public class Customer : IDataErrorInfo

{

public string Name { get; set; }

public string Error

{

get { return string.Empty; }

}

public string this[string propertyName]

{

get

{

string result = string.Empty;

if (propertyName == "Name")

{

if (string.IsNullOrEmpty(Name))

result = "Wartość nie moż być pusta";

}

return result;

}

Najważniejszą metodą w powyższej klasie jest indekser

string this[string propertyName]

1	string this[string propertyName]

to właśnie tutaj mogą zostać sprawdzone wszystkie właściwości danego obiektu – propertyName oznacza nazwę propertisu, który walidujemy. W przypadku, gdy wartość jakiejś właściwości jest nieprawidłowa, w pole result wpisujemy komunikat błędu. Komunikaty te “wyłapywane” są przez widok, a następnie wyświetlane w postaci komunikatów przy odpowiednich kontrolkach. Jeżeli wszystko jest OK zwracamy string.Empty.Walidacje przy pomocy interfejsu IDataErrorInfo idealnie nadają się do walidowania modelu.

3. Walidacja z użyciem interfejsu INotifyDataErrorInfo

Interfejs INotifyDataErrorInfo prezentuje się w następujący sposób:

public interface INotifyDataErrorInfo
{
     bool HasErrors { get; }
     event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
     IEnumerable GetErrors(string propertyName);
}

public interface INotifyDataErrorInfo

{

bool HasErrors { get; }

event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

IEnumerable GetErrors(string propertyName);

}

bool HasErrors – określa czy dany obiekt zawiera błędy
event EventHandler ErrorsChanged– zdarzenie informujące o zmienie ilości błędów w obiekcie
IEnumerable GetErrors(string propertyName) – funkcja pobierająca kolekcję błędów dla danego propertisa

W celu “wyłapania” błędów przez widok należy w bindingu ustawić properties
NotifyOnValidationError = true

<TextBox Text="{Binding Name, NotifyOnValidationError=True, Mode=TwoWay}" />

1	<TextBox Text="{Binding Name, NotifyOnValidationError=True, Mode=TwoWay}" />

Jak już wcześniej wspomniano funkcja GetErrors(string propertyName) zwraca kolekcję błędów dla danej właściwości. Zatem do klasy, która będzie implementowała interfejs INotifyDataErrorInfo należy dodać kolekcję przechowującą obiekty typu ValidationResult. Przykładowa implementacja interfejsu może wyglądać w następujący sposób:

public class BaseViewModel : INotifyDataErrorInfo
{
    private ICollection<ValidationResult> _validationResults;
    public IEnumerable GetErrors(string propertyName)
    {
        return _validationResults.Where(result => result.MemberNames.Contains(propertyName));
    }
 
    public bool HasErrors
    {
        get { return _validationResults.Count > 0; }
    }
 
    public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
    
    private void NotifyErrorsChanged(string propertyName)
    {
        if(ErrorsChanged!=null)
            ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));
    }

    protected void Validate()
    {
        _validationResults.Clear();
        Validator.TryValidateObject(this, new ValidationContext(this, null, null), _validationResults, true);
     
        foreach (var result in _validationResults)
            NotifyErrorsChanged(result.MemberNames.First());
    }
    
    protected void Validate(string propertyName)
    {
        var validationResults = _validationResults.Where(result => result.MemberNames.Contains(propertyName)).ToList();
        foreach (var result in validationResults)
               _validationResults.Remove(result);
        
        Validator.TryValidateProperty(value, new ValidationContext(this, null, null) { MemberName = propertyName }, _validationResults);
           NotifyErrorsChanged(propertyName);
     }
}

public class BaseViewModel : INotifyDataErrorInfo

{

private ICollection<ValidationResult> _validationResults;

public IEnumerable GetErrors(string propertyName)

{

return _validationResults.Where(result => result.MemberNames.Contains(propertyName));

}

public bool HasErrors

{

get { return _validationResults.Count > 0; }

}

public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

private void NotifyErrorsChanged(string propertyName)

{

if(ErrorsChanged!=null)

ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));

}

protected void Validate()

{

_validationResults.Clear();

Validator.TryValidateObject(this, new ValidationContext(this, null, null), _validationResults, true);

foreach (var result in _validationResults)

NotifyErrorsChanged(result.MemberNames.First());

}

protected void Validate(string propertyName)

{

var validationResults = _validationResults.Where(result => result.MemberNames.Contains(propertyName)).ToList();

foreach (var result in validationResults)

_validationResults.Remove(result);

Validator.TryValidateProperty(value, new ValidationContext(this, null, null) { MemberName = propertyName }, _validationResults);

NotifyErrorsChanged(propertyName);

}

Funkcja Validate() najpierw czyści wszystkie poprzednie wyniki walidacji, a następnie przy pomocy klasy Validator oraz funkcji TryValidateObject waliduje wszystkie właściwości, które zostały oznaczone atrybutem dziedziczącym po klasie ValidationAttribute.Z kolei funkcja Validate(string propertyName) waliduje tylko konkretną właściwość.
Przykładowe walidowanie właściwości przy pomocy atrybutów może wyglądać w następujący sposób:

[Required(ErrorMessage = "Pole nie może być puste")]
public string Subject
{
    get { return _subject; }
    set
    {
        _subject = value;
         Validate(“Subject”)
    }
}

[Required(ErrorMessage = "Pole nie może być puste")]

public string Subject

{

get { return _subject; }

set

{

_subject = value;

Validate(“Subject”)

}

W celu stworzenia własnych regół walidacji, nie uwzględnionych w zapewnionych przez framework atrybutach należy stworzyć własną klasę dziedziczącą po klasie ValidationAttribute, a następnie przeciążyć metodę IsValid. Przykładowa klasa może wyglądać w następujący sposób:

public class IntValidation : ValidationAttribute
{
    private bool allowNull;
    public IntValidation(bool allowNull)
    {
        this.allowNull = allowNull;
    }
    
    protected override ValidationResult IsValid(object value, ValidationContext validationContext)
    {
        if (value != null)
        {
            int resul;
            if (int.TryParse(value.ToString(), out resul))
                return ValidationResult.Success;
            else
                return new ValidationResult(ErrorMessage, new List{validationContext.MemberName });
        }
        
        return allowNull ? ValidationResult.Success : new ValidationResult(ErrorMessage);
    }
}

public class IntValidation : ValidationAttribute

{

private bool allowNull;

public IntValidation(bool allowNull)

{

this.allowNull = allowNull;

}

protected override ValidationResult IsValid(object value, ValidationContext validationContext)

{

if (value != null)

{

int resul;

if (int.TryParse(value.ToString(), out resul))

return ValidationResult.Success;

else

return new ValidationResult(ErrorMessage, new List{validationContext.MemberName });

}

return allowNull ? ValidationResult.Success : new ValidationResult(ErrorMessage);

}

Walidacja przy użyciu interfejsu INotifyDataErrorInfo idealnie nadaje się (wg mnie) do walidowaniu całych ViewModeli. Przy zamykaniu okna wystarczy wywołać funkcję Validate() z bazowego ViewModelu, a w przypadku gdy zwróci ona false zatrzymać zamykanie okna. Jako, że walidacja zostanie przeprowadzona na wszystkich wybranych przez nas propertisach, widok automatycznie się zaktualizuje i pokaże komunikaty błędów na odpowiednich kontrolkach okna.

.NET BLOG

.NET, C# blog

Silverlight

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.1

Interactivity oraz Interaction

Prism – CommandBehaviors

Prism – Komendy

1. DelegateCommands

2. CompositeCommands

Walidacja

1. Walidacja poprzez rzucanie wyjątków

2. Walidacja z użyciem interfejsu IDataErrorInfo

3. Walidacja z użyciem interfejsu INotifyDataErrorInfo