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?