.net - 多少业务逻辑属于 RIA 服务层？

Question

我最近一直在试验使用 .NET 4.0 的 Silverlight、RIA 服务和 Entity Framework 。我试图弄清楚该堆栈是否适用于我即将进行的任何项目。似乎这些技术对于开发应用程序非常有效，但我正在努力决定如何构建这个堆栈之上的应用程序。

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

所以，我的问题:

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

是否在架构级别发布了使用此堆栈的任何指南？

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

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

Answer 1

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

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

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

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

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

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

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

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