有關接口實現和可擴展性的體系結構問題

我創建了一個示例應用程序，只是爲了測試並嘗試一些wpf的功能。我基本上是在wpf中嘗試數據綁定，並且或多或少地快速完成其餘的部分。那麼，我遇到了一個問題（是的，應該在開始編碼之前預先考慮:)），我想知道什麼是最好的重構解決方案。有關接口實現和可擴展性的體系結構問題

我有一個簡單的界面，基於定義的過程返回對象列表。

public interface IDoStuff<out T> 
    { 
     IEnumerable<T> Do(string someParam); 
     }

我已經爲這個接口創建了幾個實現。然後，我在WPF視圖，它與硬編碼值的下拉列表中，並根據您選擇的條件，instatiates接口的實現，並填充一些列表

foreach (var item in new IDoSTuffImplementation1()<MyObj>.Do("imp 1")) 
{ 
    MyObjs.Add(item); 
}

亞特上MyObjs是DataContext的一個列表視圖，並顯示事物等等，但這不是主要問題。

這是全部硬編碼，不是很好。如果我曾經實現一個新的界面，我需要將它添加到下拉列表中，併爲該特定實現創建一個新的foreach（更多重複代碼）

好的，這是我對改善/重構的印象爲了可擴展性。我在想一個好方法是使用某種MVVM模式，將wpf視圖變爲視圖+視圖模型。 viewmodel會使用像spring這樣的IoC，它會（通過xml）實例化一個特定的接口實現，並將其注入到viewmodel中，然後調用它的「Do」方法，並且每個人都高興。所以這樣，當我們實現一個新組件時，唯一需要做的就是將它添加到xml配置文件中。建議，意見？最好的方法是什麼？謝謝!!

來源

2010-12-13 Daniel Perez

我建議你改變你Method而不是Property。然後將該屬性分配給ComboBox的ItemsSource屬性以緩解使用數據綁定的編碼。

來源

2010-12-13 09:50:55 decyclone

這真的沒有什麼幫助，我的主要問題是對架構（和建議的增強）認爲，而不是如何進行數據綁定。 – 2010-12-13 10:03:18

你提到MVVM，這就是爲什麼我建議你使用'Property'而不是'Method'。 MVVM基於'Notifications'，'Data Binding'和'Commands'。使用'Unity'或'MEF'作爲'IoC'。 – decyclone 2010-12-13 10:06:45

其實我沒有看到任何體系結構的變化，如果你提供了另一個接口的實現。在使用MVVM時，您已經擁有了一個很好的體系結構，因此您嘗試完成的任務不會更改體系結構，但會使用該體系結構擴展您的應用程序。

來源

2010-12-13 23:14:27 Davita

是的，但在目前的情況下，構造函數獲取IWorker 。在建議的場景中，我需要像Dictionary >或類似的東西，以便能夠根據命令在適當的實現之間切換。但是在這裏，我需要一些非常具體的代碼來完成這個開關，無論是在按鈕命令中，還是在switch語句中，或者是用來檢查應該使用哪種實現的代碼。我認爲mvvm的想法是試圖避免，除其他外，這是什麼？ – 2010-12-13 23:38:49

hmm ...也許你可以跟蹤VM中的IWorker對象，並使用CommandParameter來識別按鈕的IWorker。如果保留所有IWorker實現的想法對您來說聽起來不太合適，您可以始終在代碼後面初始化VM，並創建一個接受IWorker對象數組的VM構造函數。 – Davita 2010-12-13 23:53:34

有關接口實現和可擴展性的體系結構問題

回答

相關問題