如何在C#中构建混合架构框架？

Question

我有一个我想要构建的控件框架的概念。这个想法的不同之处在于，我不打算采取“一刀切”的方法或“一种控制来统治所有人”的方法。

举个例子，Telerik做了一个非常好的网格控件，ComponentOne，Xceed等等。然而，它们都是具有成百上千个方法和属性、复杂的对象模型层次结构等的巨大控件。通常情况下，这些网格对于你所需要的东西来说是大材小用了，但你仍然必须承担学习整个网格来做一些简单事情的艰巨任务。

我的概念更多的是一种“混合”的方法。在这里你可以创建一个非常简单的控件，然后构建你可以“添加”到控件中的功能。例如，您有一个简单的网格，并且希望为每个网格添加具有页眉和页脚的网格“部分”。

好的，那么问题出在哪里？这样做的传统方法是通过多重继承，这是C#不支持的。即使它确实支持它，我仍然认为MI增加的问题比它解决的问题更多。

所以我正在征集关于如何处理这个问题的意见。MEF会是一个潜在的解决方案吗？

编辑：

我想到的一件事是，可以使用表达式树从各种表达式构建控件。我得再仔细考虑一下，但这是一个有趣的概念。

另一个可能的选项可能是“控件生成器”，它基于选定的特征生成部件。这看起来更复杂，但使用T4可能是可管理的。

Answer 1

几个选项

1. 考虑了装饰器模式；小对象扩展了您可以在运行时构建的相当简约的类的行为。Dotnet框架中的典型示例将围绕IO流(例如StreamReader/Writer，TextStreamReader/Writer，FileStreamReader/Writer)；这在OO框架中也很常见，典型的示例看起来类似于var window=new HorizontalScrollingWindowDecorator(new VerticalScrollingWindowDecorator(new Window));
2. The状态、策略、命令和复合模式，它们提供了各种替代方案来处理行为的组合，而不需要大量的控制流。例如，将某些类型的行为委托给对象的当前状态(某些类方法基本上调用当前对象状态的方法)。您还可以将行为委托给命令对象，或使用复合命令构建复杂的命令。单一继承通常会导致您倾向于组合对象而不是继承，这些都是用于组合行为的经典模式，这些模式在函数式编程中很常见的“中间有洞”模式可以使用委托，当某些小部分行为需要由特定实例实现时。
3. 您可以使用PostSharp或类似的面向方面的编程工具来执行运行时或编译时行为编织，特别适用于几个不同类需要的行为，这些类与该类的主要职责没有太多关系。

Answer 2

就我个人而言，我认为多重继承无论如何都不是实现这种设计的好方法。在大多数情况下，多重继承似乎是一种糟糕的设计。继承对组件之间的关系过于严格。

组合要灵活得多，在这种情况下，MEF将是一个很好的起点。

控件的基类将是一个行为容器--本质上是一个MEF容器。

它仍然留下了其他类如何与您的控件交互的问题。有很多选择。例如，基本控件上的标准接口，消息传递，甚至使用C# 4.0中的动态绑定。

Answer 3

我想试着回答，但不评论这是否是一个值得解决的问题。

我还没有在组件中尝试过这一点，但理论上有Decorator Pattern：您可以在运行时添加插件来拦截控件(键盘和鼠标)的输入和(屏幕)输出。