Warstwa prezentacji odpowiedzialna jest za komunikację z użytkownikiem. W dzisiejszych czasach interfejsy graficzne są na tyle rozbudowane, że poprawne zaprojektowanie warstwy prezentacji stanowi poważne wyzwanie. W małych projektach często ta warstwa stanowi najbardziej złożoną część całej architektury.
Bez wykorzystania stosownych wzorców projektowych po pewnym czasie pisania aplikacji okaże się, że jakakolwiek zmiana interfejsu wiąże się ze skomplikowaną refaktoryzacją kodu.
Jedną z podstawowych cech poprawnie zaprojektowanej warstwy prezentacji jest niezależność od sposobu wyświetlania. Doskonałym przykładem jest np. blog WordPress. Za pomocą kilku kliknięć można zmienić wygląd (skórkę) strony. Sposób wyświetlania jest wyraźnie oddzielony od logiki oraz akcji użytkownika. Innymi słowy interfejs graficzny powinien pozostać nieświadomy danych, które wyświetla. Drugim przykładem obok blog’a jest wyświetlanie danych (np. zamówień) w ASP .NET – programista może użyć zarówno kontrolki DataGrid jak Repeater. Podsumowując warstwa prezentacji musi być odporna na zmianę widoku – model musi pozostać niezależny (np. powinno wykorzystywać sie IEnumarable<Order> zamiast specyficznej kolekcji dla danego API graficznego).
Często podawaną ważną cechą warstwy prezentacji jest niezależność od technologii interfejsu graficznego (WPF, Silverlight itp.). W praktyce jednak nie zawsze spełniana jest ta zasada. W idealnym świecie architektura tej warstwy powinna pozwalać na swobodną zmianę technologii UI. W rzeczywistości zaprojektowanie tak elastycznej warstwy jest bardzo trudnym i czasochłonnym zadaniem i często rezygnuje się z tego. Oczywiście wykorzystując np. Model-View-ViewModel znacznie łatwiej będzie przejść w przyszłości na inną technologie niż wykorzystując klasyczny autonomiczny widok.
Ważnym elementem wyróżniającym dobrze zaprojektowaną warstwę jest wsparcie dla testów (np. jednostkowych). W widoku autonomicznym zautomatyzowane testy są praktycznie niemożliwe – sprowadzałyby się do symulowania kliknięć użytkownika. Potrzebujemy API, które pozwoli nam symulować konkretną akcję użytkownika z poziomu kodu – np. kliknięcie w dany przycisk. Kluczem do tego jest stworzenie abstrakcji między widokiem a logiką prezentacji – konkretnie interfejsu zawierającego metody typu “SelectOrder”, “ShowDetails” itp.
Dobrą cechą jest również całkowita niezależność od warstwy biznesowej. Uzyskuje się to poprzez wprowadzenie wspomnianych już w poprzednich postach obiektów DTO. W praktyce jednak tworzenie DTO jest bardzo czasochłonne i nie zawsze opłacalne.
W przyszłych postach przedstawię kilka podstawowych wzorców projektowych – Model-View-Controller, Model-View-Presenter, Model-View-ViewModel oraz Model2. Planuje również opisanie dwóch frameworków wspomagających wykorzystanie tych wzorców zarówno w aplikacjach web (oczywiście będzie to ASP .NET MVC) jak i desktop.