2011-02-18 47 views
3

我有一個使用泛型在其數據的合同,例如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方法的對象圖中,我不確定這個解決方案可能會工作,並可能導致類型被錯誤地映射和其他此類問題。如果可能,我真的很想具體定義允許的映射。

+0

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

回答

0

不確定AutoMapper是否提供了您之後的支持,但是如果確實如此,則會按照您的建議使用反射。

如果由於性能問題(應該是一次性啓動成本),您反對反射解決方案,那麼基於T4模板的代碼生成解決方案可能值得考慮?

+0

一點都不反對 - 我們目前的解決方案使用反射效果很好。這個問題更傾向於看看是否有人使用適合AutoMapper框架的解決方案來避免自己編寫代碼。特別是我希望吉米(AutoMapper的作者)會介紹並給出一個兼顧的答案;) – Xcalibur 2011-03-01 07:13:05