Silverlight 4 - RIA服务 - 这是一个很好的编码实践吗？

Question

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

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

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

Answer 1

我认为RIA Services鼓励出色的模式（除了DomainDataSource之外，很多人会用它来将数据访问逻辑放在视图中，但我知道RIA服务人员一直在寻找使DDS更适合MVVM的方法） 。从架构的角度来看，我喜欢这里的一些具体要点：

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

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

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