WCF/WPF 最佳实践 - WCF ChannelFactory 和 PRISM
我是 PRISM 框架的新手，所以我的问题可能有点偏离主题。
我建立了一个由两个项目组成的 WCF 服务。
- WCF .svc 和 Web.config 项目仅包含服务定义。
- 定义WCF服务接口和服务类型的服务类型项目。
在客户端，我有点担心应该如何实现服务的单一、长期代理。
我的方法是使用 ChannelFactory 创建服务通道，并将其注册到我的模块内的 Unity 容器。这意味着我的模块必须引用服务类型项目才能获取服务接口（这是正确的方法吗？）。
问题是“当我们需要提供身份验证来创建通道以及如何处理断开连接/重新连接时，管理此通道的最佳方法是什么。”
I'm new to the PRISM framework so my question may be a bit off topic.
I've established a WCF service composed of two projects.
- The WCF .svc and Web.config project just contains the service definitions.
- The service type project that defines the WCF service interface and the service type.
In the client side, I am a little apprehensive as to how I should implement a single, long-lived proxy to the service.
My approach is to create a channel to the service using the ChannelFactory<T> and registering this to the Unity container within my module. This means that my Module must reference the Service Type project to get the service interface (is this the right way?).
The question is "what is the best way to manage this channel when we need to provide authentication to create a channel and how to handle disconnections/re-connections."
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，代理不应该是单例（或基于统一的单例），而应该根据需求创建。这样每个逻辑模块都可以随意创建它，同时不会干扰其他模块。
除此之外，你的方法非常正确。代理应该引用 ServiceType 项目等。
如果您想实现身份验证“服务”，那么我将创建另一个名为 AuthenticationService 的类，并将其在 Unity 中注册为单例。反过来，这将获得对新代理的引用，并处理与身份验证/授权相关的所有内容。
这个想法是让每个逻辑模块的行为就好像它是应用程序中唯一的东西一样，而不需要担心除其依赖项之外的其他模块。因此，如果您有两个视图，每个视图都可以获得自己的 IAuthenticationService，这将是相同的（并且它们不应该关心它），而 AuthenticationService 本身依赖于代理，并且它将保存对它的引用贯穿其一生。
The proxy should not be IMO a singleton (or unity-based-singleton) but instead should be created by demand. that way each logical module can create it at will, while not interfering with other modules.
other than that you're approach is very much correct. the proxy should have a reference to the ServiceType project, etc.
if you want to implement an authentication "service", then I would create another Class called AuthenticationService, and register that in Unity as a singleton. This, in turn, would get a reference to a new proxy, and would deal with everything related to authentication/authorazation.
The idea is to let each logic module behave as if it's the only thing in the application, without needing to worry about the other modules other than its dependecies. so this way if you have two Views, each could obtain their own IAuthenticationService, which would be the same (and they shouldn't care about it), while the AuthenticationService itself is dependant on the proxy, and it would hold a reference to it through-out its life.