C# 按钮点击事件的编码标准

C# 按钮点击事件的编码标准,c#,coding-style,idioms,solid-principles,C#,Coding Style,Idioms,Solid Principles,在将代码附加到默认按钮单击事件时,我试图遵循良好的编码标准。两个选项是:在单击事件处理程序中包含几行代码或包含一个最终执行与这些代码行相同操作的方法 软件设计原则是什么,或者为什么我会使用这种或那种方法的具体原因是什么 [此外,它是一个现有的标准winforms应用程序,只是扩展了一点。] 选项A: private void btnExport_Click(object sender, EventArgs e) { var FileName = getFileName(reportPre

在将代码附加到默认按钮单击事件时,我试图遵循良好的编码标准。两个选项是:在单击事件处理程序中包含几行代码或包含一个最终执行与这些代码行相同操作的方法

软件设计原则是什么,或者为什么我会使用这种或那种方法的具体原因是什么

[此外,它是一个现有的标准winforms应用程序,只是扩展了一点。]

选项A:

private void btnExport_Click(object sender, EventArgs e)
{
    var FileName = getFileName(reportPrefix);

    if (fileName == null)            
    {
        return;
    }

    SaveFile(fileName, QueryString);
}
选项B:

private void btnExport_Click(object sender, EventArgs e)
{
    DoExport();           
}


private void DoExport()
{
    var FileName = getFileName(reportPrefix);

    if (fileName == null)            
    {
        return;
    }

    SaveFile(fileName, QueryString);

}

出于以下原因,我将推荐方案B:

  • 关注点分离:处理事件(EventHandler)或委托的代码与执行实际工作的实际实现逻辑分离,并封装在另一个方法中

  • 方法
    DoExport
    的意图从名称上看是清楚的。如果有人读了你的代码,它会被解释为

    选项B:“单击按钮时进行导出。”
    选项A:“单击按钮时,如果文件名为 清空然后返回,否则保存文件。“

    哪个听起来更容易阅读?为了便于阅读,选项B提供了一种清晰简洁的方式来表达您的意图

  • 如果您决定将
    按钮更改为另一个控件,如anchor、linkButton、Label或任何其他控件,则无需将事件处理程序与实现细节绑定。像
    DoExport
    方法一样,不应该依赖
    EventArgs'或
    sender`对象

  • 将来,需要从代码中的其他位置调用导出功能(
    DoExport
    )。然后,您可以轻松调用
    DoExport
    方法

  • 测试:如果您将此方法作为公共方法并希望测试它。测试方法比编写代码来引发事件然后测试功能要容易得多


  • 两者都不是,但B比A更接近:

    SRP(单一责任原则)建议您将业务逻辑与UI分离,不仅在方法级别,而且至少在类级别(命名空间和/或库级别分离也可能有用)。这是因为UI可能独立于导出逻辑的更改而更改

    包含
    btnExport\u Click
    的UI类负责驱动UI,向用户显示数据,并将用户交互(如单击)路由回业务逻辑

    而另一个类,最好是在抽象后面,接口是理想的(DIP,依赖倒置原则),负责导出:

    public class YouUIClass
    {
        IExporter exporter;
    
        private void btnExport_Click(object sender, EventArgs e)
        {
            var fileName = GetFileName(reportPrefix);
    
            if (fileName == null)            
            {
                return;
            }
            exporter.DoExport(fileName);           
        }
    }
    
    public class Exporter : IExporter
    {
        public void DoExport(string fileName)
        {
            SaveFile(fileName, queryString);
        }
    }
    
    (您可能需要从UI向导出器方法传递一些参数,如
    filename
    queryString
    ,正如我所演示的,因为我假设
    GetFileName
    是UI)

    一个巨大的优势是您可以测试业务逻辑,而无需涉及UI。然后,手动测试只是检查UI是否将事件正确地转发到后续层


    当以这种方式解耦UI时,有一些模式可以遵循这种方法,而不是使用自己的模式,如MVC、MVP和MVVM。

    如果需要在多个位置使用
    DoExport
    ,那么选项B更有意义。使用MVVM并绑定到viewmodel上的命令。OP提到他在使用WPF吗?@BackDoorNoBaby他没有提到任何技术。wpf或winforms。但我确实提到了坚实的原则,我假设wpf或某种winforms中可用的mvvm模式。这是一个旧的winforms应用程序,没有任何选项引入wpf或任何web技术。每个人都在填补知识空白。:)当然可以:)我建议你用Bob叔叔的一些内容来填补一些空白: