添加AutoMapper类型映射约定对于WCF合同泛型类型

我有一个使用泛型在其数据的合同，例如WCF服务（简体）：添加AutoMapper类型映射约定对于WCF合同泛型类型

public GetDetails(StatusField<string> status);

现在WCF通过创建一个非泛型支持泛型对于泛型中T的每一个可能的值都是等价的类型。所以，上面的例子中，客户端消耗WCF服务将看到下面的签名上面的功能：

public GetDetails(stringStatusField status); 
//...

现在客户端的StatusField类的通用版本的副本。我们想在客户端使用AutoMapper来映射这个通用的StatusField和WCF上面生成的类型（比如stringStatusField），以便我们可以调用服务。我们可以通过在客户端启动手动创建的地图，像这样做：

Mapper.CreateMap<StatusField<string>, stringStatusField>();

但是因为有已完成转换的WCF的50多个可能的值，这是费力。扩展这个想法，我们可以使用反射来为所有类型自动创建地图，这是我们目前使用的解决方案。

理想情况下，我想看到的是一种解决方案，它与AutoMapper的体系结构相关联，以避免手动进行反射。从概念上讲，这需要一些定义AutoMapper将用来将两种类型绑定在一起的约定的方式，类似于它允许在匹配属性时指定自定义约定。到目前为止，我还没有看到一种方法来做到这一点，如果有人知道如何做到这一点，那么我想在这里回答这个问题，特别是关于上述情况。

顺便说一句我知道有些人可能会想到Mapper.DynamicMap（）作为解决这个问题的方法。首先，我们不想使用它，因为这意味着调试可能会更困难（正如其他类似于此的帖子所指出的那样），并且如果StatusField深深地嵌套在传递给WCF方法的对象图中，我不确定这个解决方案可能会工作，并可能导致类型被错误地映射和其他此类问题。如果可能，我真的很想具体定义允许的映射。

来源

2011-02-18 Xcalibur

客户是否生成wcf的要求？否则可以使用ChannelFactory。 – 2011-02-28 22:35:14

不确定AutoMapper是否提供了您之后的支持，但是如果确实如此，则会按照您的建议使用反射。

如果由于性能问题（应该是一次性启动成本），您反对反射解决方案，那么基于T4模板的代码生成解决方案可能值得考虑？

来源

2011-02-28 23:05:22

一点都不反对 - 我们目前的解决方案使用反射效果很好。这个问题更倾向于看看是否有人使用适合AutoMapper框架的解决方案来避免自己编写代码。特别是我希望吉米（AutoMapper的作者）会介绍并给出一个兼顾的答案;） – Xcalibur 2011-03-01 07:13:05

添加AutoMapper类型映射约定对于WCF合同泛型类型

回答

相关问题