「接口編碼」和業務實體的最佳實踐？

應該使用接口和/或基類將業務實體抽象出來，以便當你傳遞它們時只使用接口/基類？（這是我們一直在做的）。「接口編碼」和業務實體的最佳實踐？

還是應該實體不使用的接口抽象並只在必要時應該使用的傳承？

我之所以問這個問題，是我一直儘量抽離使用接口的我的應用程序代碼的所有部分。這使得我可以很容易地使用mock等進行單元測試。另外，通過使用接口，我可以確保只有工廠類實際引用包含實現的項目以及所有其他項（例如：業務邏輯層）該項目包含所有的接口。

上述工作一直很好，直到現在。但是現在，我們需要通過WCF公開一些業務方法。用於返回接口的業務方法，但現在我試圖重複使用相同的方法並通過WCF公開它，WCF不喜歡我使用和返回接口作爲服務方法參數一部分的事實。

現在我可以嘗試使用KnownTypes和ServiceKnownTypes解決問題，但它讓我想如果我沒有爲我的應用程序的業務實體部分使用接口，我不會遇到這個問題。

所以我想如果有一個最好的做法，當涉及到一個新的項目：如果您或你應該不會有你的所有業務實體的接口？

來源

2011-03-23 Raj Rao

我見過很多人推薦針對商業實體的接口。並且通過電線發送您的商業實體也可能是一個壞主意。 – driushkin 2011-03-24 17:14:55

實際上，你可以告訴WCF使用跨線你的接口，所以它不是一個問題。

這是添加服務引用對話框中的設置。

什麼你要找的是選項「中引用組件重用類型」。

你要確保你的合同正在上線的兩端用，所以你需要確保你選擇重用引用程序集，你需要確保你的組件在引用程序集列表。

http://msdn.microsoft.com/en-us/library/bb514724.aspx

爲了避開不必知道有關的子類，你可以做這樣的事情的基類：

[KnownType("GetKnownTypes")] 
public abstract class Shape 
{ 
    static Type[] GetKnownTypes() 
    { 
     //do some reflection here to look up all classes that extend Shape 
     //and are serializable 
     return results; 
    } 
}

我不知道，你可以用同樣的方法爲一個接口，因爲它需要有一個靜態方法實現。

來源

2011-03-23 18:01:55 Joseph

當您將實際的類作爲WCF實現的一部分返回時，此工作正常。但是當你返回或使用接口作爲你的方法簽名的一部分時，你最終必須用KnownTypeAttribute來修飾大量的代碼，這就是我的問題所在。（此外，除了手動檢查類之外，沒有簡單的方法來添加KnownTypeAttribute） – 2011-03-23 20:49:38

@Rajah我明白你的意思，我會用一種方法更新我的答案 – Joseph 2011-03-24 16:49:02

「接口編碼」和業務實體的最佳實踐？

回答

相關問題