最近研究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中也沒有新的更新，不知道微軟是否已經放棄了這一框架。