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

Question

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

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

我很想从有经验的 Silverlight/RIA 开发人员那里得到一些关于这些问题的评论，也许还有一些我忽略的评论。我喜欢这个概念，但我担心那些比我更纯粹的代码主义者会拒绝这种方法。

Answer 1

我认为 RIA 服务鼓励了很好的模式(也许除了 DomainDataSource，许多人将使用它来将数据访问逻辑放在 View 中，但我知道 RIA 服务人员一直在寻找使 DDS 对 MVVM 更友好的方法)。从架构的角度来看，这是我喜欢它的一些具体点:

验证逻辑可以声明一次，但同时应用于客户端(良好的 UX)和服务器端(服务的非 SL 客户端的安全性和一致性)。

查询是跨层执行的，因此您可以考虑在客户端上想要/需要什么，制定查询，并知道它将一直翻译到您的数据库而不会过度获取。您可以完成所有这些操作，而无需考虑优化 SQL 查询等，但会获得很多难以实现的好处。

通过使所有内容都可绑定(bind)，使用 MVVM 使您的 View 保持简单和愚蠢变得更加容易。数据绑定(bind)是您的好 friend ，RIA 服务让实现 INotifyPropertyChanged 变得不那么烦人/乏味。一遍又一遍，加上它添加了许多其他更难实现的接口(interface)，如 INotifyDataErrorInfo (我认为)和 IEditableObject等等，许多 Silverlight 控件都尊重开箱即用的“做正确的事”。

我想我不理解您所说的服务加倍为 DAL 的意思 - DAL 是您的 LINQ-To-SQL 或 LINQ-To-Entities(或您喜欢的任何 DAL、NHibernate 等)的模型。 RIA 服务更像是位于 DAL 之上的业务逻辑层，并以一种使业务逻辑在消费者之间保持一致的方式公开数据。在 Silverlight 的情况下，它还添加了客户端代码生成来进行客户端验证等，但这只是 Silverlight 的增值。

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