D365 как правильно переопределить метод в таблице.

[ax_mct]

Цитата:

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

Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/

Очень по теме статья для автора темы.

Как обычно самое интересное в комментариях.
1. Конечный клиент это клиент компании Microsoft.
2. Microsoft работает с конечными клиентами напрямую.
3. Цель Microsoft - обновлять систему технически и функционально когда и как он захочет.
4. Ответственность за совместимость на вас как ISV, Партнера или клиента.

Вы все еще хотите переопределять метод в таблице D365FoE в чужом приложении для чужого клиента?

Главное это понять парадигму "the ‘open-close’ paradigm .. Open for extensions, closed for modifications".
Это главнее чем нахождение форточки. И об этой парадигме как-то все молчат, а в ней вся соль.

Цитата:

Michael Fruergaard Pontoppidan
January 19, 2018 at 8:10 am
Thanks Dick.

The overall goal of extensibility is to get our shared customer running on the latest release always. This means that extra care and attention to writing robust extensions are required. Significantly more care than when customizing via overlayering. Ultimately; we want to be able to do a binary replace of AppSuite – and everything still works.

The AX extensibility model is quite powerful – too powerful in some cases. When using this toolbox, you are responsible for building a solution that can “survive” an AppSuite upgrade as-is. Any brittleness you build in, like dependencies on call stack, extensions to methods that are not coherent with the standard method will cause disruption to our customers. One example of the latter is to change the global company context in an extension method. We trust you to make strong, durable and lasting solutions.

I agree there is a turn-around time on extension requests; which can be obstructive to development. The sooner you log them the sooner you’ll get them; plan for this delay.

Regarding option 2: The state is class instance specific – not global. There are cases where the state is coherent with the class and its purpose. Here I would not have concerns.
Regarding option 3: You should really use IDisposable, like outlined, instead of guids and potentially stale caches.
Regarding delegates: Chain-of-command is large replacing the need for delegates (and requests for adding these).