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