О рукожо..ах (?). И немножко ER

[axm2017]

В силу того что люди таки начали осваивать ER ( и довольно на удивление успешно, напоминая порой тетенек-бухгалтерш ака виртуозов Excel) приходится анализировать и их неудачи.

Одна из них оказалась связана с отчетом "Sales tax declaration info report for HU":

Кто то талантливый из видимо в MS (в терминах одного самокритичного коллеги работавшего на данную контору - см заголовок) не стал как обычно выводить название в параметры или использовать константы, смог как то обойти кодревью, проверки и втиснуть шедевр в класс SalesTaxDeclarationInformationReportService который как понимаю таки венгерский отчет но без всяких суффиксов.

Благодаря его столь решительному подходу попытки сделать свое в виде derive ов и прочего у консультантов обрекались на неудачу.

/// <summary>
    /// Called by service controller.
    /// </summary>
    /// <param name = "_dataContract">The report parameters.</param>
    [Microsoft.Dynamics.BusinessPlatform.SharedTypes.InternalUseOnlyAttribute]
    public void run(SalesTaxDeclarationInfoReportContract _dataContract)
    {
        dataContract = _dataContract;

        this.processReport();

        this.runER();
    }

    /// <summary>
    /// Called by service controller.
    /// </summary>
    private void runER()
    {
        ERIModelDefinitionParamsAction parameters = new ERModelDefinitionParamsUIActionComposite()
                    .add(
                        new ERModelDefinitionDatabaseContext()
                            .addTemporaryTable(this.getTmpTaxReport()))
                    .add(
                        new ERModelDefinitionDatabaseContext()
                            .addValue(tableNum(CompanyInfo), fieldNum(CompanyInfo, DataArea), curext()))
                   .add(
                        new ERModelDefinitionInputParametersAction()
                            .addParameter('ParameterReportMode', dataContract.parmReportMode()))
                    .add(
                        new ERModelDefinitionInputParametersAction()
                            .addParameter('model/ParameterFromDateRange',dataContract.parmTaxReportPeriodFromDate()))
                   .add(
                        new ERModelDefinitionInputParametersAction()
                            .addParameter('model/ParameterToDateRange', dataContract.parmTaxReportPeriodToDate()));

        // Call ER to generate the report.
        ERFormatMappingTable eRFormatMappingTable;
        select RecId from eRFormatMappingTable where eRFormatMappingTable.Name == "Sales tax declaration info report for HU";
        ERFormatMappingId formatMapping = eRFormatMappingTable.RecId;

        ERObjectsFactory::createFormatMappingRunByFormatMappingId(formatMapping)
            .withFileDestination(ERObjectsFactory::createFileDestinationBrowser())
                .withParameter(parameters)
                        .withCreatingObjectParameter(SalesTaxDeclarationInfoReportContract::parmERModelname(),
                                                     classStr(SalesTaxDeclarationInfoReportContract),
                                                     dataContract).run();
    }

Вопрос в том как это можно безболезненно и с минимумом кода поправить?

[Stitch_MS]

Может, что-то типа этого?

[ExtensionOf(classStr(SalesTaxDeclarationInformationReportService))]
final class SalesTaxDeclarationInformationReportServiceNNN_Extension // <-- new extension
{
    public void run(SalesTaxDeclarationInfoReportContract _dataContract)
    {
        try
        {
            throw Exception::Numeric;

            next run(_dataContract);
        }
        catch (Exception::Numeric)
        {
            dataContract = _dataContract;

            this.processReport();

            this.nnnRunER(); // <- new method
        }
    }

    private void nnnRunER()
    {
        // ...
    }

}

[belugin]

Я бы порекомендовал завести нам багу.

Можно сделать свою копию (copy-on-write, как выражается fed).

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

Еще можно у стандартного мепинга заменить имя на другое где-то (в xml файле или БД) а у кастомного сделать такое, как требует код.

Но это теоретические возможности которые я не могу порекомендовать.

[axm2017]

PS На всякий случай домохозяйкам на заметку в SalesTaxDeclarationInfoItemizedExcel_HU та же фигня (отчет Sales tax declaration info Itemized Excel for HU).

[fed]

Цитата:

Сообщение от belugin

Я бы порекомендовал завести нам багу.

Можно сделать свою копию (copy-on-write, как выражается fed).

Мне тут понадобилось подправить по-мелочи функциональность банковских курсовых разниц. Выяснилось что авторы этого произведения, не только породили код, где на каждый метод заведено по отдельному классу, но и повесили на вообще все классы и методы, которые были созданы в ходе разработки, аттрибут internal и nohook. Так что в итоге мне пришлось copy-on-writeить порядка 25 классов и расширения нескольких таблиц.
Ты там поинтересуйся при случае, не было ли у ваших зарубежных коллег случаев хронической икоты ? А то я вот совсем не понимаю, ЗАЧЕМ было делать такую мелкогранулированную систему, а потом ее же наглухо закрывать от расширений...

[Stitch_MS]

Мне в таких случаях приходилось писать и такое (вместо трех строчек кода):

SysDictClass sysDictClassCredManCreditControl_WHS = SysDictClass::newName(classStr(CredManCreditControl_WHS));

Object creditControl = sysDictClassCredManCreditControl_WHS.callStatic(
	staticMethodStr(CredManCreditControl_WHS, newFromDocumentStatusCheck),
	CredManDocumentStatusCheck::WHSShipment);

sysDictClassCredManCreditControl_WHS.callObject(
	methodStr(CredManCreditControl, parmSalesTable), 
	creditControl, 
	origSalesTable);

checkOK = sysDictClassCredManCreditControl_WHS.callObject(
	methodStr(CredManCreditControl, run), 
	creditControl);

[belugin]

Цитата:

Сообщение от fed

А то я вот совсем не понимаю, ЗАЧЕМ было делать такую мелкогранулированную систему, а потом ее же наглухо закрывать от расширений...

Понятно зачем закрывают для расширений - чтобы не поддерживать точки расширения которые могут быть никому не нужны. Если все-таки нужны, есть возможность сделать extensibility request.

Вот, например, сделали вы метод

public void test(str _arg)

И хочется добавить параметр:

• добавить обязательный параметр - breaking change (может быть вызов из расширения)
• добавить необязательный параметр - breaking change (может быть обернут расширением)
• добавить новый метод с дополнительным параметром можно, но прекратить вызывать старый метод - breaking change (на вызов может быть подписано расширение, котрое перестанет работать)
• можно использовать disposable context, это приемлемо, но ломает рекурсию.

Решения:

• Hookable(false) - если надо чтобы можно было подписаться на метод, то сделать отдельное событие (это не блокирует создание нового метода, вызывающеего то же событие)
• Передавать аргументы при помощи класса (как в дотнете события сделаны XXXEventArgs) - добавление свойства в класс это не breaking change
• Продумывать для каких сценариев нужны расширения, а для каких нет

[trud]

Цитата:

Сообщение от belugin

[*]Передавать аргументы при помощи класса (как в дотнете события сделаны XXXEventArgs) - добавление свойства в класс это не breaking change

Кстати можно еще через временную таблицу передавать(тоже расширяется, плюс можно отобразить в диалоге), довольно удобно получается.
Но это не отменяет замечания что каждый метод создан отдельный класс. Вроде как цель ООП - это упросить сопровождение, а не сделать его более сложным. В последнее время очень много такого кода стало встречаться

[belugin]

Цитата:

Сообщение от trud

Кстати можно еще через временную таблицу передавать(тоже расширяется, плюс можно отобразить в диалоге),

В таблице нельзя делать private поля, поля ссылочного типа и, думаю, что создание записи, это более медленное действие.

Доступ к полям таблицы происходит через конверсию в object - соответственно boxing/unboxing. Так же там есть всякая проверка доступа и т.д.

Цитата:

довольно удобно получается.
Но это не отменяет замечания что каждый метод создан отдельный класс. Вроде как цель ООП - это упросить сопровождение, а не сделать его более сложным. В последнее время очень много такого кода стало встречаться

Я не знаю, зачем там создан класс на метод. И даже не очень понимаю, о каком коде идет речь.

[fed]

Цитата:

Сообщение от belugin

Я не знаю, зачем там создан класс на метод. И даже не очень понимаю, о каком коде идет речь.

Посмотри на классы BankCurrencyReval* и все что с ними связано. Я когда-то эту задачу делал в один класс. Наверное по-хорошему можно было бы там логику класса на 3-4 реструктурировать (с учетом изменений в работе с финансовыми аналитиками в DAX2012). Но Микрософт создал 28 классов BankCurrencyReval*, три класса BankAccount*, добавил около 5-6 методов в разные таблицы и тщательно закрыл все это internal и hookable(false)