andyfrench.info

This post is mainly concerned with the basics of WCF RIA Services and is intended to serve as a aide memoire for terms etc. It will be added to over time.
Some definitions:

• Project Link
  • The server project references the domain services, shared code etc. defined on the server side.
  • Code is generated in the client project at compile time linking the client and the server.
• Entities
  • Defined on the server and generated client-side.
  • Validation etc. also generated on the client side (i.e. you just maintain the single server-side definition).
  • Used to marshal the data across the WCF service.
  • Can be created with Entity Framework, LINQ to SQL, or POCOs.
• Domain Service
  • Defines the operations supported on the server side (e.g. CRUD operations).
  • Can be arbitrary operations to be invoked on the server from the client exposed by WCF.
• Domain Context
  • The client side counterpart to the Domain Service.
  • Generated code on the client side.
  • Contains a WCF proxy that makes the service calls.
  • Manages creating the queries to be executed on the server side, entity change tracking etc.
• Domain Data Source
  • Used to execute queries and submit changes to the server side.
  • Associated with the domain context.
  • Makes calls through the domain context to query and update entities.
  • Facilitates direct data binding from XAML.

Entities or entity collections retrieved are cached through the domain context on the client side. Changes (i.e. the addition, deletion or update of entities) are effectively ‘stored’ in the Domain Context until the changes are flushed through to the database. In other words, the Domain Context must be kept around long enough to submit the changes.
The Domain Context Load and SubmitChanges execute asynchronously. They take a thread from the thread pool, make the necessary calls to the server, and when those calls complete the work is automatically marshalled back to the UI thread to modify the entity collections and subsequently update the UI (probably via INotificationChanged).
However, it would be prudent to assume at least the possibility of problems. A couple of strategies that can be employed to get around this are:

• Subscribe to the Completed event obtained from the LoadOperation or SubmitOperation obtained from Load or SubmitChanges.
• Call an overload of the Load or SubmitChanges that takes an Action<LoadOperation> or Action<SubmitOperation> (i.e. supply call-backs).

Attributes

When creating the Domain Service (server side) adding the EnableClientAccess attribute will cause client side code to be generated at compile time.
Operations in the Domain Service can be decorated with attributes to identify their purpose (e.g.  create, read, update or delete and entity instance).
Authentication and authorisation can be enforced using attributes (the attributes can be specified at the service or operation level):

• RequiresAuthentication - prevents anonymous users from accessing a service to perform an operation.
• RequiresRole - ensures that the current principal belongs to one of the specified roles.

Convention over configuration

By default WCF RIA Services uses convention over configuration to find appropriate operations defined in the Domain Service.  There are a set of named method prefixes WCF RIA Services is looking for (e.g. Update***, Insert***, Delete***).
As an alternative attributes can be used to decorate methods and indicate what they are to be used for (i.e. configuration).

Authentication and authorisation

On the client authentication functionality is accessed through a class called WebContext, a class that represents functionality provided by the web server.
Authentication services implement the IAuthentication interface. An implementation of an authentication service will use a DomainContext to work against the corresponding DomainService implementing IAuthentication on the server.
There are 2 approaches to implementing authentiaction:

1. Derive from the out-of-box AuthenticationService base class. This provides a default implementation that leverages the asp.net membership, roles and profile infrastructure.
2. Implement IAuthentication on your domain service and do whatever you like based on your unique scenarios when implementing Login, Logout and other methods of the interface. This is especially useful if you're not using the asp.net infrastructure services or want to use some custom auth mechanism.

See http://www.nikhilk.net/Entry.aspx?id=262 and http://www.nikhilk.net/RIAServices-Authorization.aspx.
Authorisation can be further controlled using attributes (see above).