In this lab, you will modify the example application to customize data and behavior based on the logged in user, using the Model-View-ViewModel pattern. You will also implement server-side access control, and explore how WCF RIA Services data annotations work with data forms to provide end to end validation in Silverlight applications.
You can start from where you left off with the previous lab, if you completed it. But if you did not get to the end, or if it you would just prefer to work from a fresh starting point, make a copy of the solution in the StartingPoint folder for this lab—it contains the completed solution from the previous lab.
In the lab for the previous module, your Silverlight application used a simple approach that works for very basic applications, but which can run into problems as your program grows. You were binding controls directly to data sources that came back from WCF RIA Services, and putting all the code into the code behind for your XAML pages. This is problematic for a number of reasons. Embedding application behavior into the code behind makes that behavior hard to test in isolation. You cannot write unit tests for that code without somehow loading the XAML. Binding directly to objects returned by a service raises problems when your application needs to show state that doesn’t correspond directly to properties those objects already have. You certainly wouldn’t want to go adding new items to the object model returned by a domain service simply to support user interface status such as knowing whether the user has dismissed a notification in the UI yet, but it’s entirely reasonable (a good idea in fact) to use data binding to work with that sort of state.
Non-trivial Silverlight applications typically add an extra layer between the XAML and the underlying data model to provide flexibility and testability. You will use this approach in this part of the lab. You will customize the user interface based on whether the user is logged in, and if so, which role their account belongs to.
Obviously, concepts such as account and role are as much server-side concerns as client-side ones, so these ideas belong in the world of the domain model. In fact the Silverlight Business Application template adds some services to support these features to any new application. The logic for deciding which specific UI elements should be available to which users is clearly specific to the client-side code, and that’s the logic that will go into the extra layer. We call this layer the ViewModel, because it sits between the View (the XAML with its codebehind) and the Model (the client-side wrappers generated by WCF RIA Services for our domain service, in this case).