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

Question

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

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

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

Answer 1

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

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

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

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