最近研究Ria Services，之前抱有较高期望，现在比较失望。Ria Services似乎只是为发布Demo而提供的一套帮助快速开发的库，而不是一套完整的企业级的框架。它能很好的解决一些简单的增删改的问题，能应付小数据量下的Change Tracking，还提供了一套看似很丰富完备的Validation机制，那些教程、演示中都竭力展现了它快捷方便的一面，却有意无意的掩盖了其过于死板导致的各种缺点：
提交修改不接受参数
Ria Services里的所有增删改操作，最终都通过SubmitChange方法提交，但这么重要的方法却不支持参数传递。举一个例子：如果业务场景需要切换数据库，而服务端在接收提交请求时由于没有别的参数，并不清楚当前操作的是哪一个数据库，这就会造成麻烦。一种解决办法就是在实体里增加标识所属数据库的属性，但这无疑是麻烦而冗余的，因为这要求每一种实体都要附加这样的属性。
不支持多对多
Entity Framework都支持多对多了，但Ria Services却不支持多对多，依然要靠操作关系实体来操作多对多。
服务端对实体的属性修改，客户端无法知悉
由于客户端的缓存层，保证了Ria Services在客户端的Change Tracking，但这样的缓存层却经常导致服务端和客户端的数据不一致。提交修改后，如果实体有属性在服务端进行了修改，客户端无法从回调中知悉，唯一的解决办法就是每次提交后重新Load Query。
不支持部分提交
在一次修改提交中，如果有部分提交失败产生了Validation Error，那么返回到客户端时，你会发现ChangeSet里面还保有所有的ChangeSet，即使是那些提交成功，在服务端已经处理过的实体，在客户端的状态依然是Modified或Added或者Removed。在这种情况下，如果你再次提交，会重新提交之前已经提交成功的实体。而解决这种问题的方法，是把那些没有ValidationErrors的实体，从Domain Context中Detach掉再Attach上。这种解决方案无疑是比较别扭的。
当改变一个实体在服务端引发另一个实体的改变时，客户端无法知悉也无法报错
由于ChangeSet在服务端是不可改变的状态，一旦在服务端发生了实体间的连带改变，服务端无法反馈给客户端。那么解决方法就是把所有的连带修改都在客户端完成，而这在大数据量的情况下，显然是不适合的（需要先把所有需要修改的数据提取到客户端，再在客户端中完成所有修改的逻辑）。
不支持自定义类型的实体属性和参数
如果说自定义类型的实体属性还可有可无，因为毕竟实体属性往往和数据表的字段绑定，基本类型属性应该够用，那么无论在Query还是Invoke方法中都不支持自定义类型参数，无疑是大大制约了查询的灵活性。
暴露的WCF服务无法直接提供给其他客户端使用
由于Ria Services底层使用的是WCF服务，所以我们有理由期望这些WCF服务可以被其他非Silverlight客户端使用，但事实是，通过Fiddler监控到的Ria Service请求与普通的WCF服务并不相同，由于Ria Service在创建时在客户端和服务端都增加了一层（Domain Service和Domain Context），所以如果要使用不能生成Domain Context层的客户端中连通Ria Services生成的WCF Service时，会需要自己重新构建一套类似Domain Context的框架。
总结
综上所述，Ria Services在目前的状态下，并不适合企业级的复杂应用，在大数据量下不堪重用。而不乐观的是，由于Ria Services和Silverlight紧密绑定，随着Silverlight前途堪忧，Ria Services进一步更新的可能也越来越少，事实上，从Silverlight 4中的Ria Services SP2之后，整个框架处于停滞状态，在Silverlight 5中也没有新的更新，不知道微软是否已经放弃了这一框架。