0

在编写连接到 WCF Web 服务的 Silverlight 应用程序时，我们在使用 Web 服务时看到的唯一选项是对 WS 接口进行异步调用。

IE

WebService client = new WebService();
client.ServiceMethodCompleted += new EventHandler<Args>(client_Handler);
client.ServiceMethodAsync();
client.close()

...followed by
void client_Handler(object sender, Args e)
{
    //Next step, possibly another method?
}

虽然我理解编写 webapps（安全网）时异步调用的原因，但如果编写的方法的每个步骤都依赖于 Web 服务调用的结果，将使用哪种类型的设计模式？

例如，如果 Web 服务中有一个方法检查访问者的用户凭据，并且根据该用户的组，将执行一些操作。

public MyPage() //Constructor
{
    CheckCredentialsAsync();

    if(result.IsUserTypeA)
    {
       //something complex
    }
    else if(result.IsUserTypeB)
    {
       //something else complex
    }
    ...etc

}

有没有办法在不使用由先前异步调用完成事件触发的方法的“多米诺”设计的情况下完成此操作？如果有很多客户端/服务交互，它似乎会变得混乱。

谢谢！

4

3 回答 3

4

我所知道的此类模式的最佳建模是事件驱动的有限状态机。异步方法完成是事件，您的“复杂操作”是操作，您的 MyPage 实例是当前状态。然而，对于任何相当数量的状态和事件，FSM 都可能非常麻烦，虽然可以通过组合更简单的 FSM 以某种方式对其进行检查，但我绝不会称这种模式为直观和简单的。

坦率地说，我经常更喜欢你描述的回调链。“多米诺骨牌”效应并不一定很糟糕，一旦你编写了几个这样的模块，你就会掌握它的窍门。它的复杂性基本上是由“复杂”块中可能的执行分支的数量驱动的。在同步路径中你会有一个 if 分支，在异步路径中你可能有两个单独的回调。需要输入更多代码，但不一定更难理解。并且“更多代码”部分可以通过将 coe 适当地工厂化为助手来处理。

我认为虽然我没有使用 Silverlight 类，但我的经验主要是围绕 WebRequest、SqlClient 和 Stream 操作异步行为。最后，我发现最复杂的部分是错误处理的拆分和资源所有权的拆分，因为该using模式对异步的用处要小得多。

于 2009-10-27T00:20:05.720 回答
2

如果您不想将回调链接在一起，请查看 Jeffrey Richter 的 AsyncEnumerator： http: //www.wintellect.com/PowerThreading.aspx

它也支持 Silverlight。

于 2009-10-31T07:55:30.727 回答
0

我同意你的观点：
看着长长的多米诺骨牌链是丑陋的。它混淆了代码，因为您页面中的（无休止的）调用和回调列表不一定与其他开发人员沟通给定系列是任何单个集合的一部分。这就是为什么我会使用设计模式将这些调用包装到单个对象中。

如果您的多米诺骨牌链...

使用以前的调用数据：
我会使用DECORATOR设计模式将这些调用包装到一个对象中。使用装饰器模式的一个很好的例子是STREAM对象。

如果您的多米诺骨牌链...

不使用以前的调用数据：
我会使用CHAIN OF RESPONSIBILITY设计模式将这些调用包装到一个对象中。

但是
，您可能使用或不使用其中一种的原因有很多。我只是想迎合你的具体情况。 这是您决定使用哪一个的方法。

于 2011-02-10T13:35:15.403 回答