如何架构业务层或wcf ria服务
我们正在从头开始构建一个新系统，并决定使用 SL4、WCF RIA 服务和 EF4。
因此，我将 WCF RIA 服务视为 SL 客户端的业务逻辑，但它是否可以用作通用业务逻辑层，可供应用程序的其他部分使用。例如，WCF RIA 服务将实现安全性（例如允许谁对哪些对象执行哪些操作）。但这种安全性还应该由系统的其他部分实现，而不仅仅是 SL 客户端。
为了避免重复此逻辑，我的想法是使用 WCF RIA 服务作为通用业务层，这意味着如果系统的其他部分需要访问数据层，它们将需要通过该层。
但这是 WCF RIA 的正确用法吗？
谢谢
We are building a new system from scratch and have decided on SL4, WCF RIA Services and EF4.
So I see the WCF RIA services as the business logic of the SL client, but can it be used as a general business logic layer, that can be used by other parts of the application. As an example the WCF RIA service will have security implemented (such as who is allowed to do what with which objects). But this security implementation should also be by other parts of the system and not only by the SL client.
To avoid having this logic duplicated my idea is to use the WCF RIA service as a general business layer meaning that if other parts of the system needs access to the datalayer they would need to go through this layer.
But is this an ok usage of WCF RIA?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您所描述的是标准 WCF RIA 模式，也是 WCF RIA 团队设计系统的工作方式。
WCF RIA 将允许您获得对 EF4 实体的端到端访问，并将您的业务逻辑隐藏在 RIA 服务接口后面。您可以在类级别（服务契约中的所有方法）或方法级别将身份验证和授权属性应用于服务定义（域服务类）中的实体，以实现更精细的控制。
我在你的计划中看到的唯一主要缺陷是“系统的其他部分需要访问数据层，他们需要通过这一层”。现阶段的 WCF RIA 只能与 Silverlight 配合使用（也许还有 ASP.NET MVC？我不确定）。 Microsoft 最终打算扩展 RIA 服务以供任何类型的 .NET 应用程序使用，但在现阶段它实际上仅适用于 Silverlight。这意味着您将错过其他非 Silverlight 应用程序的许多 WCF RIA 好处。不过，我相信您仍然可以将 WCF RIA 服务公开为普通的 WCF 服务，包括身份验证/授权层。您将错过自动代理、代码生成等功能。
但是，仍然有多种方法可以从 Silverlight 外部使用此服务层。您可以使用 OData 端点或 SOAP/REST 服务公开 EF4 实体。有关此内容的更多详细信息，请查看 这篇文章。
What you're describing is the standard WCF RIA pattern and is how the WCF RIA team designed the system to work.
WCF RIA will allow you to get end-to-end access to your EF4 entities and hide your business logic behind the RIA service interface. You can apply authentication and authorization attributes to your entities in the service definition (domain service class) at either the class level (all methods in the service contract) or the method level for more granular control.
The only major flaw I see in your plan is "other parts of the system needs access to the datalayer they would need to go through this layer". WCF RIA at this stage only plays well with Silverlight (and maybe ASP.NET MVC? I am not sure). Microsoft eventually intends to extend RIA Services to be consumed by any kind of .NET application but at this stage it's really a Silverlight-only thing. This means that you'll miss out on a lot of the WCF RIA goodies with your other non-Silverlight applications. However I believe you can still expose the WCF RIA service as an ordinary WCF service, including the authentication/authorization layer. You'll just miss out on the automatic proxies, code generation, etc.
There are still several ways of using this service layer from outside of Silverlight however. You can expose your EF4 entities with an OData endpoint or SOAP/REST service. For more details on this, check out this article.
在大型 RIA 项目中，我们通常有很多模块（业务模块、许可、授权、审计模块等），显然有一些模块需要跨其他模块访问，还有一些模块需要跨 SL 客户端访问。因此，我相信您关心的是典型的架构方面，即如何使其在大型应用程序中正确分布。与任何 .NET 项目一样，您可以将其模块化为不同的库项目。这意味着您可以适当地将一些作为 RIA 服务类库项目或典型的可重用.net库（例如，日志库）
In the big RIA project we usually have so many modules ( Business modules, licensing, authorization, Audit modules etc.) and obviously there are some modules that need to be accessed across other modules and also some across the SL client. So I believe your concern is a typical architecture side on how you make this properly distribute in a big application. As in any .NET project, you can modularize it in to different library projects. That means you can appropriately make some as RIA Service Class Library project or else typical reusable .net libraries ( for example, Logging library)