事件处理的一般最佳实践（方法）答案

【问题标题】：General Best practice for Event handling (methods)事件处理的一般最佳实践（方法）
【发布时间】：2013-08-08 21:10:25
【问题描述】：

到目前为止，我将所有对事件做出反应的代码直接放入事件处理方法中。
昨天我在某个地方看到有人提到那里只应该放最少的代码。
真的吗？或者最佳做法是什么？

例如从程序流畅工作的角度来看，哪个示例更好，以及为什么，如果可以的话：图一：

private void MainForm_DragDrop(object sender, DragEventArgs e)
{
    var DropPosX = e.X;   
    string[] s = (string[])e.Data.GetData(DataFormats.FileDrop, false);    
    for (int i = 0; i < s.Length; i++)
    {
        CheckFile(s[i])
        LoadFile(s[i]);
        // ..big chunk of code..
    }    
    // ..big chunk of code..    
}

图2：

DoDragDrop(int[] s, int DropPosX)
{
    for (int i = 0; i < s.Length; i++)
    {
        CheckFile(s[i])
        LoadFile(s[i]);
        // ..big chunk of code..
    }    
    // ..big chunk of code..
}

private void MainForm_DragDrop(object sender, DragEventArgs e)
{
    var DropPosX = e.X;    
    string[] s = (string[])e.Data.GetData(DataFormats.FileDrop, false);    
    DoDragDrop(s, DropPos);
}

..甚至
图3：

int DropPosX;
string[] s;

DoDragDrop()
{
    for (int i = 0; i < s.Length; i++)
    {
        CheckFile(s[i])
        LoadFile(s[i]);
        // ...
    }    
    // ...
}

private void MainForm_DragDrop(object sender, DragEventArgs e)
{
    DropPosX = e.X;    
    s = (string[])e.Data.GetData(DataFormats.FileDrop, false);    
    DoDragDrop();
}

【问题讨论】：

我认为这个问题在code review stack exchange website 上会更好。
对不起，也许我应该说我不是在寻找特定的代码审查。该代码仅作为示例。 -- 如果你觉得更好，我可以把它改成更简单的伪代码？

标签： c# winforms c#-4.0

【解决方案1】：

大多数事件处理程序基本上采取以下两个操作

从事件中收集相关数据，可能只是事件发生了
使用收集的数据执行操作

听起来那个人建议您将这些逻辑操作分解为 2 个单独的方法。这是合理的推理，但也是风格问题。这样做不会使您的程序或多或少正确。虽然我通常发现如果你采用这种方法，代码更容易测试。

具体到这个示例。在这种情况下，我不会使用实例变量。被拖动的项目和位置与DoDragDrop 方法相关，应该作为参数传递。如果需要保留该数据，则应使用 DoDragDrop 设置实例值。

private void MainForm_DragDrop(object sender, DragEventArgs e)
{
    int position = e.X;    
    string[] items = (string[])e.Data.GetData(DataFormats.FileDrop, false);    
    DoDragDrop(positon, items);
}

【讨论】：

因此，将一大段代码（可能需要一些时间来处理）直接放入事件处理方法中通常没有错？
我完全同意。有时使用单独的方法是有意义的，例如当某些事件将“共享”代码时，然后将该代码放入两个事件都可以调用的单独方法中是有意义的。对我来说，仅仅为了阻止它而将其拆分听起来更像是一个编码风格问题。
@Riva 这些是两个不同的东西。您的事件处理程序是否有大量代码是 100% 的风格问题。我更喜欢紧凑、简短的方法，但这是一种风格选择。长时间运行的事件处理程序很糟糕，因为它们会降低用户体验。如果事件处理程序无法及时响应，则应将工作转移到后台线程
@Riva，如果您预计您的事件处理可能“可能需要一些时间来处理”并且您担心线程阻塞，那么您可能需要考虑移动该代码变成可以异步执行的方法。
我当然同意防止代码重复是正确的、好的和需要的。那不是我问题的真正范围。 - 从我提到的那句话中，我了解到事件处理程序中的长代码以某种方式破坏了程序的“流程”。我知道现在不是这样，谢谢大家！

【解决方案2】：

是的，你应该尽量保持最低限度。

如果说大量代码在大量内部组件（例如表单控件，但您的目标是尽可能多的事件处理程序之外），它可能会变得有点混乱。

一切都取决于大块代码是什么，但即使是本地私有方法也比 eventHandler 中的一大块代码要好。

如果说您正在抓取 UI 属性以将它们存储在另一个类中。向它添加一个方法，将它们作为参数。

如果有很多 UI 内容，请查看 UserControl。

这样做的主要原因是，测试 UI 是一件很痛苦的事情，所以 UI 中的逻辑越少，工作就越容易。

【讨论】：