【问题标题】:Are auto-generated proxies the best approach for implementing an asynchronous WCF client?自动生成的代理是实现异步 WCF 客户端的最佳方法吗?
【发布时间】:2010-10-10 19:43:12
【问题描述】:

我正在为 C#/.NET 3.5 项目设计架构,该项目将通过 WCF 在客户端和服务器之间进行通信。这通常是一个查询-响应系统,例如,其中一种服务方法可能如下所示:

User GetUserByLastName(string lastName);

另外一项规定是,WCF 客户端方法需要异步调用,以免对 UI 的响应产生不利影响,因为在某些情况下,这些方法可能需要很长时间才能执行。

我已经根据 Microsoft 的文档实现了一个概念证明,因此客户端代理是使用 Visual Studio 中的“添加服务引用”对话框自动生成的,并且我选中了包含异步方法的选项。

这可以很好地作为概念证明,但我遇到了许多博客文章和其他参考资料,强烈建议不要在大型​​项目中使用自动生成的代理。其中一些来源提供了涉及手动创建代理或使用反射动态创建代理的替代方案,但这些解决方案似乎总是只实现同步 WCF 调用。

为异步 WCF 客户端自动生成的代理涉及相当多的样板代码,我不想为每个服务和方法手动实现和维护这些代码。

所以我的问题是:

为异步 WCF 服务使用自动生成的代理是不是一个坏主意,如果是这样,是否有不涉及大量手动维护样板代码的好选择?

【问题讨论】:

    标签: c# .net wcf


    【解决方案1】:

    这很糟糕,有几个原因,我相信您已经阅读了这些博客文章中的所有内容。对我来说,主要缺点是:

    1) 频道创建一团糟、丑陋且效率低下

    2) 无法缓存 ChannelFactory

    3) 不适用于 DI

    4) 如果您重用客户端,通道可能会出现故障,您必须围绕它编写代码

    5)这是代码生成,如果您的代码发生更改,则必须重新生成。

    6) 老实说,它并没有节省很多代码。如果您使用 web.config/app.config 来设置端点,则使用服务的接口创建通道工厂(并对其进行缓存)然后创建代理只需几行代码。

    【讨论】:

    • 关于您的第 6 点,我还没有看到一个示例说明如何为不涉及大量代码的异步操作执行此操作,而这些操作仅用于实现单个服务方法所需的基础架构。有什么建议或参考吗?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-04-28
    • 1970-01-01
    • 1970-01-01
    • 2012-01-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多