委托如何使用通用且可扩展的类响应多个事件？

我已经设计了一种技术来处理 rdlc 报告中的多个子报告，但当我试图使其通用且可重复时，我不得不采用该模型并针对每种情况稍微调整它。

例如，如果我定义一个抽象接口，像这样，我只需根据需要将其从 winform 剪切并粘贴到 winform ：

abstract class ISolutionStrategy
{
    public abstract void AlgorithmInterface(Int64 searchCriteria, SubreportProcessingEventArgs e);
}

首先，我希望能够通过包含一个 has-a 对象将其带入每种形式。我还想封装委托处理分派的行为，并使处理方法也成为“通用”。

那么，设计要求是：

• 创建一个可以包含在winform中的对象来处理多个子报表处理
• 在winform中实例化并配置对象
• 在winform中构建调度表或switch/case语句
• 传入所有方法来处理该 winforms 报表查看器的特定要求

目标是制作一个可以独立测试并坚固耐用的对象，而且不必剪切和粘贴轮子，也不必为每个新的 winform 进行大量手动调整。

在我看来，有人找到了比我目前拥有的更好的设计。

创建一个可以包含在winform中的对象来处理多个子报表处理

到目前为止，我在本地表单加载事件中有一个委托：

this.reportViewer1.LocalReport.SubreportProcessing += new SubreportProcessingEventHandler(LocalReport_SubreportProcessing);

这是由 *LocalReport_SubreportProcessing* 方法中的 switch 语句处理的。

该方法的主体包含一个 switch 语句：

void LocalReport_SubreportProcessing(object sender, SubreportProcessingEventArgs e)

        {
            String commonSubreportKey = _commonSubreportKey;

            switch (e.ReportPath)
            {
                case "rptSubAlternateParts":
                    runSubAlternatePart(e, commonSubreportKey, new GetAlternateParts());
                    break;
                case "rptSubGetAssemblies":
                    runSubFailurePart(e, commonSubreportKey, new GetAssemblies());
                    break;
                case "rptSubGetAssemblies":
                    runSubGetGetEndItemLRMFailureInfo(e, commonSubreportKey, new GetEndItemLRMFailureInfo());
                    break;
                case "rptSubGetAssemblies":
                    runSubGetSubAssemblies(e, commonSubreportKey, new GetSubAssemblies());
                    break;
                default:
                    break;
            }

Aside:

在我看来，与 我考虑过的替代方案。我考虑过在报告中使用哈希 名称作为键，函数调用数据作为值。但是，我 真的不知道该怎么做，我认为这会更难 别人来理解。

之后，调用一个函数，重新排列 switch 语句中从函数调用传递的信息：

    private static void runSubAlternatePart(SubreportProcessingEventArgs e1, String  commonReportKey, GetAlternatePart myAP)
            {
                myAP.AlgorithmInterface(commonReportKey, e1);
            }

这种重新安排肯定是代码口吃，但对于我试图实现的策略模式来说似乎是必要的中间：

     abstract class IStrategy
        {
            public abstract void AlgorithmInterface(String searchParam, SubreportProcessingEventArgs e);

        }

以下是其中一份报告的战略具体实施情况：

class GetAlternatePart : IStrategy
{
private BLL.AlternatePartBLL ds = new BLL.AlternatePartBLL();


public override void AlgorithmInterface(String searchParam, SubreportProcessingEventArgs e)
              {

                    e.DataSources.Clear();
                    DataTable myDataTable = ds.GetAlternativePart(searchParam);
                    DataSet myDataSet = new DataSet();
                    myDataSet.Tables.Add(myDataTable);
                e.DataSources.Add(new ReportDataSource("BLL_AlternatePartBLL", myDataSet.Tables[0]));
            }

        }
    }

无论如何，我的愿望是不必在报告之间重复手动连接相同的逻辑，因为我有许多带有多个子报告的报告。

我想要一种库质量的方式，使用类来动态创建发生口吃的中间部分，并且我想传递一个“匿名”函数，它实际上实现了子报表与其相应数据源的详细连接。

对于带有子报表的单个报表，甚至几个一次性报表，我所做的都是可以的，但是如何才能使其更少的手动、更健壮且更可测试呢？

我的环境是 Visual Studio 2008，目标是 .NET 3.5；抽象类的声明方式和编译方式似乎有所不同。

我建议的解决方案是对基类进行非常简单的重构，它将您需要在每个 WinForm 中编写的代码减少为两件事：1）用于该表单的报表的设置； 2) 定义如何获取该表单的报告数据。

假设每个 WinForm 都继承自一个名为 ReportForm 的基类，则每个 WinForm 的代码将如下所示：

public partial class Form1 : ReportForm
{
    public Form1()
    {
        // Wire up the report used by the Visual Studio-designed report viewer to the base class
        base.WinFormReport = reportViewer1.LocalReport;

        InitializeComponent();
    }

    // The search parameters will be different for every winform, and will presumably
    //  come from some winform UI elements on that form, e.g., parentPartTextBox.Text
    protected override DataResult GetReportData(SubreportProcessingEventArgs e)
    {
        // Return the data result, which contains a data table and a label which will be
        //  passed to the report data source
        // You could use DataSet in DataResult instead of DataTable if needed
        switch (e.ReportPath)
        {
            case "rptSubAlternateParts":
                return new DataResult(
                    new BLL.AlternatePartBLL().GetAlternativePart(parentPartTextBox.Text)
                    , "BLL_AlternatePartBLL"
                );

            case "rptSubGetAssemblies":
                return new DataResult(
                    new BLL.SubAssemblyBLL().GetSubAssemblies(someOtherTextBox.Text)
                    , "BLL_SubAssemblyBLL"
                );

            default:
                throw new NotImplementedException(string.Format("Subreport {0} is not implemented", e.ReportPath));

        }
    }
                                .
                                .
                                .

上面的代码做了这些事情：

1) 告诉基类(ReportForm) Form 中使用了哪个Report。如果您愿意，您也可以将 Report 重构为 ReportForm，但我的方法仍然允许您在 Visual Studio 中创建和操作 ReportViewer 及其报表。但是，如果您以编程方式传递报表而不是在设计器中，则可能需要将报表从派生的 WinForm 类发送到基类中。

2) 定义报表如何获取其所有子报表的数据。为此，我们只需要返回一个数据表和一个标签，因为这就是报表数据源最终需要的全部内容。将 DataTable 和标签绑定到 RDLC 数据源的代码属于基类 (ReportForm)，因为该绑定代码对于所有 WinForms 都是通用的。

现在，ReportForm 代码应如下所示：

/// <summary>
/// Don't cut & paste into any Windows Forms, inherit the behavior you want from a base class
/// </summary>
public abstract class ReportForm : System.Windows.Forms.Form
{
    // I'm not sure exactly what this is used for, but I put it in base class in case there is some use for it here
    protected string _commonSubreportKey = "12345";

    // This will be the one line of code needed in each WinForm--providing the base class a reference
    //  to the report, so it has access to the SubreportProcessing event
    protected Report WinFormReport { get; set; }

    // Making this abstract requires each derived WinForm to implement GetReportData--foolproof!
    protected abstract DataResult GetReportData(SubreportProcessingEventArgs e);

    // Wire up the subreport_processing handler when any WinForm loads
    // You could override this in derived WinForms classes if you need different behavior for some WinForms,
    //  but I would bet this default behavior will serve well in most or all cases
    protected virtual void Form1_Load(object sender, EventArgs e)
    {
        Report.SubreportProcessing += new SubreportProcessingEventHandler(LocalReport_SubreportProcessing);
    }

    // When the Subreport processing event fires, handle it here
    // You could also override this method in a derived class if need be
    protected virtual void LocalReport_SubreportProcessing(object sender, SubreportProcessingEventArgs e)
    {
        // Get the data needed for the subreport
        DataResult dataResult = this.GetReportData(e);

        e.DataSources.Clear();
        e.DataSources.Add(new ReportDataSource(dataResult.Label, dataResult.Table));
    }
}

请注意，ReportForm 基类继承自 Form，然后所有 WinForm 都将继承自 ReportForm——这是整个设计的关键。下面是这个 ReportForm 基类的工作原理：

1）当实例化WinForm时，设置了基本属性WinFormReport，因此基本对象知道正在使用哪个Report。

2）当WinForm加载时，Form Load事件在基类上被调用，因为它没有在派生类中定义。加载表单时，将连接报表的 Subreport_Processing 事件。

3) 当用户输入参数并单击某些内容以在报表查看器中创建报表时，最终子报表将由 RDLC 实例化，并且 Subreport_Processing 事件会多次触发，每个子报表触发一次。

4) 当事件触发时，基类事件处理程序调用 GetReportData(e)，这将调用 WinForm 上定义的 GetReportData 方法。注意，该方法在基类中是抽象的，因此不能在基类上定义，而必须在派生类中定义。

5) WinForm 中的 GetReportData(e) 方法使用您最初指定的调度程序逻辑，将 DataTable（如果需要，也可以是 DataSet）和文本字符串返回到基本处理程序。

6) 基本处理程序获取 DataTable/DataSet 和文本字符串，将它们作为报告数据源提供给报告，并且还可以执行显示报告所需的任何其他操作。

经过深思熟虑，我决定建议将常见行为相当简单地重构为基类，因为我认为它可以满足您的要求，并且我没有看到哪里需要更复杂的东西。我认为您会发现这种方法非常可读，它绝对最小化了每个新 WinForm 中所需的内容，最重要的是，发现它具有极强的可扩展性；也就是说，当您继续开发系统时，您总是会问“这个新代码是否需要在每个 WinForm 中重复，或者是否很常见，因此应该进入基类？”

如果您对此方法有任何疑问或疑虑，请随时添加评论，祝您好运。我希望这正是您正在寻找的！