.net - RIA服务层中包含多少业务逻辑？

最近，我一直在使用.NET 4.0对Silverlight，RIA Services和Entity Framework进行试验。我试图弄清楚该堆栈是否适合在我即将进行的任何项目中使用。显然，这些技术对于开发应用程序来说可能非常有生产力，但是我正在努力决定应如何构建此堆栈顶部的应用程序。

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

所以，我的问题是:

使用此堆栈的应用程序中业务逻辑(规则，验证，行为，授权)的最佳位置是什么？

是否在体系结构级别上发布了有关使用此堆栈的指南？

我的问题与大型，复杂且生命周期长的应用程序有关。显然，对于只有几个屏幕的应用程序，这并不是什么大问题。

编辑:
我要提到的另一件事是，显然您可以使域服务类变得愚蠢，但是随后，您将丢失大量推送到客户端的自动实体信息(例如，验证)。然后，如果您丢失了，那么使用RIA服务有什么意义吗？

最佳答案

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

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

域类是放置包含复杂验证的业务逻辑的好地方。

域类使用RIA实体和上下文作为数据存储的接口(interface)。

域类是根据业务考虑建模的，不需要与RIA实体一对一的关系。

简单的UI验证可以存在于ViewModels中。

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

实际上，这种架构需要更多的编码工作，但是在可读性和可维护性方面却付出了很多时间。即使对于简单的CRUD应用程序，我也会遵循这种做法。具有构建更准确地表示问题空间的域模型的能力是一个引人注目的优势。