关于设计的思考 - 核心控制逻辑和渲染层

Question

我只是想知道我是否可以对我目前正在做的一些工作的设计有所了解。

以下是目前的情况 - 基本上：

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

所以，这就是我所做的：

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

我发现了以下专家和这种方法：

Pro的

• 有效。很好，它很容易实现一个新的渲染机制，你所做的只是将抽象引擎子类化并渲染输出（将所需的引用传递给你）。
• 它实际上是从核心代码中分离UI，使其更容易测试。

• 显然，由于核心/渲染逻辑的封装，当它们出现时会出现问题，这一点非常明显。

  精读的

• 它可能看起来令人困惑/臃肿。即使每个类中没有大量代码，也有3x类可以将其渲染为1个输出（1x核心，1x接口，1x渲染器）。但是，在创建WinForms / WebForms控件时，它还意味着另一个classe（因为需要sublcass Control以及AbstractRenderingEngine）。

...好的，这是我能想到的唯一“骗局”，以及这个问题的主要原因^ _ ^

所以，

您对这种“模式”有何看法？你会如何改变/改善它？

---

这个问题可能会随着更多想法的到来而得到更新，或者可能会要求明确（我知道这是一个沉重的阅读！）。

---

更新

感谢你们的答案，有趣的是你说MVP，我以为我曾经在某个地方见过这样的东西，但是不记得我的生活是什么！当我看到“MVP”时，我认为“该死”。 ：d

感谢回复人员。我将更多地研究MVP，看看我是否可以进一步改进。

Answer 1

从你的描述来看，这有点像我做MVP的方式，但事件是另一回事。

我通常有一个非常薄的视图隐藏在界面背后，并且对演示者一无所知。视图是在用户操作上抛出事件的视图。通常所有的视图都是转换特定于基元的UI，或者有时是模型中的值对象（ddd意义上的值对象，而不是.net结构）有时候，我会为更复杂的情况嵌套视图并进行重用。 UserControls有时会有自己的视图和演示者结构。当您开始执行嵌套视图和演示者时，对象的实例化会开始大量工作，所以这通常是在我开始寻找IoC容器时。

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

我看到的另一种方法是视图了解演示者，演示者只通过界面了解视图。这样就不得不为视图操作引发事件，因为视图可以直接与演示者对话。 （我认为这是以前在smalltalk世界中被称为MVC的东西）演示者仍然是可测试的，这使您能够从视图到演示者进行数据绑定。我通常不使用数据绑定，所以对我来说这不是一个很大的优势。我在第一个例子中更加分解东西。