多少业务逻辑属于 RIA 服务层？答案

【问题标题】：How much business logic belongs in RIA services layer?多少业务逻辑属于 RIA 服务层？
【发布时间】：2010-05-24 14:00:07
【问题描述】：

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

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

所以，我的问题：

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

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

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

【问题讨论】：

我也想知道同样的事情！真的很难让我了解 RIA 服务的最佳实践。貌似没有太多详细的业务应用示例。
我还在为自己解决这个问题。一个想法是，即使使 DomainService 尽可能愚蠢，您仍然可以获得易于使用的 DomainContext 来将更改（批量）提交到服务器并在客户端进行更改跟踪。这个 IMO 仍然使 RIA 服务非常有价值。
好点digiduck。这当然是值得的。

标签： .net silverlight entity-framework architecture wcf-ria-services

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

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

正如您所说，业务逻辑最终会出现在 DataAnnotations 和自定义验证中，对于系统的第一个版本，这可能是开发人员生产力方面的“最佳”位置。

我感觉这项技术在快速构建 crud 应用程序时有它的优势，当您有复杂的业务逻辑时，您最终可能会在 silverlight 应用程序和 RIA 服务之间增加一个额外的业务层。

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

【讨论】：