Kashperuk Ivan: Development tutorial: Extensibility: Replaceable in Chain of Command methods

[trud]

Цитата:

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

Как и возможность наличия расширения.

так а как разработчик должен это учесть? т.е. если вы предлагаете генерить исключение, надо наверное и предлагать механизм обработки этого исключения. если механизма обработки нет, зачем тогда его генерить?
вообще вот отличное описание о "будущем" NAV, странно что для АХ не сделают подобное.
russianerpexperience: Как вендор партнёра услышал, или будет ли Россия в облаке: новости о новейшей системе Dynamics 365 'Tenerife' с Directions EMEA 2017

т.е. решения надо делать на полностью extension и не extension(давая клиенту выбирать)
для "не extension" иметь список перегруженных методов, соответственно додумывая дальше при установке 2 решений которые меняют одно и тоже выдавать конфликт(т.е. не давать ставить вообще если решения конфликтуют и возможности мержить код нет - например нет исходного кода), если возможность мержинга есть то выдавать что мержить - но это правда будет текущая модель работы из 2012

[belugin]

Цитата:

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

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

Учесть так - заменять собой метод только если есть полный контроль над условиями перекрытия. Например, проводка относится к типу который введен вами. (тут, кстати, непонятно как это сделать гарантировано - то есть, если другое расширение будет по какому-то другому независимому признаку определять что именно оно должно перекрыть - надо тогда чтобы была гарантия что пространства параметров не пересекается, то есть у метода должен быть ровно один параметр типа enum).

Мне кажется обработка исключений, кроме нескольких, заключается в том, чтобы прервать текущий процесс и вывести сообщение об ошибке.

Цитата:

т.е. решения надо делать на полностью extension и не extension(давая клиенту выбирать)
для "не extension" иметь список перегруженных методов, соответственно додумывая дальше при установке 2 решений которые меняют одно и тоже выдавать конфликт(т.е. не давать ставить вообще если решения конфликтуют и возможности мержить код нет - например нет исходного кода), если возможность мержинга есть то выдавать что мержить - но это правда будет текущая модель работы из 2012

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