多个客户端的流畅WCF(代码中)配置/托管?

时间:2009-11-18 15:23:18

标签: .net wcf

不在代码中配置WCF需要与模型和服务库进行更多耦合吗?

如果我正确理解它,您可以在与使用的服务相同的项目中的代码中配置主机。然后在客户端上配置通道,但客户端必须知道模型,这意味着如果我有几个客户端应用程序使用该服务,他们都必须引用模型(或任何你正在使用的)程序集。

所以我认为代码配置/主机不是涉及多个客户端时的最佳选择吗?

1 个答案:

答案 0 :(得分:1)

您可以从代码配置WCF,而无需创建比使用配置文件更多的耦合。

我喜欢使用以下分区:

服务器:

  • 您的数据合同的一个程序集(models / DTO)。
  • 服务合同的一个程序集(您的WCF接口)。
  • 一个用于服务实施的程序集。
  • 一个用于服务主机创建逻辑的程序集。该程序集将包含一个类(WCFHostsLoader),用于实例化所有端点的服务主机。
  • 连接WCF主机的一个程序。在ASP.Net下可能是Globas.asax。在Globas.asax中,您将调用WCFHostsLoader.Configure()。

客户端:

客户是一个完全独立的问题。您暗示客户端必须与服务器共享相同的程序集(模型)。虽然这是可能的(这是我们在项目中所做的);这不是强制性的。

选项1是共享相同的模型装配和服务合同装配。就我而言,如果客户端应用程序是用.Net编写的(并且由您或您可以提供两个所需程序集的一方编写),这是最好的方法。主要的优点是在客户端上,你不会在丑陋的生成类上结束。我也认为这种方法更优雅。去看看GoF Proxy pattern。在纯代理模式中,不会将参数(模型)代理到代理服务。

选项2是使用从服务器的WSDL生成的一组代理类。我认为更常见,因为a)Visual Studio的添加服务参考使这很容易。 b)如果客户不是.Net,那么这是唯一的选择。如果您使用Visual Studio的添加服务引用生成的类,您可能很难尝试控制通道工厂创建过程来配置代码而不是配置文件中的所有内容(我从未尝试过这样做)。可能存在其他工具来生成更符合代码配置的代理类。

我希望这会有所帮助