1

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

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

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

所以，这就是我所做的：

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

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

专业人士

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

  • 显然，由于核心/渲染逻辑的封装，问题出现时很明显。

    骗局

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

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

所以，

你对这个“模式”有什么看法？你会如何改变/改进它？

这个问题可能会随着我的更多想法而更新，或者可能需要澄清（我知道这是一个沉重的阅读！）。

更新

谢谢你们的回答，你说MVP很有趣，我以为我在某个地方看到过这样的东西，但我一生都记不起它是什么了！一看到“MVP”，我就想“该死”。:D

谢谢你们的回应。我会更多地研究 MVP，看看我是否可以进一步改进我所拥有的东西。

4

1 回答 1

2

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

我通常有一个非常薄的视图，它隐藏在界面后面，并且对演示者一无所知。视图是在用户操作上引发事件的视图。通常，视图所做的只是将 UI 特定于原语或有时来自模型的值对象（ddd 意义上的值对象，而不是 .net 结构）有时我嵌套视图以用于更复杂的情况和重用。UserControls 有时有自己的视图和演示者结构。当您开始嵌套视图和演示者时，对象的实例化开始得到大量工作，所以这通常是我开始寻找 IoC 容器的时候。

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

我看到的另一种方法是视图了解演示者，而演示者仅通过界面了解视图。由于视图可以直接与演示者对话，因此不必为视图操作引发事件。（我认为这在 smalltalk 世界中曾经被称为 MVC）presenter 仍然是可测试的，这使您能够从视图到 Presenter 进行数据绑定。我通常不使用数据绑定，所以对我来说这不是一个很大的优势。我在第一个例子中解耦的东西有点像。

于 2008-09-22T13:08:24.357 回答