如何在没有svcutil.exe的情况下使用WCF服务?
我发现了两种无需 svcutil.exe
帮助即可使用 WCF 服务的方法:
ClientBase
ChannelFactory
我知道ClientBase
可能使用ChannelFactory
。但我说的是在写作之间进行选择:
public sealed class ServiceClient
: ClientBase<IService>, IService
{
ReturnType IService.MethodName(ParameterType parameterName)
{
return Channel.MethodName(parameterName);
}
}
// later
IService client = new ServiceClient();
var result = client.MethodName(parameterName);
或者
ChannelFactory<IMyService> channelFactory = new ChannelFactory<IMyService>();
channelFactory.Open();
var channel = channelFactory.CreateChannel();
var result = channel .MethodName(parameterName);
channelFactory.Close();
我应该选择哪一个?
I have found 2 ways of consuming a WCF service without the help from svcutil.exe
:
ClientBase<IService>
ChannelFactory<IService>
I know that ClientBase
probably uses ChannelFactory
. But I'm talking about choosing between writing:
public sealed class ServiceClient
: ClientBase<IService>, IService
{
ReturnType IService.MethodName(ParameterType parameterName)
{
return Channel.MethodName(parameterName);
}
}
// later
IService client = new ServiceClient();
var result = client.MethodName(parameterName);
or
ChannelFactory<IMyService> channelFactory = new ChannelFactory<IMyService>();
channelFactory.Open();
var channel = channelFactory.CreateChannel();
var result = channel .MethodName(parameterName);
channelFactory.Close();
Which one should I choose?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您的选择标准是什么?
从功能上来说,最终,这两种方法都工作得很好,并且基本上给出了相同的结果。
您想根据什么做出决定?
我的建议:选择你觉得更舒服的风格!使用
ChannelFactory
的方法可能需要您编写越来越少的普通代码 - 所以这对于该方法来说可能是一个小小的优势。这两种方法都要求通道两端都有 .NET,并且服务和客户端与其中的服务和操作契约共享一个公共程序集 - 因为客户端必须至少知道服务接口才能使用连接到服务的两种方式之一。
What are your criteria for choosing?
Functionally, in the end, both approaches work just fine and basically give you the same result.
What do you want to base your decision on?
My advice: pick the style that you feel more comfortable with! The approach with the
ChannelFactory<IService>
probably requires you to write less and less mundane code - so maybe that would be a little advantage for that approach.Both approaches require that you have .NET on both ends of the channel, and that service and client share a common assembly with the service and operation contracts in them - since the client must know at least the service interface in order to be able to use either of the two ways of connecting to the service.