mfp: Extending class state

[fed]

Во первых - процентов 70 моих личных доработок меняют базовую логику. И в extension их просто не засунуть. Во вторых - по моим ощущениям (могу быть неправ - на 7ке не работал, только баловался), разработка через extension требует эдак разика в два-три больше времени чем разработка через overlayering. При объявлении тендера, вряд ли клиент впишет использование extensions в условия контракта. Если даже и впишет, то в самых первых результатах анализа ему партнер сообщит что:
1. Из за отсутствия базового функционала;
2. Плохой адаптации старых классов к новому замечательному механизму extensions;
использование только extensions не представляется возможным (хотя конечно клиент может отказаться от 80% своих существующих бизнес-процессов с целью обойтись только extensions -мы всегда за использование стандарта).После чего тому же клиенту сообщат что даже в тех случаях, где можно было бы обойтись одними extensions, их использование поднимет трудозатраты в 2-3 раза. После этого - клиент примет решение использовать overlayering и будет просто множить результаты аудита на ноль.
Собственно - вот сейчас есть best practice от Микрософт, который рекомендует не устанавливать отладочный режим в Production AOS. Тем не менее - 90% клиентов эту рекомендацию игнорируют. Просто потому что возможность быстро диагностировать и починить проблемы в production с лихвой перекрывает потенциальный негатив от включенного режима отладки. Хотя при любом healthcheck Микрософтовский PFE включит в отчет рекомендацию отключить эту галочку.
P.S. Ах да - забыл упомянуть что перед доработками и сейчас обычно напоминают клиенту о проблемах с обновлениями и тд и тп. И уже сейчас (равно как и последние 16 лет), любой клиент легко игнорирует эту проблему, потому что жить без обновлений ему намного менее страшно чем жить без своих бизнес-процессов...
P.P.S. Обобщая - в большинстве случаев, выбирая между непонятными пропущенными обновлениями в непонятном будущем и пропущенными бизнес-процессами в понятном настоящем, клиент выберет эти самые бизнес-процессы, а не обновления и best practice...

[skuull]

Цитата:

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

Во первых - процентов 70 моих личных доработок меняют базовую логику. И в extension их просто не засунуть...

А если этот пакет не позволяет overlay то прийдется взять и засунуть, потратив на это в 2-3 раза больше времени или идти в добрый МС и просить их добавить делегатик попутно обьясняя клиенту что эту хотелку сделать без изменения кода МСом не получиться. Так что осваивать новые танци прийдется в любом случае вне зависимотсти от желания

[trud]

Цитата:

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

А если этот пакет не позволяет overlay то прийдется взять и засунуть, потратив на это в 2-3 раза больше времени или идти в добрый МС и просить их добавить делегатик попутно обьясняя клиенту что эту хотелку сделать без изменения кода МСом не получиться.

Не знаю как там с Application Foundation, но с предложениями добавить делегатик в Application Suite который может поменять стандартную функциональность(доп проверку там добавить или подобное) Микрософт сразу посылает(у нас закрыли 2 подобных запроса из 13 запрашиваемых). т.е. я как понял у них текущее правило - любой добавляемый делегат не должен никак влиять на стандарт, если потенциально может повлиять, в сад. просто добавить там вызов в начале или конце метода - это да, добавляют

[b_nosoff]

Цитата:

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

Во первых - процентов 70 моих личных доработок меняют базовую логику. И в extension их просто не засунуть.

Плохие новости для вас - модель Application Foundation нельзя оверлейерить начиная с Update 2

Цитата:

Extensibility features are key features of the Dynamics AX platform because the Application Platform and Test Essentials models cannot be customized (over-layered) in the August 2016 release. Also, if you customize elements in the Application Foundation model, you will get warnings as this model is scheduled to be locked from customizations in the next Dynamics AX platform update.