Popišme si případ, ve kterém přistupujeme do databáze na serveru ze Silverlight aplikace ve webovém prohlížeči. Rozeberme si, jak putují data z databáze až do grafického rozhraní. Popíšeme si, jaké rysy mají mít třídy, aby šly pomocí webové služby přenášet ze serveru na klienta. Máme data netriviální struktury v databázi a můžeme je uživateli zobrazovat několika způsoby v nejedné oblasti aplikace.
Máme data netriviální struktury v databázi a můžeme je uživateli zobrazovat několika způsoby. Třídit je, nebo přepínat mezi kategoriemi. A ještě k tomu jsou data celkem veliká. Protože je u nás 3G pokrytí mizerné, rozhodneme se implementovat na straně klienta proxi.
Databáze poskytuje svá data pomocí uložených procedur. Uložené procedury krásně obalí strukturu databáze rozhraním. Aplikace, která přistupuje k databázi jen přes uložené procedury, tedy nemusí vědět nic o struktuře tabulek. Změny v databázové struktuře se tím pádem obejdou bez úprav aplikace, která databázi využívá (nevyžadují-li úpravy i změny v rozhraní, i tak ale budou změny menší).
Pomocí LINQ se tyto procedury volají z jazyka C# pohodlně a jednoduše. Získaná data se jen přebalí do transportních tříd a nabídnou jako webová služba (v našem případě Silverlight-enabled WCF Service). Proč přebalovat do transportních tříd? Inu, webovými službami neprotlačíme jen tak nějakou třídu. Ty potlačitelné (čti serializovatelné) se označují jako transportní a jsou celkem specifické. Tak jako je funkce webové služby označena atributem OperationContract, musí být transportní třída označena atributem DataContract. Jednotlivé vlastnosti třídy musí mít atribut DataMember a musí mít veřejný jak getter tak i setter. U typu Enum musí mít jednotlivé výčty atribut EnumMember. A konečně transportní třída musí mít veřejný konstruktor bez parametrů. Tyto transportní třídy je dobré mít v samostatném projektu Silverlight Class Library, na kterou má referenci jak Silverlight projekt, tak i projekt webové služby poskytující.
Není nutné dělit Silverlight aplikaci mezi více projektů, je ale dobrý nápad si oddělit vlastní aplikaci Client od datových struktur Client.Data. Client obsahuje vrstvu View, Client.Data pak vrstvy ViewModel a Model. Pojďme se na jednotlivé vrstvy podívat.
Binding propojuje data ovládacího prvku ve View s daty v ObservableCollection<T>ve ViewModelu. Umožňuje automatickou změnu obsahu ovládacího prvku při změně obsahu této datové struktury. Funguje to oběma směry, takže pokud uživatel změní obsah ovládacího prvku, projeví se to i v datové struktuře. Nově přidané či odebrané prvky jsou rychle k nalezení v obsluze události, kterou tato změna vyvolá. Je samozřejmě možné využívat i jiné datové struktury s vlastními ovládacími prvky. Při používání tříd pro binding se v XAML kódu jen jednoduše deklaruje, která vlastnost třídy se má do obsahu ovládacího prvku vkládat. Je tedy možné velice pohodlně čerpat z více ovládacích prvků různé vlastnosti ViewModelu.
Nyní si rozeberme, kde jdou dělat řezy aplikací využívající MVVM. Důležitý řez je mezi Modelem a ViewModelem. Ke grafickému rozhraní můžeme připojit libovolný (testovací) Model (vytvoříme třídu ViewModel s jinou instancí třídy Model), který může obsahovat například testovací data uložená v XML podobně na místním úložišti. Stejně tak můžeme vytvořit testovací grafické rozhraní využívající stejnou třídu Model. Mezi XAML a logickým kódem je přirozené oddělení, aby bylo možné vyvíjet grafické rozhraní nezávisle na logickém kódu aplikace.