将MVP界面模式中的演示者划分为过大的优秀做法是什么?

时间:2009-05-07 16:25:19

标签: user-interface refactoring mvp

我最近经常遇到的一个问题是我的演示者课程变得太大了。通常,我可以在不跳过节拍的情况下切断常规的大班。但是主持人有时候更难以削减,而不会让代码更难以遵循。

特别是当页面开始填满面向CRUD的控件时。有时我将控制分开,但如果它们受到其他控制的影响,协调逻辑本身就很复杂。有时我会将列表或网格数据检索分开,但有时候会有类似的陷阱。

您是否有任何技巧,经验法则或公共区域可以从演示者身上重构出来?

2 个答案:

答案 0 :(得分:9)

我通常使用两种方法:

  1. 将业务规则提取并委托给域类。
  2. 将视图分区为逻辑相关的控件,然后为每个分区创建一个新的视图界面。然后,您可以沿着相同的行拆分演示者。如果您使用的平台支持子表单组件组(C#用户控件,Delphi框架等),这是一种生成可重用控件的强大方法。
  3. <强>更新

    在拆分视图时,我通常首先拆分界面并让我的表单实现多个接口。

    public class ComplexForm: Form, ISubView, IOtherSubView
    {
        ...
    }
    

    然后我将演示者分成了我创建的许多视图。

    public class SubViewPresenter
    {
        private ISubView subView;
        ...
    }
    
    public class OtherSubViewPresenter
    {
        private IOtherSubView otherSubView;
        ...
    }
    

    您可以更进一步,将ISubView和IOtherSubView的实现移动到用户控件或保持原样。如果您使用的是被动视图模式,那么这是儿童游戏,因为表单只会处理UI逻辑。一旦我拆分演示者,我会尽量避免演示者之间的直接沟通。如果需要任何通信,我尝试通过域对象间接进行。

答案 1 :(得分:2)

尝试提取在将数据传递到DAL或将其推送到视图之外执行活动的代码。例如,如果您必须执行电子邮件更新或执行业务逻辑,请尝试将这些更新提取到单独的类中。我经常处理同样的问题,并且一直试图将尽可能多的逻辑移动到各个域/实体类并在那里执行验证。

希望这有用。