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]

Цитата:

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?

[kashperuk]

Цитата:

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

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

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

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

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


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

[belugin]

Цитата:

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

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

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

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

[trud]

Цитата:

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

то exception.

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

[belugin]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

[belugin]

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

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

[kashperuk]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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