Web Services是经实践考验证明的跨防火墙的通信方式,它很稳定且被广泛认可。总的来说你需要为分散的CRUD操作指定相应的接口并在Silverlight中忠实的调用他们
- 使用的原因:需要进行类似直接通过服务进行数据库交互操作的项目(弱化业务逻辑部分)。
- 避免使用的原因:必须始终自己监视数据的变化并调用相应的服务方法进行更新,任何需要并发的操作或事务变得较为沉重且需要处理大量的代码。
ADO.NET Data Services
ADO.NET Data Services是一套简单的基于Rest的数据通信方式。它依赖于Http定义服务接口,如Get操作定义为读写、Post操作定义为更新等。它使用ATOM或JSON作为序列化格式,所以可以被各种类型的客户端调用。
他通过将基于URI的API转换为LINQ调用从而提供插入、更新、删除等操作。这意味着ADO.NET本身是很单薄的一层,它的目的是将URI模型翻译为数据通信代码。
对于Silverlight来说,ADO.NET Data Services真正的亮点在于其提供的客户端类库。这个客户端类库允许开发者在客户端使用LINQ查询并在服务端执行。当然它支持的LINQ语法相比服务端有一些局限,大概覆盖80%的场景,当然ADO.NET Data Service也允许开发者在必要时自定义剩余的操作以适应其他场景。另外,客户端类库提供一个强大的Data上下文类用以监视和处理有事务支持的批量操作。
使用ADO.NET Data Services公开数据通信实际上是宫公开查询终结点的方式替代定义接口,这就是它最特别的地方。比如,我们可以像这样使用LINQ查:
- 使用的原因:想要一个简单、安全的模型使得开发人员可以在代码中定义他们需要的查询(相对于基于接口的WCF Service)。得益于LINQ调用及上下文类,使用ADO.NET Data Services客户端类库会让你的客户端代码量适当减少。
- 避免使用的原因:当你想要严格控制数据访问接口及不想让可发者直接在客户端使用LINQ查询的情况下应该避免使用ADO.NET Data Services。
WCF RIA Services
由于RIA Services基于服务端查询接口定义,在客户端开发人员可以像这样调用其接口定义的查询:
在介绍ADO.NET Data Services时曾提到开发人员可以使用LINQ查询,RIA Services同样允许向查询终结点添加LINQ 约束。例如你可以这样对终结点添加LINQ表达式:
var riaQry = ctx.GetGamesQuery() .Where(g => g.Price < 50m) .OrderBy(g => g.Name); LoadOperation < Game > op = ctx.Load < Game > (riaQry);
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。