RIA服务层有多少业务逻辑？

Question

我最近使用.NET 4.0对Silverlight，RIA Services和Entity Framework进行了实验。我正在试图弄清楚这个堆栈是否适用于我即将开展的任何项目。看起来这些技术似乎可以非常高效地开发应用程序，但我很难决定应该如何构建这个堆栈顶部的应用程序。

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

所以，我的问题：

• 使用此堆栈的应用程序中业务逻辑（规则，验证，行为，授权）的最佳位置是什么？
• 是否在架构级别发布了使用此堆栈的指南？

我的问题涉及大型，复杂和长期存在的应用程序。显然，对于只有几个屏幕的应用，这不是一个问题。

修改 我要提到的另一件事是，很明显你可以使域服务类变得愚蠢，但是你会丢失很多被推送到客户端的自动实体信息（例如验证）。如果你输了，那么使用RIA服务有什么意义吗？

Answer 1

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

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

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

另外需要注意的是，我们已经实现了自己的并发身份映射，并将脏跟踪推送到RIA上下文。

在实践中，这种架构需要更多的编码工作，但在可读性和可维护性方面可以节省大量时间。即使对于简单的CRUD应用程序，我也会遵循这种做法。能够构建更准确地表示问题空间的域模型是一个引人注目的优势。

Answer 2

一般来说，使用该技术比使用该技术更有效率。

正如您所说，业务逻辑最终出现在DataAnnotations和自定义验证中，对于系统的第一个版本而言，这可能是开发人员工作效率的“最佳”位置。

我觉得这种技术在快速构建crud应用程序时具有强大的优势，当您拥有复杂的业务逻辑时，最终可能会在Silverlight应用程序和RIA服务之间建立额外的业务层。

还没有尝试构建任何真实的东西，我们只会在使用它一段时间后才真正知道答案。