The Problem WCF RIA Services Was Built to Solve
Before RIA Services, building a data-driven Silverlight application meant writing a WCF service on the server that exposed CRUD operations, hand-crafting data transfer objects to cross the wire, writing a client-side proxy to call the service, and then duplicating validation logic in both places because client-side validation attributes on the server's Entity Framework model were never visible to the Silverlight project. WCF RIA Services closes that gap by generating client-side counterparts of your server entities and their DataAnnotations validation attributes automatically at build time, so a single [Required] or [StringLength] attribute written once on the server model shows up as live client-side validation without being retyped.
Cricket analogy: It's like a franchise having to maintain two completely separate copies of the player roster, one for the ground staff and one for the broadcast graphics team, manually updating both whenever a player is added, versus a single master roster that automatically syncs to both.
DomainService and DomainContext
On the server, you author a class that derives from DomainService, exposing query methods that return IQueryable<T> results, such as GetActiveCustomers(), along with Insert, Update, and Delete methods that RIA Services associates with your entity type by naming convention or explicit attributes. When you build the solution, the tooling generates a client-side DomainContext subclass in the Silverlight project's Generated_Code folder, exposing a strongly-typed EntityQuery for each server query method and a Load method that executes it asynchronously, giving you compile-time checked access to server operations without writing a single line of proxy code by hand.
Cricket analogy: It's like a franchise's head office publishing an official rulebook of approved player transactions, and every regional office automatically receives an identical, pre-typed transaction form derived directly from that rulebook rather than drafting its own.
Querying, Editing, and Submitting Change Sets
On the client, you load data by calling context.Load(context.GetActiveCustomersQuery()), which returns a LoadOperation whose Completed event exposes the results as an EntityList already bound to your grid; editing a returned entity's properties automatically marks it as modified inside an internal EntityChangeSet tracked by the DomainContext. Calling context.SubmitChanges() bundles every added, modified, and deleted entity from that change set into a single round trip to the server, where the DomainService's Insert, Update, and Delete methods are invoked per entity, and any validation failures or concurrency conflicts come back attached to the specific entities that failed rather than aborting the whole batch indiscriminately.
Cricket analogy: It's like a captain submitting a single team-sheet change request covering three substitutions at once to the match referee, rather than filing three separate paperwork trips, with the referee flagging only the specific substitution that violates a rule.
Shared Validation Between Client and Server
Because the generated client entity classes carry the same System.ComponentModel.DataAnnotations attributes as the server metadata classes, binding a TextBox to a required property and triggering validation, either through Silverlight's built-in binding validation or by calling entity.ValidationErrors after a manual check, reproduces the exact same rules the server would enforce on SubmitChanges, catching mistakes before a round trip is even attempted. This does not eliminate server-side validation, since a malicious or out-of-date client could bypass client checks entirely, so RIA Services always re-validates on the server during SubmitChanges and returns any failures through the SubmitOperation's EntitiesInError collection regardless of what the client already checked.
Cricket analogy: It's like both the third umpire and the on-field umpire independently applying the exact same no-ball rule from the same rulebook; the bowler gets caught by the same standard whether the check happens at the crease or upstairs in the review room.
// Server: DomainService exposing query and CRUD operations
public class CustomerDomainService : LinqToEntitiesDomainService<StoreContext>
{
public IQueryable<Customer> GetActiveCustomers()
{
return this.ObjectContext.Customers.Where(c => c.IsActive);
}
public void UpdateCustomer(Customer customer)
{
this.ObjectContext.Customers.AttachAsModified(customer);
}
}
// Server: shared metadata attaches validation attributes
[MetadataType(typeof(CustomerMetadata))]
public partial class Customer
{
private sealed class CustomerMetadata
{
[Required]
[StringLength(100)]
public string Name { get; set; }
[Range(0, 150)]
public int CreditLimit { get; set; }
}
}
// Client: generated DomainContext usage
var context = new StoreDomainContext();
context.Load(context.GetActiveCustomersQuery(), loadOp =>
{
CustomerGrid.ItemsSource = loadOp.Entities;
}, null);
// later, after edits made in the bound grid
context.SubmitChanges(submitOp =>
{
if (submitOp.HasError)
{
foreach (var entity in submitOp.EntitiesInError)
StatusText.Text += entity.ValidationErrors.First().ErrorMessage;
submitOp.MarkErrorAsHandled();
}
}, null);The generated client entities live in the Silverlight project's Generated_Code folder and are regenerated on every build, so never hand-edit them directly; extend behavior instead through partial classes in your own code files, which RIA Services merges with the generated partial class at compile time.
- WCF RIA Services generates client-side entity classes and a DomainContext from a server-side DomainService, eliminating hand-written proxies and DTOs.
- DataAnnotations validation attributes defined once on the server automatically appear as client-side validation.
- context.Load executes a generated EntityQuery asynchronously and returns bound-ready results.
- context.SubmitChanges bundles all pending inserts, updates, and deletes into a single round trip.
- Server-side validation always re-runs during SubmitChanges regardless of client-side checks, since clients cannot be trusted.
- Generated code lives in Generated_Code and is overwritten on every build; extend it via partial classes instead.
Practice what you learned
1. What server-side base class do you derive from to expose data operations to a Silverlight RIA Services client?
2. Where do DataAnnotations validation attributes need to be defined to appear automatically on the Silverlight client?
3. What does context.SubmitChanges() do?
4. Why does RIA Services still re-validate on the server even if the client already validated the data?
5. Where does RIA Services put the generated client-side entity and context code, and what is the rule about editing it?
Was this page helpful?
You May Also Like
Consuming WCF Services in Silverlight
How Silverlight applications call WCF services through generated asynchronous proxies, and the sandbox and binding constraints that shape every call.
Silverlight Networking
The networking stack Silverlight exposes for HTTP and socket communication, and the security boundaries that govern which requests are allowed to leave the plug-in.
Silverlight MVVM
How the Model-View-ViewModel pattern organizes Silverlight applications around data binding, keeping views declarative and logic unit-testable outside of code-behind.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics