Continuing in our discussion of Silverlight 3 and the update to .NET RIA Services. I have been updating the example from my Mix09 talk “building business applications with Silverlight 3”. RIA Services is very much an extension of the LINQ project. Effectively you can think of RIA Services as n-tier LINQ. As such, I thought it would be interesting to show how any of the tons of Linq Providers can be used with RIA Services.
You can watch the original video of the full session
The demo requires (all 100% free and always free):
Also, download the full demo files and check out the running application.
Here is the general application pattern we are looking at this time:
Way back in Part 8: WCF I showed off how to get your data from a WCF services (rather than Entity Framework) via RIA Services. One part I was never quite happy with is that I needed to pass the page number into the Query method. While David Poll and I developed a neat little paging pattern that worked with this, it certainly felt like a hack.. and Jason Allor, our development manager totally agreed. The core problem is I didn’t have a IQueryable that knew about my WCF services to return. Jason assured me this would be easy to do based on the LINQ to TerraServer Provider Sampleand Matt Warren’s excellent set of posts. So I dared him to try it and he did!
What Jason ended up with is pretty cool. It does not cover 100% of the cases that RIA Services might use, but it does cover a lot or them and all the source is here, so feel free to use and extend.
In my original WCF example, my query method looked like:
public IQueryable<SuperEmployee> GetSuperEmployees(int pageNumber)
{return this.Context.GetSuperEmployees(pageNumber)
.Where(emp => emp.Issues > 100)
.OrderBy(emp => emp.EmployeeID)
.Select(emp =>
new MyApp.Web.SuperEmployee() {EmployeeID = emp.EmployeeID,
Gender = emp.Gender,
Issues = emp.Issues,
LastEdit = emp.LastEdit,
Name = emp.Name,
Origin = emp.Origin,
Publishers = emp.Publishers,
Sites = emp.Sites,
}).AsQueryable();
}
Notice that page number should really be handled by skip() and take() in the query rather than an explicit parameter that doesn’t compose well.
And with Jason’s cool new IQueryable to WCF implementation it is much clearner:
public IQueryable<SuperEmployee> GetSuperEmployees(){return new LinqToSuperEmployeeService(this.context)
.Where(emp => emp.Issues > 100);
}
Basically the LinqToSuperEmployeeService parses the Linq query and gives us access to the individual parts of the query.
internal class LinqToSuperEmployeeService : QueryableService<SuperEmployee>
{ private SuperEmployeeServiceClient context; public LinqToSuperEmployeeService(SuperEmployeeServiceClient context) { this.context = context;}
protected override object ExecuteQuery(QueryDetails details)
{ if (details.Count) {return this.context.GetSuperEmployeesCount(
details.SkipSize,
details.PageSize,
details.OrderBy,
details.Filters.ToArray());
}
else {return this.context.GetSuperEmployees(
details.SkipSize,
details.PageSize,
details.OrderBy,
details.Filters.ToArray())
.Select(emp => ConvertUtils.Convert(emp));
}
}
}
For example, consider a query such as:
q.Skip(20).Take(10)
.OrderBy(e => e.Name)
.Where(e => e.Origin == 'Earth');
We’d end up calling the GetSuperEmployees(20,10,null,{“Earth”});
The base QueryableService will parse out the the SkipSize, PageSize and orderby information an puts it in the QueryDetails class. And then in the this overload of the Execute method we pluck those out and pass them on to the WCF service. You could just as easily pluck those values out and call a REST based service or generate some TSQL, etc.
If you wanted to reuse this functionality for your WCF service, you just derive your own subclass of QueryableService and do the right thing with the values.
One more cool thing, if you create your own subclass of of DomainService that can handle calling a particular WCF service things get even easier.
[EnableClientAccess()]
public class SuperEmployeeDomainService : LinqToSuperEmployeeDomainService
{ public IQueryable<SuperEmployee> GetSuperEmployees() {return this.Context;
}
And the code for your custom DomainService? Pretty easy as well.
public class LinqToSuperEmployeeDomainService : DomainService
{private SuperEmployeeServiceClient webServiceContext = new SuperEmployeeServiceClient();
private LinqToSuperEmployeeService linqContext; protected LinqToSuperEmployeeDomainService() {this.linqContext = new LinqToSuperEmployeeService(this.webServiceContext);
}
public IQueryable<SuperEmployee> Context { get { return this.linqContext; }}
public SuperEmployeeServiceClient WebServiceContext { get { return this.webServiceContext; }}
}
This part talked about how to use a custom Linq provider to make it very easy to call a WCF service to get data into your Silverlight client. The very simple Linq provider I show here can be easily customized to work with any service or other data source.
Tidak ada komentar:
Posting Komentar