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

[Blog bot]

Источник: http://kashperuk.blogspot.com/2017/1...ibility_7.html
==============

Recently we announced a new and pretty powerful Extensibility feature, wrapping methods with Chain of Command in augmentation classes. This allows to write much cleaner extensions with fewer lines of code, as well as provides some extra capabilities like access to protected fields and methods of augmented object, easier way of ensuring a single transaction scope for standard and extension code,

Источник: http://kashperuk.blogspot.com/2017/1...ibility_7.html

[ax_mct]

Quote:

Note that by definition that means only one of the ISV solutions can replace it. If two attempt to accept() the result, an error will be shown.
That would typically mean that a logical conflict exists between the two ISV solutions, and the VAR would need to decide which ones to use, or make it configurable somehow.

Интересно. Спасибо.
Я правильно понимаю что проверка конфликта решений ISV не на этапе компиляции, а как runtime error?

[belugin]

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

Я бы запретил вызывать оттуда private члены, например в-общем получается, что это как событие с дефолтным подписчиком, но не событие

[kashperuk]

Quote:

Originally Posted by ax_mct

Интересно. Спасибо.
Я правильно понимаю что проверка конфликта решений ISV не на этапе компиляции, а как runtime error?

Ну, на этапе компиляции и раньше не было. Раньше два ISV могли подписаться на один и тот же метод, и вернуть результат unconditionally.
Это приводило к ситуации "Last man wins" (ну или first man, не суть)

С введением конструктора EventHandlerResult::singleResponse() теперь упадет ошибка, что, мол, попытка повторного вызова - это подобно тому, как это сделано в SysExtension framework

К сожалению, с Replaceable так не получается, то есть опять возвращаемся к First Man Wins - если безусловно не вызывать next() и ваш код вызовется первым, то у остальных не будет шанса, даже если по условиям ваш код ничего бы доп не сделал.


Да и вообще, сосуществование нескольких ISV решений - сложная тема. Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

[kashperuk]

Quote:

Originally Posted by belugin

Я бы запретил вызывать оттуда private члены, например в-общем получается, что это как событие с дефолтным подписчиком, но не событие

Так вроде ж и нет доступа к приватным методам и членам основного класса

[belugin]

Quote:

Originally Posted by kashperuk

Так вроде ж и нет доступа к приватным методам и членам основного класса

Я имел ввиду в заменяемом а не в заменяющем - но потом подумал, что это аналогично protected методу.

[belugin]

Quote:

Originally Posted by kashperuk

Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

Так как это все равно синтаксический сахар для события, сделать дополнительные конструкции для этого:

• Расширение обязано проверить условия при которых оно может заменить метод и вызвать специяльную штуку "Я хоче заменить этот метод", а потом сделать, что ему надо
• Вызываются все расширения, если у двух совпадают желания по замене метода, то exception.

[trud]

Quote:

Originally Posted by belugin

то exception.

Так и что будет делать пользователь с этим exception?

[belugin]

Quote:

Originally Posted by trud

Так и что будет делать пользователь с этим exception?

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

Расширения ISV не должны брать ответсвенности за условия, про которые не знают.

[trud]

Quote:

Originally Posted by belugin

Вообще как с любой другой ошибкой в софте - репортить программеру.

что за программер? ну т.е. я как конечный пользователь ставлю 2 сертифицированных решения из App store - у меня после этого перестает работать стандартный лукап по складам. т.е. по идее это ошибка MS(у разработчиков решений то все работает)
т.е. что должен суппорт MS делать с такой ошибкой?

[belugin]

Quote:

Originally Posted by trud

по идее это ошибка MS(у разработчиков решений то все работает)

То что у разработчика расширения все работает, это не значит что ошибка не его. Например у него может быть локаль EN-US а у пользователя тайская, и он это не учел. Как и возможность наличия расширения.

Я не знаю, как решает такие вопросы саппорт, как и вопросы при любых 3rd party расширениях для всего чего угодно. Наверное должен быть кто-то, кто поддерживает весь комплект в целом. Так же как если у вас антифирус конфликтует с какой-нибудь утилитой вы обращаетесь к сисадмину.

[trud]

Quote:

Originally Posted by belugin

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

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

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

[belugin]

Quote:

Originally Posted by trud

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

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

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

Quote:

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

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

[ax_mct]

Quote:

Originally Posted by kashperuk

Да и вообще, сосуществование нескольких ISV решений - сложная тема. Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

Думаю что решить эту проблему можно только на конечном клиенте. Для этого нужен полный контроль над всем кодом тем кто будет эту проблему решать.

На уровне поставщика платформы задача выглядит решаемой только если ограничить ISV до нескольких и очень тесно с ними работать. Что судя по всему и происходит и что судя по всему и является целью. Что имеет все шансы на успех но с совсем другими партнерами и клиентами.

"Быстро, дешево, много" в части инсталляций - вполне работающий для прибыли для того у кого в руках контроль. Но рынка ISV рынка для D365FOE не будет, будет не больше одного ISV решения для бизнес-процессов на конкретном внедрении вот и все. И то если именно Microsоft будет формально или неформально гарантировать его совместимость.

То есть тесная совместная работа Microsоft с 1-5 ISV и все. Между собой все решат и так я полагаю.