|
30.01.2018, 12:24 | #1 |
Участник
|
Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/
|
|
|
За это сообщение автора поблагодарили: Vadik (1), ax_mct (3). |
30.01.2018, 12:28 | #2 |
Модератор
|
Цитата:
Сообщение от skuull
Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/
__________________
-ТСЯ или -ТЬСЯ ? |
|
30.01.2018, 22:01 | #3 |
Banned
|
Цитата:
Сообщение от 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). |
|
31.01.2018, 10:25 | #4 |
Moderator
|
Цитата:
Похоже что идеологи нового подхода просто не представляли насколько дорого ободится сервисная сторона внедрений, и предпологали что хотя микрософт будет работать напрямую с клиентами, управление мешающимися под ногами партнерами не будет слишком дорого обходится. На практике все конечно оказалось не так, реалистичных бюджетов на управление партнерами и проектами внедрения у MS конечно нету (конечно за исключением тех немногих проектов, которые ведутся MCS). Поэтому эта идея насчет того что микрософт работает с клиентом напрямую на практике потихонечку умирает (просто явочным порядком - поскольку ни у кого в MS нету времени вести наши проекты напрямую и при этом еще как-то нас воспитывать). А MFP просто очень удален от реальности и до него эта интересная информация пока не дошла... |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
31.01.2018, 18:57 | #5 |
Banned
|
Создал тему здесь
Эко-система Microsoft, это как? Последний раз редактировалось sukhanchik; 01.02.2018 в 09:17. |
|
|
|