有多少业务逻辑属于RIA服务层？
我最近一直在尝试使用 .NET 4.0 的 Silverlight、RIA 服务和实体框架。我试图弄清楚该堆栈是否适合我即将进行的任何项目。当然，这些技术对于开发应用程序来说似乎非常高效，但我正在努力决定如何构建该堆栈之上的应用程序。
我遇到的主要问题是，在大多数演示中，我看到大部分业务逻辑最终都作为 RIA Services 域服务类中的 DataAnnotations 和自定义验证而结束。这对我来说似乎不合适。我认为域服务基本上是一种美化的 Web 服务，它恰好可以轻松地将信息推送到客户端。但我所看到的大多数内容似乎都将领域服务定位为应用程序中业务逻辑的主要来源。
所以，我的问题是：
- 使用此堆栈的应用程序中业务逻辑（规则、验证、行为、授权）的最佳位置是什么？
- 是否有在架构级别发布的使用此堆栈的指南？
我的问题涉及大型、复杂且长期存在的应用程序。显然，对于只有几个屏幕的应用程序来说，这不是一个问题。
编辑： 我想提到的另一件事是，显然您可以使域服务类变得愚蠢，但随后您会丢失许多被推送到客户端的自动实体信息（例如验证）。如果您失去了这一点，那么使用 RIA 服务还有什么意义呢？
I have been experimenting recently with Silverlight, RIA Services, and Entity Framework using .NET 4.0. I'm trying to figure out if that stack makes sense for use in any of my upcoming projects. It certainly seems like these technologies can be very productive for developing applications, but I'm struggling to decide how an application on top of this stack should be architected.
The main issue I have is that in most of the demos I've seen most of the business logic ends up as DataAnnotations and custom validations in the RIA Services domain service class. This seems inappropriate to me. I view the domain service as basically a glorified web service that happens to make it easy to push information to the client. But most of what I've seen seems to orient the domain service as the main source of business logic in the application.
So, my questions:
- What is the best location for business logic (rules, validations, behaviors, authorization) in an application using this stack?
- Are there any guidelines published at an architectural level for using this stack?
My questions pertain to large, complex, and long-lived applications. Obviously for an application of only a few screens this is less of a concern.
Edit:
Another thing I meant to mention is that obviously you can make the domain service class stupid, but then you lose a lot of the automagic entity information (e.g. validations) being pushed to the client. And then if you lose that is there any point to using RIA services?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们的团队正在 RIA 堆栈之上实现 Silverlight 应用程序。我们决定在 RIA 实体之上构建一个域模型。此外，我们选择遵循 MVVM 模式来建模 UI 交互。
到目前为止，我已经注意到以下好处：
另一件需要注意的事情是，我们已经实现了自己的并发身份映射，并将脏跟踪推到了 RIA 上下文。
在实践中，这种架构需要更多的编码工作，但在可读性和可维护性方面获得了巨大的回报。即使对于简单的 CRUD 应用程序，我也会遵循这种做法。能够构建更准确地表示问题空间的领域模型是一个引人注目的优势。
Our team is in the process of implementing a Silverlight app on top of the RIA stack. We've decided to build a domain model on top of the RIA entities. Additionally, we elected to follow the MVVM pattern to model UI interactions.
So far, I've noticed the following benefits:
Another thing to note is we've implemented our own identity map for concurrency and pushed off dirty tracking to the RIA context.
In practice, this architecture requires a bit more coding effort, but pays off big time with readability and maintainability. Even for simple CRUD applications, I'd follow this practice. Having the ability to build a domain model that more accurately represents the problem space is a compelling advantage.
一般来说，使用技术比反对技术更有效率。
正如您所说，业务逻辑最终出现在 DataAnnotations 和自定义验证中，对于系统的第一个版本，这可能是开发人员生产力方面的“最佳”位置。
我有一种感觉，这项技术在快速构建 CRUD 应用程序时具有其优势，当您具有复杂的业务逻辑时，您最终可能会在 silverlight 应用程序和 RIA 服务之间增加一个额外的业务层。
还没有尝试在这方面构建任何真实的东西，只有在使用它一段时间后我们才会真正知道答案。
In general it is more productive to work with the technology than against it.
As you say the business logic ends up in DataAnnotations and custom validations, this may be the "best" place for it with respect to developer productivity, for the first version of the system.
I have a feeling that this technology has it's strength when rapidly building crud applications, when you have complicated business logic you may end up with an extra business layer in between the silverlight application and the RIA services.
Have not tried to build anything real in this yet, we will only really know the answer to this after we have used it for some time.