不使用代码生成工具而共享WCF代码-.net-火龙果软件工程

分享到

不使用代码生成工具而共享WCF代码

作者 Jonathan Allen，火龙果软件发布于 2014-03-13

在传统WCF开发时遇到的一个主要问题是代码重用。无论你的服务端类设计得再怎么好，一旦经过代理（proxy）生成工具的处理，你就只能得到简单的DTO（数据传输对象）。本文将说明如何绕过代理生成工具，而使得你的客户端和服务端能够共享代码。

为了论述方便，我们在下面的例子中将使用这个服务接口。

[ServiceContract(Namespace = "https://zsr.codeplex.com/services/")] 
public interface IInformationService 
{
      [OperationContract] 
     Task<zombietypesummarycollection> ListZombieTypes();

[OperationContract]
Task<zombietypedetails> GetZombieTypeDetails(int zombieTypeKey);

[OperationContract]
Task<int> LogIncident(SessionToken session, ZombieSighting sighting);
}

为了支持.NET 4.5中的async/await关键字，每个方法会返回一个Task或Task<T>对象。

不使用代理生成工具的理由

不可变对象与数据契约

不可变对象较少出错，这一点如今已被广泛认可了。除非调用数据契约类的代码需要直接编辑某个属性，否则该属性就应该被标记为只读，以避免发生错误。

这里是一个仅限于只读显示的类的示例。

using System;
using System.Runtime.Serialization;

namespace Zombie.Services.Definitions
{
[DataContract(Namespace = "https://zsr.codeplex.com/services/")]
public class ZombieTypeSummary
{
public ZombieTypeSummary(string zombieTypeName, int zombieTypeKey, string
briefDescription = null, Uri thumbnailImage = null)
{
ZombieTypeName = zombieTypeName;
ZombieTypeKey = zombieTypeKey;
BriefDescription = null;
ThumbnailImage = thumbnailImage;
}

[Obsolete("This is only used by the DataContractSerializer", true)]
public ZombieTypeSummary() { }

[DataMember]
public string ZombieTypeName { get; private set; }

[DataMember]
public int ZombieTypeKey { get; private set; }

[DataMember]
public string BriefDescription { get; private set; }

[DataMember]
public Uri ThumbnailImage { get; private set; }

}
}

在以上代码中你会注意到一件奇怪的事，它有一个被标记为过期的公共构造函数（译注：这避免了该构造函数被任何客户端代码所直接调用）。即使在反序列化对象时WCF并不真正调用这个构造函数，但它必须存在。我们只需再添加一些特性，使得WCF知道哪些字段需要被传递就可以了。

如果我们看一下生成的代理服务，它看上去会和我们之前编写的服务端代码略有相似。

[DebuggerStepThroughAttribute()]
[GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[DataContractAttribute(Name = "ZombieTypeSummary", Namespace = 
   "https://zsr.codeplex.com/services/")]
[SerializableAttribute()]
[KnownTypeAttribute(typeof(ZombieTypeDetails))]
public partial class ZombieTypeSummary : object, IExtensibleDataObject, 
INotifyPropertyChanged
{
   [NonSerializedAttribute()]
   private ExtensionDataObject extensionDataField;

[OptionalFieldAttribute()]
private string BriefDescriptionField;

[OptionalFieldAttribute()]
private Uri ThumbnailImageField;

[OptionalFieldAttribute()]
private int ZombieTypeKeyField;

[OptionalFieldAttribute()]
private string ZombieTypeNameField;

[BrowsableAttribute(false)]
public ExtensionDataObject ExtensionData
{
get { return this.extensionDataField; }
set { this.extensionDataField = value; }
}

[DataMemberAttribute()]
public string BriefDescription
{
get { return this.BriefDescriptionField; }
set
{

if ((object.ReferenceEquals(this.BriefDescriptionField, value) != true))
{
this.BriefDescriptionField = value;
this.RaisePropertyChanged("BriefDescription");
}
}
}

[DataMemberAttribute()]
public Uri ThumbnailImage
{
get { return this.ThumbnailImageField; }
set
{

if ((object.ReferenceEquals(this.ThumbnailImageField, value) != true))
{
this.ThumbnailImageField = value;
this.RaisePropertyChanged("ThumbnailImage");
}
}
}

[DataMemberAttribute()]
public int ZombieTypeKey

{
get { return this.ZombieTypeKeyField; }
set
{
if ((this.ZombieTypeKeyField.Equals(value) != true))
{
this.ZombieTypeKeyField = value;
this.RaisePropertyChanged("ZombieTypeKey");
}
}
}

[DataMemberAttribute()]
public string ZombieTypeName
{
get { return this.ZombieTypeNameField; }
set
{

if ((object.ReferenceEquals(this.ZombieTypeNameField, value) != true))
{
this.ZombieTypeNameField = value;
this.RaisePropertyChanged("ZombieTypeName");
}
}
}

public event PropertyChangedEventHandler PropertyChanged;

protected void RaisePropertyChanged(string propertyName)

{
PropertyChangedEventHandler propertyChanged = this.PropertyChanged;
if ((propertyChanged != null))
{
propertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
}

补充：性能与PropertyChangedEventArgs

假设我们所操作的属性是可变的，那么创建PropertyChangedEventArgs的实例就将成为一个性能问题。单独一个实例创建的开销其实是非常小的，构造这些实例的字符串已经由外部传入对象，因此你只需为每个事件做一次内存分配就可以了。

问题就出在 “每个事件”上。如果有大量事件产生，你将会制造不必要的内存压力和更频繁的垃圾回收周期。并且如果事件引起了其它对象被分配，你就混杂地制造了很多短生命周期和长生命周期的对象。通常情况下这不是问题，但在对性能敏感的应用程序中它就可能成为问题了。因此，你需要像以下方法那样缓存事件参数对象：

static readonly IReadOnlyDictionary s_EventArgs =
   Helpers.BuildEventArgsDictionary(typeof(ZombieSighting));

void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
OnPropertyChanged(s_EventArgs[propertyName]);
}

public DateTimeOffset SightingDateTime
{
get { return m_SightingDateTime; }
set
{
if (m_SightingDateTime == value)
return;
m_SightingDateTime = value;
OnPropertyChanged();
}
}

令人惊讶的是，代理生成工具并不会自动创建事件参数的缓存。其实它甚至不需要在Dictionary中查找对象，只需像这样生成静态字段就可以了：

static readonly PropertyChangedEventArgs s_SightingDateTime = new
 PropertyChangedEventArgs("SightingDateTime");

验证，计算属性及类似代码

使用传统的代理服务时，往往倾向于通过复制和粘贴共享验证方法、计算属性及类似代码，这样很容易导致错误，尤其是在基础代码也在不断地进行修改时。可以通过partial类将它们放到独立的文件当中，并共享其中部分文件。这可以减少它的错误机率，但是这种方法仍然有一些局限性。

一个设计良好的代码生成器（比如ADO.NET Entity Framework）会创建“XxxChanging” 和 “XxxChanged”等partial方法，允许开发者在属性的setter方法中注入附加的逻辑。遗憾的是代理生成工具并没有这么做，这迫使开发者不得不把属性更改的事件监听传入构造函数和OnDeserialized方法中。

另一个问题是客户端和服务端不能共享声明性的验证方法。由于所有的属性都是由代理生成工具创建的，没有地方可以加入适当的特性声明（attribute）。

集合

如同每一个WCF开发者会告诉你的一样，代理生成工具会完全忽视集合的类型。客户端虽然可以在数组、list和observable集合中进行选择，但所有特定类型信息都会丢失。事实上，对WCF代理生成工具来说，所有的集合都可以暴露为IList<T>。

不使用代理生成工具可以解决这个问题，但是也随之产生了一些新问题。尤其因为你不能对集合类使用DataContract特性，意味着集合不能有任何属性被序列化，这是一个相当不幸的设计决策，因为SOAP是基于XML的，而使用XML的特性和属性是非常适合于表达集合概念的。

如果你能够从集合的子项中推算出集合的所有属性，你就能够凭空生成它们。否则，你必须把这个类分离为普通类和集合类。

代码生成

在开发过程中，有许多可以避免的bug产生自代码生成工具本身。它要求代理被生成的时候服务端处于运行状态，而这一步骤是难以集成到通常的构建过程中的。开发者不得不选择手动进行更新，而这一任务经常被忽视。虽然它不大会在生产环境中产生问题，但会浪费开发者的时间去查找服务调用突然间不能正常工作的原因。

实现无代理的WCF

由于基本的设计模式如此简单，简单到令人质疑代理生成工具存在的理由。（代理生成也并非全无用处，在调用非WCF的服务时还是需要它的）。如你所见，你只需创建一个ClientBase的子类，传递你打算实现的接口，并暴露Channel属性。建议加入构造函数，不过它是可选的。

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;

namespace Zombie.Services.Definitions
{
public class InformationClient : ClientBase
{
public new IInformationService Channel
{
get { return base.Channel; }
}

public InformationClient()
{
}

public InformationClient(string endpointConfigurationName) :
base(endpointConfigurationName)
{
}

public InformationClient(string endpointConfigurationName, string remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}

public InformationClient(string endpointConfigurationName, EndpointAddress
remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}

public InformationClient(Binding binding, EndpointAddress remoteAddress) :
base(binding, remoteAddress)

{
}
}
}

支持依赖注入

这个模式带来的一个好的副作用是，为了单元测试而让它支持依赖注入是很方便的。为此，我们首先需要一个接受这个服务接口的构造函数，然后重写或屏蔽由ClientBase暴露的某些方法。

private IInformationService m_MockSerivce;
public InformationClient(IInformationService mockService)
   : base(new BasicHttpBinding(), new EndpointAddress("http://fakeAddress.com"))
{
   m_MockSerivce = mockService;
}

public new IInformationService Channel
{
get { return m_MockSerivce ?? base.Channel; }
}

protected override IInformationService CreateChannel()
{
return m_MockSerivce ?? base.CreateChannel();
}

public new void Open()
{
if (m_MockSerivce == null)
base.Open();
}

机敏的读者会注意到这并非最整洁的API，并且遗留了某些缺陷。例如，一个QA开发者可以将其转换为基类，并直接调用真正的Open方法。只要这是大家都知道的一个局限性，就不大会出错。并且只要使用伪地址，它就不会有机会去实际连接到真实的服务器。

部分代码共享的选项

在.NET服务端和.NET或WinRT客户端共享代码的默认选项是共享程序集引用。但有时候你只想在服务端和客户端共享某个类的一部分，有两种方法可以实现：

选项1是使用关联文件，配合使用条件编译指令，它的优点是所有的生成代码都在一起，但结果可能相当混乱。

选项2也使用关联文件，但这次你将使用一个包含在多个文件中的partial类，其中一个文件将被共享，而其余文件仅包含用在客户端或服务端的代码。

考虑Silverlight

这个模式可以使用在Silverlight中，但是还有些额外的考虑。首先，WCF的Silverlight版本要求所有的服务方法用老式的IAsyncResult方式编写。

[ServiceContract(Namespace = "https://zsr.codeplex.com/services/")]
public interface IInformationService
{
   [OperationContractAttribute(AsyncPattern = true)]
   IAsyncResult BeginListZombieTypes(AsyncCallback callback, object asyncState);

ZombieTypeSummaryCollection EndListZombieTypes(IAsyncResult result);

[OperationContractAttribute(AsyncPattern = true)]
IAsyncResult BeginGetZombieTypeDetails(int zombieTypeKey, AsyncCallback callback
, object asyncState);

ZombieTypeDetails EndGetZombieTypeDetails(IAsyncResult result);

[OperationContractAttribute(AsyncPattern = true)]
IAsyncResult BeginLogIncident(SessionToken session, ZombieSighting sighting,
AsyncCallback callback, object asyncState);

int EndLogIncident(IAsyncResult result);
}

为了使用新的async/await方式，你需要使用FromAsync函数将接口重新封装为Task。

public static class InformationService
{
   public static Task ListZombieTypes(this IInformationService client)
   {

return Task.Factory.FromAsync(client.BeginListZombieTypes(null, null),
client.EndListZombieTypes);
}

public static Task GetZombieTypeDetails(this IInformationService client,
int zombieTypeKey)
{

return Task.Factory.FromAsync(client.BeginGetZombieTypeDetails(zombieTypeKey,
null, null), client.EndGetZombieTypeDetails);
}

public static Task LogIncident(this IInformationService client, SessionToken
session, ZombieSighting sighting)
{

return Task.Factory.FromAsync(client.BeginLogIncident(session, sighting, null,
null), client.EndLogIncident);
}
}

关于“僵尸标准参考”项目

为了展示.NET平台上和各种技术实现的不同，我们正在创建一个参考应用程序。这不仅仅是个传统的hello world应用，我们决定打造的是“僵尸标准参考”项目。这包含了一系列应用，如报告僵尸的目击情况，管理库存（例如对抗僵尸毒的疫苗），以及调查队派遣等等。这使得我们有机会观察一个真实世界中的应用程序的数据库、移动应用、定位修正及一些其它的常见的实用功能。