有关接口实现和可扩展性的体系结构问题

我创建了一个示例应用程序，只是为了测试并尝试一些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

有关接口实现和可扩展性的体系结构问题

回答

相关问题