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 验证可以存在于 ViewModel 中。

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

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