RIA服务层中应该包含多少业务逻辑？

Question

我最近一直在尝试使用.NET 4.0中的Silverlight、RIA服务和实体框架进行实验。我正在努力弄清楚这个技术栈是否适用于我的即将到来的项目。这些技术似乎非常适合开发应用程序，但我很难决定如何构建这个技术栈上的应用程序。

我主要的问题是，在我看过的大多数演示中，大部分业务逻辑最终都成为了RIA服务域服务类中的DataAnnotations和自定义验证。我认为这是不合适的。我认为域服务基本上是一个被美化的Web服务，可以轻松地将信息推送到客户端。但是，我看到的大部分内容似乎将域服务定位为应用程序中主要的业务逻辑来源。

所以，我的问题是：

• 在使用这个技术栈的应用程序中，业务逻辑（规则、验证、行为、授权）的最佳位置是什么？
• 有没有在架构层面上使用这个技术栈的指南？

我的问题涉及到大型、复杂和长寿命的应用程序。显然，对于只有几个屏幕的应用程序，这不是太大的问题。 编辑： 我还想提到的另一件事是，显然你可以让域服务类变得愚蠢，但是这样你就失去了很多自动推送到客户端的实体信息（例如验证）。那么如果你失去了这个功能，使用RIA服务还有什么意义呢？

- RationalGeek

---

我也想知道同样的事情！真的很难理解RIA服务的最佳实践。好像没有太多详细的业务应用示例。 - Banford

我自己也还在摸索中。不过有一个想法，即使将DomainService尽可能地变得愚笨，您仍然可以获得易于使用的DomainContext，以便将更改（批量）提交到服务器并在客户端跟踪更改。在我看来，这仍然使RIA Services非常有价值。 - joshuapoehls

好的观点，digiduck。这确实值得一些东西。 - RationalGeek

Answer 1

我们的团队正在实现一个基于RIA堆栈的Silverlight应用程序。我们决定在RIA实体之上构建域模型。此外，我们选择遵循MVVM模式来建模UI交互。

到目前为止，我注意到以下好处：

1. 域类是放置业务逻辑（包括复杂验证）的好地方。
2. 域类使用RIA实体和上下文作为数据存储的接口。
3. 域类按照业务关注点进行建模，不需要与RIA实体一一对应。
4. 简单的UI验证可以存在于ViewModels中。

另一个要注意的事情是，我们实现了自己的标识映射以进行并发，并将脏跟踪推迟到RIA上下文。

在实践中，这种架构需要更多的编码工作，但通过可读性和可维护性大大得到回报。即使对于简单的CRUD应用程序，我也会遵循这种做法。能够构建更准确地表示问题空间的域模型是一个令人信服的优势。

- randolphcabral

Answer 2

一般来说，与技术合作比对抗更具生产力。

正如你所说的，业务逻辑最终会出现在DataAnnotations和自定义验证中，对于系统的第一个版本来说，这可能是“最佳”位置，从开发人员的角度来看。

我有一种感觉，当快速构建crud应用程序时，这项技术的优势就显现出来了，当你有复杂的业务逻辑时，你可能会在Silverlight应用程序和RIA服务之间添加额外的业务层。

尚未尝试在此上构建任何真实的东西，只有在使用一段时间后，我们才能真正知道答案。

- Shiraz Bhaiji