我对Silverlight很新.我花了一天时间看着RIA服务.这个概念看起来非常好,是一种节省大量时间编写面向数据的Silverlight应用程序的方法.然而,在我花费的时间里,我感觉很多人可能觉得这种方法过于“快速和肮脏”,并且至少会违反几种最佳做法.

例如,默认情况下,后端服务层兼作数据访问层.并且数据库实体和UI之间似乎存在紧密耦合.

我非常有兴趣从经验丰富的Silverlight / RIA开发人员那里得到一些关于这些问题的评论,也许还有其他我忽视的问题.我喜欢这个概念,但我担心的是那些代码纯粹比我更纯粹的人会对这种方法犹豫不决.

最佳答案 我认为RIA Services鼓励很好的模式(除了DomainDataSource,很多人会用它来将数据访问逻辑放在视图中,但我知道RIA服务人员一直在寻找使DDS更加适合MVVM的方法).从架构的角度来看,我喜欢这里的一些具体要点：

>验证逻辑可以声明一次,但应用于客户端(很好的UX)和服务器端(服务的非SL客户端的安全性和一致性).
>查询是跨层执行的,因此您可以在客户端上考虑您想要/需要的内容,制定查询,并知道它将一直转换到您的数据库而不会过度获取.您可以完成所有这些操作,而无需考虑优化SQL查询等,但可以获得许多难以实现的好处.
>通过使所有内容都可绑定,使用MVVM来保持视图简单和愚蠢变得更加容易.数据绑定是你的朋友,而RIA Services一遍又一遍地实现INotifyPropertyChanged并不那么烦人/乏味,而且它还增加了许多其他难以实现的接口,如INotifyDataErrorInfo(我认为)和IEditableObject等等,许多Silverlight控制开箱即用“做正确的事”.

我想我不遵循你所说的服务加倍作为DAL的意思 – DAL是来自LINQ-To-SQL或LINQ-To-Entities(或者你喜欢的任何DAL,NHibernate等等)的模型. RIA服务更像是位于DAL之上的业务逻辑层,并以保持业务逻辑在消费者之间保持一致的方式公开数据.对于Silverlight,它还添加了客户端codegen以进行客户端验证等,但这只是Silverlight的增值.

业务实体和UI之间可能存在紧密耦合,但这可以通过任何技术完成.无论技术如何,您都必须考虑公开正确的数据,然后在其上构建UI.