RIA Services: Jumpstarting RIA Development

Business Application Template

This template has come to have a life of its own. Folks love it. Sometimes I wonder if we'll see a bunch of RIA Services applications that all look like the business application template (we need to get an updated set of themes/variations on the look/feel of the app). However, it does reflect how it is a useful starting point.

The template results in a solution with two projects that together represent your end-to-end application - an ASP.NET Web application representing the server half, and a Silverlight application representing the client. The two projects are linked. The client project logically depends on the server project, so services in the server can automatically be consumed without additional explicit references, and the client project is set to be deployed back into the server project.

DataModel

OK, so this isn't part of RIA Services specifically, but it is certainly a key part of the application development flow. RIA Services allows you to use your choice of data access technology, and you get to use both the runtime APIs, and its design experiences.

New DomainService

The role of a DomainService class is to encapsulate your data access logic, and any application-specific logic. It is typically a stateless service with a set of CRUD methods. DomainService represents the starting point for RIA Services specific functionality.

The wizard allows you to get started with a basic DomainService with a ready-to-use initial implementation of CRUD methods that operate on the data model and entities you select to expose to the client.

Client-side Programming Model and Intellisense

The RIA Services infrastructure automatically produces a strongly-typed, data-centric proxy in the form of a DomainContext for each DomainService exposed by the server half of the application. You don't have to explicitly add references, or perform an explicit build. It just works, just as you'd expect things to work within a single project... the only difference is that this time its within a single application across couple projects in the solution.

Data Sources Window

The Data Sources window understands the RIA Services programming model, and surfaces the generated DomainContext and Entity types, so you can easily drag them onto the design surface to create data source controls, and data-bound lists and details user interfaces, that support browsing data, sorting and paging through it, editing it (with validation), and exploring master/details relationships.

All of these design-time features complement RIA Services to simplify application development to allow you to quickly get started and create a breadth-first version of your application's functionality. Usually this isn't the end, so RIA Services lets you go much further depending on your scenarios, and requirements. Here are a few things that might interest you.

• Structured Queries and Operations: instead of having default CRUD methods, you might choose to create one or more structured query methods, custom update methods etc. to closely match the semantics of your particular application domain.
• Validation, Authorization and Business rules: More than likely you'll have a few interesting rules to enforce. You can define them using metadata that you attach to your models and your methods. This metadata can be specified using CLR attributes, or read-in from external storage such as a database or rules engine. Either way, RIA Services takes care of propagating your intent down to the client when possible.
• Presentation model: instead of having your data model entities show up directly on the client, you might choose to create a set of presentation-tier types (or DTOs) that you use to define the contract between the presentation logic on the client and the application logic on the server.
• Structuring your solution: You might be interested in splitting your models and DomainServices into multiple class libraries. You can create a Silverlight class library for each server class library and then use your n-tier components as a pair within one or more n-tier apps.
• Creating view models: The client-side programming model of RIA Services lends itself well to the view model pattern, which allows you to factor out your data access logic, and view-independent logic out of your views.

If you've been using RIA Services, hopefully you'll see the new tooling features as rounding out the story. If you're new to the technology, hopefully this shows how RIA Services can take care of lots of plumbing and infrastructure, and allow you to focus on creating your rich internet application simply and effectively.