Я разработал технику для обработки нескольких подотчетов в отчете rdlc, но, поскольку я пытался сделать его универсальным и повторяемым, мне пришлось вместо этого взять модель и слегка настроить ее для каждого случая.

Например, если я определяю абстрактный интерфейс, например, я просто вырезаю и вставляю его из winform в winform по мере необходимости:

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

Во-первых, я хочу иметь возможность внести это в каждую форму, добавив объект has-a. Я также хочу инкапсулировать поведение обработки отправки делегатом и сделать методы обработки "общий» также.

Итак, требования к дизайну таковы:

Создайте объект, который может быть включен в winform для обработки нескольких вложенных отчетовСоздайте и настройте объект в winformПостройте таблицу диспетчеризации или оператор switch / case в winformПередайте все методы для обработки специфических требований этой winform 'просмотрщик отчетов

ЦЕЛЬ состоит в том, чтобы сделать объект, который можно протестировать отдельно и сделать надежным, а также не нужно резать и вставлять колесо и выполнять кучу ручных настроек для каждой новой формы win.

Мне кажется, что кто-то нашел лучший дизайн, чем тот, который у меня сейчас есть.

Создайте объект, который может быть включен в winform для обработки нескольких вложенных отчетов

Пока у меня есть делегат в локальном событии загрузки форм:

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

который обрабатывается оператором switch в методе * LocalReport_SubreportProcessing *.

Тело метода содержит оператор 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;
            }

В сторону:

По моему мнению, переключатель в основном удобочитаемый для человека по сравнению с альтернативой, которую я рассматривал. Я решил использовать хеш с именем отчета в качестве ключа и данными вызова функции в качестве значения. Однако я не знал, как это сделать, и думал, что кому-то еще будет труднее понять.

После этого вызывается функция, которая переупорядочивает информацию, передаваемую из вызова функции в операторе 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]));
            }

        }
    }

В любом случае, я не хочу повторять одну и ту же логику между отчетами, так как у меня много отчетов с несколькими подотчетами.

Я хотел бы получить качественный способ использования класса для динамического создания промежуточных частей, где происходит заикание, и я хотел бы передать "анонимный» funciton, который фактически реализует подробное подключение подотчета к соответствующему источнику данных.

Что касается одного отчета с вложенными отчетами или даже нескольких разовых отчетов, то все, что я делаю, хорошо, но как сделать его менее ручным, более надежным и более тестируемым?

Моя среда Visual Studio 2008 с целью .NET 3.5; кажется, есть разница в том, как объявляются абстрактные классы и как они компилируются.