我只是想看看我是否对我目前正在做的某些工作的设计有想法。

这是目前的情况-基本上是：

• 我正在为我们的应用程序开发一系列控件。
• 其中一些可以在WinForms和ASP.NET Web应用程序中使用。
• 我一直在不断努力，以提高我的代码的可测试性和可测试性。

所以，这是我所做的：

• 在没有UI概念的类中创建了核心控制逻辑。当有关事情发生变化时，它只会引发事件。所有存储为自定义类型对象的数据都需要与其他对象区分开(例如，我有一个" PagingControl"，其中包含" SelectedPage"和" PageNumber"项)。
• 然后，我创建了一个抽象类，用作渲染"引擎"的接口。这确保了引擎使用或者可能添加到核心逻辑的所有自定义类型都可以被引擎处理。在上面的示例之后，它包含一个抽象方法" RenderSelectedPage"。
• 然后，我创建了抽象渲染引擎的具体实现(例如，" ConsoleRenderingEngine"，" HtmlRenderingEngine"等)。然后，这将处理这些方法，并根据需要将其呈现到各自的UI /输出中。

我发现这种方法具有以下优点和缺点：

专业人士

• 有用。非常好，它很容易实现新的呈现机制，我们要做的就是将抽象引擎子类化并呈现输出(将所需的引用传递给我们)。
• 它确实将UI与核心代码分开，从而使测试变得更加容易。
• 显然，由于核心/渲染逻辑的封装，当问题出现时，问题出在哪里就很明显了。骗子的
• 它可能看起来令人困惑/肿胀。即使每个类中没有大量的代码，也可以使用3个类将其渲染为1个输出(1个核心，1个接口，1个渲染器)。但是，在创建WinForms / WebForms控件时，它也意味着另一个类(因为必须同时包含Control和AbstractRenderingEngine)。

...好吧，那是我真正想到的唯一"骗子"，也是这个问题的主要原因^ _ ^

所以，

随着更多的想法出现，这个问题可能会得到更新，或者可能需要澄清(我知道这是一本繁重的读物！)。

更新

谢谢你们的回答，有趣的是我们说过MVP，我以为我在某个地方见过类似的东西，但我一生都记不清它是什么了！一看到" MVP"，我就认为"该死"。 ：D

谢谢你们的回应。我将进一步研究MVP，看看我是否可以进一步提高自己的水平。

解决方案

从描述来看，这有点像我做MVP的方式，但是事件却是相反的。

我通常只有一个很薄的视图，隐藏在界面后面，对演示者一无所知。该视图是根据用户操作引发事件的视图。通常，视图所做的只是翻译特定于原语的UI或者有时来自模型的值对象(ddd意义上的值对象，而不是.net结构)。有时，我将视图嵌套用于更复杂的情况和重用。 UserControl有时具有自己的视图和演示者结构。当我们开始进行嵌套视图和演示者时，对象的实例化开始进行大量工作，因此通常是在我开始寻找IoC容器时。

演示者通过其界面了解该视图，并直接与之对话。它对查看事件做出反应，并执行大多数逻辑。视图和模型已放入演示者，因此其中的所有逻辑都是可测试的。

我看到的另一种方法是，视图了解演示者，而演示者仅通过界面了解视图。这样就不必为视图操作引发事件，因为视图可以直接与演示者对话。 (我认为这在smalltalk世界中曾经被称为MVC。)演示者仍然是可测试的，这使我们能够从视图到演示者进行数据绑定。我通常不使用数据绑定，因此对我来说这并不是一个很大的优势。我将第一个示例中的内容解耦一些。