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

我一直在使用Silverlight，RIA服务，并使用.NET 4.0框架的实体试验最近。我试图弄清楚这个堆栈是否适用于我即将发布的任何项目。这当然好像这些技术可以用于开发应用程序非常有成效的，但我挣扎，决定如何在这个堆栈的顶部的应用程序应该被构建。多少业务逻辑在RIA服务层属于？

主要的问题我已经是，在大多数我见过的大部分业务逻辑的结束作为RIA服务域服务类DataAnnotations和定制验证演示的。这对我来说似乎不合适。我查看域服务为根本，恰好可以很容易地将信息推送给客户一个华而不实的Web服务。但是我所看到的大部分内容似乎都将域服务定位为应用程序中业务逻辑的主要来源。

所以，我的问题：

什么是业务逻辑（规则，验证，行为，授权）在使用这个堆栈的应用程序的最佳位置？
在架构级别上是否有使用此堆栈的准则？

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

编辑： 我的意思是说另一件事是，很明显，你可以让域服务类愚蠢的，但你失去了很多的AUTOMAGIC实体信息（例如验证）推到了客户端。那么如果你输了，那有什么意义可以使用RIA服务？

来源

2010-05-24 RationalGeek

我想知道同样的事情！真正努力争取让我的头脑围绕RIA服务的最佳实践。似乎没有太多详细的业务应用示例。 – Banford 2010-05-24 14:02:36

我还在为自己弄清楚这一点。一个想法，即使使DomainService尽可能愚蠢，你仍然可以很容易地使用DomainContext将更改（批量）提交给服务器，并更改客户端的跟踪。这个国际海事组织，仍然使RIA服务非常有价值。 – joshuapoehls 2010-05-24 20:33:37

好点digiduck。这当然是值得的。 – RationalGeek 2010-05-25 02:11:23

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

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

域类是一个很好的地方，把业务逻辑包括复杂的验证。
域类使用RIA实体和上下文作为数据存储的接口。
域类是根据业务关注建模的，不需要与RIA实体建立一对一的关系。
简单的用户界面验证可以住在的ViewModels。

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

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

来源

2010-05-26 01:42:58 randolphcabral

总的来说，使用该技术比使用该技术更有效率。

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

我有一种感觉，这种技术在快速构建粗糙应用程序时具有优势，当您有复杂的业务逻辑时，最终可能会在Silverlight应用程序和RIA服务之间形成额外的业务层。

还没有尝试过在此建立任何真实的东西，但是我们在使用它之后才会真正知道这个答案。

来源

2010-05-25 20:06:08

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

回答

相关问题