代码之家  ›  专栏  ›  技术社区  ›  Rob Cooper

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

  •  1
  • Rob Cooper  · 技术社区  · 17 年前

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

    以下是目前的情况——基本上:

    • 我正在为我们的应用程序开发一系列控件。

    因此,以下是我所做的:

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

    专业的

    • 它将用户界面与核心代码真正分离,使其 .
    • 显然,由于核心/渲染逻辑的封装,当问题出现时,问题所在的位置是显而易见的。

    • 可以 看起来很困惑/臃肿。尽管每个类中没有大量的代码,但有3个类可以将其渲染为1个输出(1个核心、1个接口、1个渲染器)。但是,在创建WinForms/WebForms控件时,它还意味着另一个类(因为需要子类) Control AbstractRenderingEngine ).

    ... 好吧,这是我唯一能想到的“弊病”,也是这个问题的主要原因^_^

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


    这个问题可能会随着我更多的想法而更新,或者可能会要求澄清(我知道这是一个沉重的阅读!)。


    谢谢大家的回复。我会更多地学习MVP,看看我是否能进一步提高自己的能力。

    1 回复  |  直到 14 年前
        1
  •  2
  •   Mendelt    17 年前

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

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

    我看到的另一种方法是视图知道演示者,而演示者只通过界面知道视图。这就避免了为视图操作引发事件,因为视图可以直接与演示者对话。(我认为这在smalltalk世界中被称为MVC)presenter仍然是可测试的,这使您能够从视图到presenter进行数据绑定。我通常不使用数据绑定,所以对我来说这不是一个很大的优势。我希望像第一个例子中那样将东西解耦。