相关疑难解决方法(0)

(Mis)使用C#迭代器实现协同程序的缺陷

我正在编写重构Silverlight程序,以从WCF服务中消耗其现有业务逻辑的一部分.在这样做时,我遇到了Silverlight 3中的限制,它只允许对WCF服务的异步调用,以避免长时间运行或无响应的服务调用阻塞UI线程(SL有一个有趣的排队模型来调用WCF服务)在UI线程上).

因此,编写曾经很简单的东西变得越来越复杂(请参阅我的问题末尾的代码示例).

理想情况下,我会使用协同程序来简化实现,但遗憾的是,C#目前不支持协同程序作为本机语言工具.但是,C#确实具有使用yield return语法的生成器(迭代器)的概念.我的想法是重新使用yield关键字,以允许我为相同的逻辑构建一个简单的协同模型.

但是,我不愿意这样做,因为我担心可能存在一些我没有预料到的隐藏(技术)陷阱(考虑到我对Silverlight和WCF的相对缺乏经验).我也担心未来的开发人员可能不清楚实现机制,并且可能会阻碍而不是简化他们将来维护或扩展代码的努力.我已经在SO上看到了关于重构迭代器以构建状态机的问题:使用"yield"关键字实现状态机,虽然它与我正在做的事情不完全相同,但它确实让我停下来.

但是,我需要做一些事情来隐藏服务调用的复杂性,并管理此类更改中的缺陷的工作量和潜在风险.我对可以用来解决这个问题的其他想法或方法持开放态度.

原始的非WCF版本的代码看起来像这样:

void Button_Clicked( object sender, EventArgs e ) {
   using( var bizLogic = new BusinessLogicLayer() ) {
       try  {
           var resultFoo = bizLogic.Foo();
           // ... do something with resultFoo and the UI
           var resultBar = bizLogic.Bar(resultFoo);
           // ... do something with resultBar and the UI
           var resultBaz = bizLogic.Baz(resultBar);
           // ... do something with resultFoo, resultBar, resultBaz
       }
   }
}

Run Code Online (Sandbox Code Playgroud)

重新考虑的WCF版本变得更加复杂(即使没有异常处理和前/后条件测试):