NHibernate 3 i QueryOver API

Całkiem niedawno pojawiła się nowa wersja NHibernate oznaczona numerem 3. Informacje co, gdzie i jak uległo zmianie można oczywiście znaleźć na głównej stronie projektu. Mi z tych wszystkich nowości najbardziej przypadło do gustu nowe API do wykonywania zapytań czyli QueryOver.

Fluent Validation i dziedziczenie

FluentValidation jest całkiem przyjemną biblioteką, która jak wskazuje nazwa dostarcza narzędzie do walidacji klas poprzez interfejs typu fluent. Co czyni ją bardzo prostą w użyciu (przykłady w dokumentacji). Poza standardowym przypadkiem tzn mamy klasę, mamy walidator i gotowe, wspiera również zagnieżdżenia klas oraz walidację kolekcji. Do pewnego czasu wydawało mi się, że więcej do szczęścia nie będzie mi potrzebne. Zawsze jest jednak jakieś ale... Biblioteka ze względu na sposób budowania walidatorów (dziedziczenie po klasie AbstractValidator<T>) nie wspiera dziedziczenia ich samych, co jednak czasem może się przydać.

Operacje asynchroniczne, czyli C# 5.0

Każda kolejna wersja platformy .NET wprowadza coraz "fajniejsze" ułatwienia dla programisty. I chyba trudno się z tym stwierdzeniem nie zgodzić. Zaczęło się od anonimowych delegatów. Później bardziej funkcyjne podejście i LINQ. W .NET 4.0 wprowadzono słowo kluczowe dynamic. Teraz przyszedł czas na lepsze wsparcie dla operacji asynchronicznych. Od wczoraj dostępny jest do pobrania Visual Studio Async CTP, który do C# i VB wprowadza dwa nowe słowa kluczowe await oraz async.

Debugowanie testów jednostkowych NUnit

Główną rolą testów jednostkowych jest wspomaganie wytwarzania oprogramowania poprzez testowanie element po elemencie (jednostce) całego rozwiązania. O ich zaletach nie trzeba się specjalnie rozwodzić ponieważ temat ten był i wciąż jest wałkowany na wielu blogach i serwisach tematycznych. Istotne jest, że po uruchomieniu testu wiemy co poszło nie tak, gdzie oraz jaki wynik powinniśmy otrzymać, a jaki otrzymaliśmy. W tym wszystkim zawsze brakowało mi jednak dokładnej wiedzy dlaczego coś poszło nie tak. Stąd możliwość debugowania testów jednostkowych wydaje się bardzo kusząca.

Problem PasswordBox przy wykorzystaniu wzorca MVVM

PasswordBox jak łatwo się domyślić jest standardową kontrolką WPF dzięki której użytkownik otrzymuje zamaskowane pole tekstowe do wpisywanie haseł itp. Kontrolka spisuje się wyśmienicie do czasu gdy przy budowaniu aplikacji nie wykorzystywany jest wzorzec MVVM (i inne pokrewne Model-View-* oparte o bindowaniu). Powód jest bardzo prosty. Ze względów bezpieczeństwa właściwość Password kontrolki nie jest uznawana jako Dependency Property co uniemożliwia bindowanie. Panowie z MS dokonali akurat takiego wyboru ponieważ wymusiłoby to ciągłe utrzymanie jawnego hasła w pamięci.

Problem zależności pomiędzy zewnątrznymi bibliotekami

Wykorzystując zewnętrzne biblioteki można bardzo łatwo wpaść w pułapkę niezgodności ich wersji. Dla przykładu nasza aplikacja wykorzystuje biblioteki A i B. Każda z nich do pracy potrzebuje biblioteki C. Ale A używa wersji 1.2, a B 1.5. Może to doprowadzić do następującego błędu kompilacji (i to w najlepszym przypadku):

Assembly 'B, Version=1.0.0.000, Culture=neutral, PublicKeyToken=17863af14b0044da' uses 'C, Version=1.5.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' which has a higher version than referenced assembly 'C, Version=1.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'

Ostatnio sam spotkałem się z tym problemem wykorzystując w jednym projekcie możliwości AOP kontenera Autofac i NHibernate. Obydwie biblioteki były zależne od Castle.Core.dll. Zostawiając jedynie jej nowszą wersję kontener działał bez zarzutu, ale NHibernate przy próbie stworzenia proxy do encji rzucał pięknym wyjątkiem:

System.IO.FileLoadException : Could not load file or assembly 'Castle.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Najprostszym rozwiązaniem problemu okazało się zmuszenie NHibernate do wykorzystywanie nowszej wersji Castle.Core poprzez tzw Assembly Binding Redirection. Sprowadza się to do dodania paru linijek w pliku *.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Castle.Core" publicKeyToken="407DD0808D44FBDC" />
        <bindingRedirect oldVersion="0.0.0.0-1.2.0.0" newVersion="1.2.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Castle.DynamicProxy2" publicKeyToken="407DD0808D44FBDC" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Dzięki temu działa zarówno Autofac jak i NHibernate, a co najważniejsze nie trzeba nic rekompilować podmieniając zależności u źródła. Należy jednak pamiętać, że sztuczka nie zawsze musi działać. W przypadku braku zgodności między kolejnymi wersjami biblioteki mogą pojawić się inne ciekawsze błędy ;).
Warto również zauważyć, że ta metoda wykorzystywana jest w ASP MVC 2, gdzie w standardowym szablonie dla Web.config istnieje wpis:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/>
      <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
    </dependentAssembly>  
  </assemblyBinding>
</runtime>

Menu użytkownika w pliku xml cz.1 - Podstawa

Pisząc aplikację w ASP.NET MVC na pewno będziemy borykać się z problemem sposobu przechowywania głównego menu jakie powinno zostać wyświetlone użytkownikowi. Jeżeli opieramy działanie na uniwersalnym menu to oczywiście najlepiej wpisać je w master page i zapomnieć o całej sprawie. Najczęściej jednak użytkownicy mają różne prawa/role, co często ciągnie za sobą brak autoryzacji do pewnych funkcjonalności. Wylądowaliśmy zatem w sytuacji gdzie w zależności praw dostępu użytkownika powinniśmy wygenerować mu inne menu.

Możliwe rozwiązania

Do dyspozycji mamy zatem następujące możliwości zapisania menu:

• na stałe w kodzie
• w pliku
• w bazie danych

Zapis na stałe w kodzie jest oczywiście z definicji zły dla tego typu dynamicznych elementów. Kolejne dwa rozwiązania są już znacznie lepsze (choćby dlatego, że odpada potrzeba ponownej kompilacji i możemy dowolnie edytować informacje). Warto jednak zwrócić uwagę, że do obsługi menu niekoniecznie trzeba używać aż bazy danych (dużą rolę odgrywa tutaj wielkość aplikacji). Jeżeli dysponujemy stałym zestawem ról dla użytkowników można swobodnie do tego celu wykorzystać plik XML.

Docelowa struktura

Odpowiednik menu użytkownika w xml powinien zawierać elementy:

• typ/prawa/rolę użytkownika
• adres docelowy
• opis wyświetlanego linku

W związku z tym wybrałem następującą strukturę zapewniającą powyższe założenia:

<!--menu.xml-->
<?xml version="1.0" encoding="utf-8" ?>
<menus>
  <menu for="Doctor">
    <item value="Dzisiejsze wizyty" url="/Doctor/Index" />
    <item value="Ostatnia wizyta" url="/Visit/Last" />
    <item value="Wyloguj" url="/User/Logout" />
  </menu>
  <menu for="Recepcionist">
    <item value="Nowy pacjent" url="/Patient/Create" />
    <item value="Wyloguj" url="/User/Logout" />
  </menu>
</menus>

Jak widać w przykładzie mamy dwa osobne menu. Jedno dla lekarza z trzema wpisami i drugie dla recepcjonisty z dwoma. Struktura jest przy okazji na tyle prosta, że bardzo łatwo da się ją odzwierciedlić w kodzie. A jak już o tym mowa, najpierw nieco abstrakcji:

[Flags]
public enum UserRole
{
    Doctor = 1 << 0,
    Recepcionist = 1 << 1,
}

public interface IMenu
{
    IEnumerable<IMenuItem> For(UserRole role);
}

public interface IMenuItem
{
    string Value { get; }
    string Url { get; }
}

Interfejs IMenu reprezentuje już wczytane menu dając dając dostęp do listy elementów IMenuItem czyli informacji opisujących link jaki później zostanie wygenerowany. Dodajmy zatem do tego wszystkiego obsługę xml i jesteśmy w domu.

[XmlRoot("menus")]
public class XmlMenu : IMenu
{
    [XmlElement("menu")]
    public List<XmlRoleMenu> RoleMenus { get; set; }

    public XmlMenu()
    {
        RoleMenus = new List<XmlRoleMenu>();
    }

    public IEnumerable<IMenuItem> For(UserRole role)
    {
        XmlRoleMenu roleMenu = RoleMenus
            .Where(m => m.Role == role)
            .Single();
        return roleMenu.Items;
    }

    public static IMenu LoadFrom(string filePath)
    {
        XmlSerializer serializer = new XmlSerializer(typeof(XmlMenu));
        XmlMenu menu = null;
        using (StreamReader reader = new StreamReader(filePath)) {
            menu = (XmlMenu)serializer.Deserialize(reader);
            reader.Close();
        }
        return menu;
    }
}

public class XmlRoleMenu
{
    [XmlElement("item")]
    public List<XmlMenuItem> MenuItems { get; set; }

    [XmlAttribute("for")]
    public UserRole Role { get; set; }

    public XmlRoleMenu()
    {
        MenuItems = new List<XmlMenuItem>();
    }

    public IEnumerable<IMenuItem> Items
    {
        get { return MenuItems.ConvertAll(item => (IMenuItem)item); }
    }
}

public class XmlMenuItem : IMenuItem
{
    [XmlAttribute("value")]
    public string Value { get; set; }
    [XmlAttribute("url")]
    public string Url { get; set; }
}

Na zakończenie jeszcze przykład użycia wyciągający menu dla doktora

static void Main(string[] args)
{
    IMenu menu = XmlMenu.LoadFrom("menu.xml");
    foreach (IMenuItem item in menu.For(UserRole.Doctor)) {
        Console.WriteLine("{0}\t{1}", item.Url, item.Value);
    }
    Console.ReadLine();
}

Prawda, że proste? Wczytywanie pliku to jednak nie wszystko czego potrzebujemy. Takie menu należy jeszcze osadzić w widoku asp.net mvc, ale o tym już niedługo.

ConfirmSubmit - HtmlHelper Extensions cz.1

Jedną z tzw dobrych praktyk projektowania aplikacji w ASP.NET MVC jest stosowanie HtmlHelper w przypadkach bardziej skomplikowanego kody widoku. Co można w skrócie nazwać "Keep your views simple". Obiekt Html oczywiście nie realizuje każdego z możliwych scenariuszy stąd powinien być w trakcie kodowania uzupełniany o dodatkowe funkcjonalności pisząc stosowne metody rozszerzające. Stąd też pomysł na niniejszy cykl postów w którym postaram zaprezentować parę przydatnych rozwiązań.

ConfirmSubmit czyli najpierw zapytaj

Tworząc różne formy do edycji/tworzenia/usuwania obiektów wypada czasem upewnić się czy użytkownik na pewno wie co robi ;] Istnieją różne metody, ale chyba najprostsza to wyświetlenie okienka z poziomu javascript:

<input  type="submit" value="Usuń" onclick="return confirm('Czy na pewno?')" />

Zakładając, że w przeglądarce nie mamy wyłączonej obsługi js (co w dobie aplikacji internetowych i Ajaxa jest rzadkością) otrzymamy coś na kształt:

Wszystko pięknie działa, ale jest hmm, niewygodne i do tego nie zgodne z zasadą tworzenia widoków o której wcześniej wspominałem. Stąd też proste rozszerzenie ConfirmSubmit:

public static  MvcHtmlString ConfirmSubmit(
    this HtmlHelper html,
    string value,
    string question)
{
    string submit = String.Format(
        "<input type=\"submit\" value=\"{0}\" onclick=\"return confirm('{1}');\"",
        value,
        question);
    return MvcHtmlString.Create(submit);           
}

Do kompletu jeszcze wywołanie i wszyscy są szczęśliwi:

<%=Html.ConfirmSubmit("Usuń", "Czy na pewno?") %>

KeyNotFoundException w NHibernate

Podczas pisania mapowań dla NHibernate w moim projekcie, natknąłem się na dość problematyczny błąd. Na samym początku informacje zwrotne nic specjalnego nie mówiły, a przynajmniej nic co od razu nasuwało źródło problemu:

System.Collections.Generic.KeyNotFoundException: Dany klucz nie był obecny w słowniku.
...

W śladzie stosu nie było też dużo lepszych informacji o genezie błędu. Ale do tego każdy programista powinien się do pewnego stopnia przyzwyczaić ;)
Po dokładniejszej analizie okazało się, że chociaż parsowania plików mapować zakończono bezbłędnie to już zbudowanie fabryki sesji powodowało wyżej wymieniony błąd. A wszystkiemu zawinił następujący fragment:

<one-to-one name="Worker" class="Worker" cascade="all" />

Wygląda całkiem niewinnie, z tym, że mapowanie do klasy Worker znajduje się w innym assembly. I stąd cały problem. NHibernate założył istnienie mapowania, którego później nie mógł znaleźć. Rozwiązanie całej sytuacji wydaje się wręcz trywialne:

<one-to-one
    name="Worker" 
    class="Full.Namespace.To.Class.Worker,Assembly.With.Worker"
    cascade="all" />

Pozostaje jeszcze pytanie jak zapobiegać takim sytuacjom w przyszłości? Można nie zrobić nic i przeklinać własną sklerozę, albo zrezygnować z mapowań xml i przerzucić się na Fluent NHibernate gdzie o taki błąd będzie trudniej (w związku z kompilowaną charakterystyką rozwiązania).

Let's fight

Kompletnie nie wiem czemu przez tak długi czas zwlekałem z założeniem tego bloga. Może potrzebowałem poczucia większej kompetencji? Trudno powiedzieć. W każdym razie ten właśnie moment można określić jako wielkie otwarcie. Najwyższy czas zacząć dzielić się własnymi przemyśleniami i innymi bzdurami o programowaniu, .NET, inżynierii oprogramowania i wszystkim tym co sprawia, że moje życie uważam za interesujące.
I tak na dobry początek musi się tutaj znaleźć mój ulubiony i jakże trafny życiowy cytat

Experience is the name that everyone gives to his mistakes - Oscar Wild