我正在为应用程序开发一个面向服务的体系结构,我希望这些服务既可以通过 WCF 公开,也可以通过一个简单的库使用。理想情况下,我想减少重复代码。
从概念上讲,这映射到:
Client => WCF Service => 服务库(实际实现)
或
客户端=>服务库(实际实现)
基于客户端所在的位置(本地或远程)。
这是一个简单的例子:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int a, int b);
}
public class Calculator : ICalculator
{
public int Add(int a, int b)
{
return a + b;
}
}
public class CalculatorFactory
{
public static ICalculator CreateCalculator()
{
return new Calculator();
}
}
我的客户端应用程序执行了以下操作
int result = CalculatorFactory.CreateCalculator().Add(1,2);
或
int result = IChannelFactory<ICalculator>().CreateChannel().Add(1,2);
取决于它是本地的还是远程的。
直接调用 WCF 注释代码(即不使用 WCF)是一种不好的做法吗?
补充说明:
- 我意识到我可以在所有情况下使用 WCF,并且只需使用 NamedPipes 为本地连接托管服务。为简单起见,我想尽量避免这种情况。
- 上述方法的替代方法是基本上复制服务库中的 ICalculator 接口(interface),并将 WCF 服务实现更改为包含 CalculatorFactory.CreateCalculator().Add(1,2)。考虑到我希望界面相同,这似乎有很多开销。
最佳答案
除非您开始使用一些 WCF 相关功能,例如 OperationContext
等,否则您可以在本地创建和使用 WCF 注释类而不会出现任何问题。
通常这通常以不同的方式抽象:
Client => ServiceAgent => 业务服务
或
Client => ServiceAgent => WCF Service => 业务服务
客户端本身并不知道服务是本地的还是远程的。服务代理是客户端组件,它基于其实现创建本地服务实例或调用远程 WCF 服务,后者又创建业务服务实例。 ServiceAgent 可以作为依赖项注入(inject)客户端,这将使您的应用程序具有很好的可配置性。您还可以在服务代理上公开不同的接口(interface)(与业务服务实现相同),如果您希望 WCF 服务和代理可以使用不同的接口(interface)。
如果您决定一直使用 WCF 服务(包括本地调用),请不要使用 NamedPipes。 NamedPipes 用于同一台机器上的进程间通信。如果您想在同一进程中使用通信,请使用 NullTransport或 Local Channel反而。它的性能仍然比直接调用差。
关于wcf - 在不使用 WCF 的情况下调用 WCF 服务 - 好的还是坏的做法?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5766238/