关于接口实现和可扩展性的架构问题答案

【问题标题】：Architectural question regarding Interfaces implementation and extensibility关于接口实现和可扩展性的架构问题
【发布时间】：2011-05-24 13:47:21
【问题描述】：

我创建了一个示例应用程序，只是为了测试和试用 wpf 的一些功能。我基本上是在尝试 wpf 中的数据绑定，并或多或少地快速完成了其余的工作。然后，我遇到了一个架构问题（是的，应该在开始编码之前提前考虑：））我想知道什么是最好的重构解决方案。

我有一个简单的接口，它根据定义的过程返回对象列表。

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

我已经为这个接口创建了几个实现。然后我在 wpf 中有一个视图，它有一个带有硬编码值的下拉列表，并且根据您选择的内容，实例化接口的实现并填充一些列表

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

MyObjs 上的 ater 是列表视图的 DataContext，并显示诸如此类的东西，但这不是主要问题。

这都是硬编码的，不是很好。如果我要实现一个新接口，我需要将它添加到下拉列表中，并为该特定实现创建一个新的 foreach（更多重复代码）

好的，这是我对改进/重构以实现可扩展性的印象。我在想一个好的方法是使用某种 MVVM 模式，将 wpf 视图变成视图 + 视图模型。 viewmodel 将使用某种 IoC，如 spring，它会（通过 xml）实例化接口的一个特定实现，并将其注入 viewmodel，然后调用它的“Do”方法，每个人都很高兴。这样，当我们实现一个新组件时，唯一需要做的就是将它添加到 xml 配置文件中。建议、意见？如果有的话，最好的方法是什么？谢谢！！

【问题讨论】：

标签： c# design-patterns architecture mvvm

【解决方案1】：

实际上，如果您提供接口的另一个实现，我看不到任何架构更改。在使用 MVVM 时，您已经有了一个很好的架构，因此您尝试完成的任务不会改变架构，而是会使用该架构扩展您的应用程序。

【讨论】：

是的，但在当前情况下，构造函数获得一个 IWorker。在提议的场景中，我需要 Dictionary> 之类的东西，以便能够根据命令在适当的实现之间切换。但是在这里，我将有一些非常具体的代码来执行该切换，无论是在按钮命令中还是在 switch 语句中，或者检查应该应用哪个实现。我认为 mvvm 的想法是尽量避免这种情况？
hmm... 也许您可以跟踪 VM 中的 IWorker 对象并使用 CommandParameter 来识别按钮的 IWorker。如果保留所有 IWorker 实现的想法对您来说听起来不太好，您始终可以在代码中初始化 VM，并创建一个接受 IWorker 对象数组的 VM 构造函数。

【解决方案2】：

我建议您将Method 改为Property。并将该属性分配给ComboBox 的ItemsSource 属性，以简化使用数据绑定的编码。

【讨论】：

这真的没有多大帮助，我的主要问题是关于架构（和建议的增强），而不是如何进行数据绑定。
您提到了 MVVM，这就是为什么我建议您使用 Property 而不是 Method。 MVVM 基于Notifications、Data Binding 和Commands。使用Unity 或MEF 作为IoC。