如何重新创建存储在演示器/控制器中的有故障的 WCF 代理?

发布于 2024-09-13 19:23:31 字数 1123 浏览 5 评论 0原文

关于涉及模型-视图-演示者、IOC 和 WCF 的模式的问题(尽管我想这同样适用于 MVC):

使用 MVP(监督控制器)模式加 IOC 进行大规模 Windows 窗体实现,演示者在其中获取依赖项注射。一种常见的依赖类型是 WCF 客户端代理,由 DI 容器使用 ChannelFactory 创建,并在屏幕打开然后释放时作为成员变量存储在演示器中。

public class SubmissionsListPresenter: IPresenter
{
     private ISubmissionsListView view;
     private ISubmissionService submissionService; // WCF Client Proxy

     public SubmissionsListPresenter(ISubmissionsListView view, 
                                     ISubmissionService submissionService) 
     {
        this.view = view;
        this.submissionService = submissionService;
     }

该设计非常适合典型使用,但存在未处理异常的缺陷,这些异常会流向应用程序级别的 ThreadException 处理程序。此时,Presenter 对代理的引用将处于错误状态,并且在该视图打开时对该服务的任何其他调用都将失败。

鉴于 WCF 最佳实践是不要让客户端代理保持开放时间超过必要的时间,那么在演示者/控制器中保留对它们的引用是一个坏主意吗?

我最初认为我可能能够在代理自己的Faulted事件或ThreadException中捕获较高级别的异常,但两者都无法重新创建/重新分配代理本身。故障事件可以 Abort() 代理,但仅此而已(因为发送者似乎是按值传递?)。

我讨厌在对这些服务的每次调用周围放置 CommunicationException catch 块(有很多!),但如果做不到这一点,我需要某种方法来重新创建代理,而不用异常处理来破坏演示者代码。

或者,我可以延迟请求服务引用,直到它被使用,然后将其丢弃,但这消除了 IOC 概念,这似乎很遗憾。

其他 MVP/MVC 架构如何处理 WCF 代理?

Question regarding patterns involving Model-View-Presenter, IOC and WCF (although I imagine the same would apply to MVC):

Working on a large-scale Windows Forms implementation using a MVP (Supervising Controller) pattern plus IOC, where Presenters get their dependencies injected. One common type of dependency is a WCF Client Proxy, created by the DI container using ChannelFactory, and stored as a member variable in the presenter while a screen is open and then released.

public class SubmissionsListPresenter: IPresenter
{
     private ISubmissionsListView view;
     private ISubmissionService submissionService; // WCF Client Proxy

     public SubmissionsListPresenter(ISubmissionsListView view, 
                                     ISubmissionService submissionService) 
     {
        this.view = view;
        this.submissionService = submissionService;
     }

The design is working great for typical use, but has a flaw with unhandled exceptions, which flow through to an app level ThreadException handler. At this point the Presenter's reference to the proxy is left in a faulted state, and any other calls to that service while that view is open will fail.

Given WCF best practice is not to keep client proxies open longer than necessary, is it a bad idea to ever keep references to them within a presenter/controller?

I initially thought I might be able to trap the exception at a high level, either in the proxy's own Faulted event or ThreadException, but neither has the ability to recreate/reassign the proxy itself. The Faulted event can Abort() the proxy, but no more than that (as sender seems to be a Pass-By-Value?).

I'm loathed to put CommunicationException catch blocks around every single call to these services (there are many!), but failing that I need some way to recreate the proxy without littering the presenter code with exception handling.

Alternatively I could delay asking for the service reference until it gets used and throw it away after, but that removes the IOC concept, which seems a shame.

How do other MVP/MVC architectures deal with the WCF proxies?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文