避免WCF Service Reference 和 WCF Service Factory的误导作用
link/Files/callwangxiang/SimpleWCF.rar
为了简化WCF的开发,我们可以通过在项目中Add Service Reference的方式(或svcutil)生成一个代理类。
后来P&P提供了Service Factory,该工程可以帮助我们设计WCF, 并根据需要灵活选择WS-*或WCF实现、代码自动生成、配置的工作。
这两种方式生成的客户端代理都回包括一份重复的Service Contract、Data Contract(还有MessageContract、FaultContact定义),
不过就像我们不会在一些大些的项目中直接托拽Connection\Command空间辅助数据访问一样,用这些工具生成的代码、配置文件包括非常多的“垃圾”,
另外,同一份实体编译两次也不利于我们部署。
不妨回归到本来的WCF代码,我们采用类似Remoting的方式,下面是一个瘦身之后的示例:

采用该方式的优势:
1、实体一致性, 便于在企业(或行业)内实施全局WCF项目时,标准业务实体重复定义,可以直接服务于行业XML DM(Data Model)或MDM(Master Data Management),可以在多个项目组的Service、Client分发标准业务实体
2、干净,没有“脏”的重复代码和配置
3、符合服务分层结构,

1、Common.dll
[DataContract]
public class Complex
{
[DataMember]
public int X;

[DataMember]
public int Y;

public Complex(int x, int y)
{
this.X = x;
this.Y = y;
}

public Complex()
{
}

public override string ToString()
{
return string.Format("({0}, {1})", X, Y);
}
}

[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int x, int y);

[OperationContract]
int Substract(int x, int y);

[OperationContract]
Complex AddComplex(Complex a, Complex b);
}
2、Host.exe
public class CalculatorService : ICalculator
{
ICalculator Members
}
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="Host.CalculatorService">
<endpoint
address="http://localhost:8000/Derivatives/Calculator"
binding="wsHttpBinding"
contract="Common.ICalculator" />
</service>
</services>
</system.serviceModel>
</configuration>
static void Main(string[] args)
{
using (ServiceHost host = new ServiceHost(typeof(CalculatorService)))
{
host.Open();
Console.WriteLine("Service is available.");
Console.ReadKey();
}
}
3、Client.exe
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<client>
<endpoint name="CalculatorService"
address="http://localhost:8000/Derivatives/Calculator"
binding="wsHttpBinding"
contract="Common.ICalculator"/>
</client>
</system.serviceModel>
</configuration>
static void Main(string[] args)
{
Console.WriteLine("Press any key when the service is available.");
ICalculator proxy = new ChannelFactory<ICalculator>("CalculatorService").CreateChannel();
Console.WriteLine(proxy.Add(1, 2));

Complex a = new Complex();
a.X = 3;
a.Y = 4;

Complex b = new Complex();
b.X = 3;
b.Y = 1;

Complex result = proxy.AddComplex(a, b);
Console.WriteLine(result);

Console.ReadKey();
}
为了简化WCF的开发,我们可以通过在项目中Add Service Reference的方式(或svcutil)生成一个代理类。
后来P&P提供了Service Factory,该工程可以帮助我们设计WCF, 并根据需要灵活选择WS-*或WCF实现、代码自动生成、配置的工作。
这两种方式生成的客户端代理都回包括一份重复的Service Contract、Data Contract(还有MessageContract、FaultContact定义),
不过就像我们不会在一些大些的项目中直接托拽Connection\Command空间辅助数据访问一样,用这些工具生成的代码、配置文件包括非常多的“垃圾”,
另外,同一份实体编译两次也不利于我们部署。
不妨回归到本来的WCF代码,我们采用类似Remoting的方式,下面是一个瘦身之后的示例:
采用该方式的优势:
1、实体一致性, 便于在企业(或行业)内实施全局WCF项目时,标准业务实体重复定义,可以直接服务于行业XML DM(Data Model)或MDM(Master Data Management),可以在多个项目组的Service、Client分发标准业务实体
2、干净,没有“脏”的重复代码和配置
3、符合服务分层结构,
1、Common.dll






































2、Host.exe



























3、Client.exe






























贸易电子化,技术全球化
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· 展开说说关于C#中ORM框架的用法!
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?