WCF RIA SERVICES V1 - słów kilka …

Chciałbym napisać dziś słów kilka o WCF RIA Services. Dokładnego przeglądu standardowych scenariuszy wersji pierwszej finalnej dokonałem niejako publikując zaktualizowane przykłady w dwóch częściach (patrz cz.I i cz.II). I chociaż jest tam wiele fajnych funkcjonalności, to dziś napiszę o trochę mniej standardowych, rzadziej spotykanych rzeczach. 

Mam tu na myśli takie zagadnienia jak korzystanie z NHibernate, MVVM (jest to typowe podejście dla Silverlight, ale nie zawsze przykłady czy prezentacje wykorzystują ten wzorzec, choć ostatnio jakby częściej), lookupy, szablony T4, fluent metadata czy synchronizacja off-line. Na te tematy też można sporo powiedzieć, co udowodniłem w moim ostatnio napisanym poście o WCF RIA Services, gdzie je dokładnie przedstawiam. Teraz natomiast zasygnalizuję dwie rzeczy z tego posta, które mogą okazać się hitami, jeśli trafią do następnej wersji WCF RIA Services. Zresztą każda z wyżej wymienionych rzeczy byłaby hitem, ale te wybrałem …

No właśnie, a co może trafić do WCF RIA Services V2?  Team założył forum, na którym rozpisane są propozycje funkcjonalności. Można na nie głosować, tak więc zachęcam do głosowania, bo inaczej ktoś wybierze za nas i znów będzie ktoś narzekać -:)

Rzecz pierwsza – lookupy. Kto dysponuje uniwersalnym komponentem ładującym asynchronicznie dane dla lookupa dla dowolnego DomainContext-u, z obsługą kaskad (co przekłada się na ładowanie z parametrami w zależności od innych lookupów)  i powiązań między encjami (wartości nie-encyjnych oczywiście też)?

Każdy kto skorzysta z ComboboxDataSource, rozszerzenia dla lookupów opublikowane przez team WCF RIA Services! Co ciekawe jest to bardzo proste w użyciu, można wręcz całość zapisać w kilku linijkach XAML-a, nie kodu! 

A gdzie view modele, dobre praktyki zakrzykną zwolennicy takich? A nie ma tutaj takich, ale czy przeszkadza się nam to cieszyć prostotą użycia powszechnie implementowanej funkcjonalności???  Zresztą niekoniecznie tak być musi, Jeff Handley opisał jak używać w view modelach kontrolkę DomainDataSource (jedynie AutoLoad i Element Binding nie działają) i trwają nad tym jakieś prace, więc pewnie podobnie będzie można powiedzieć o ComboBoxDataSource.

Rzecz druga – fluent metadata. A co to takiego? Ale najpierw, trochę wstępu …

Standardowo jak definiujemy metadane dla encji (walidacja, wygląd, itd.) w WCF RIA Services wyraża się je w większości w postaci standardowych atrybutów .NET i Silverlight. Następnie na ich podstawie są generowane atrybuty w encjach po stronie klienta (najczęściej 1:1, ale nie zawsze). Mamy też możliwość definiowania własnych reguł walidacji dzięki atrybutowi CustomValidation, któremu podaje się nazwę naszej klasy i metodę. Jeśli kod tej klasy współdzielimy pomiędzy warstwami, to atrybut ten wygeneruje się też po stronie klienta.

Dodatkowo w WCF RIA Services jest możliwość definiowania metadanych także w oddzielnych klasach (tzw. buddy classes). Jest to rozwiązanie przypadku, gdy kod encji po stronie serwera jest generowany. Aby developer nie tracił swoich metadanych pisze partial class i wiąże ją z buddy class. Wynika to z ułomności C# – póki co nie mamy innego sposobu na wyrażenie metadanych do składowych zdefiniowanych w drugiej połówce. Jest to sposób definiowania danych współdzielony z ASP.NET Dynamic Data i ASP.NET MVC.

Metadane w WCF RIA Services zostały pomyślane tak, aby także można było dostarczać je z dowolnego źródła przez własne providery danych (dodajemy własny atrybut nad domain servicem wskazując mu skąd ma czerpać metadane).

Atrybuty w encjach czy w powiązanych z nimi klasami buddy nie muszą się wszystkim podobać (już słyszę te narzekania). Buddy classes trudniej refaktoryzować, wiązanie po nazwach ma swoje wady… Ale okazuje się, że możemy sprowadzić lubiane przez niektórych reguły pisane imperatywnie w postaci wyrażeń LINQ (mają wyrażenia lambda, dobrze się je refaktoryzuje) do postaci atrybutowej przyjmowanej przez WCF RIA Services. To właśnie jest fluent metadata! I to w taki sposób że ten, kto pisze reguły nie musi wiedzieć, że to się w rzeczywistości mapuje na dodawanie atrybutów. Dokonał tego Nikhil Kothari i to już stosunkowo dawno, ale ta implementacja przy pewnych stosunkowo niewielkich zmianach działa także z finalną pierwszą wersją.

Do usłyszenia!