mfp: Extending class state

[Blog bot]

Источник: https://blogs.msdn.microsoft.com/mfp...g-class-state/
==============
A new and tremendously powerful feature was introduced in the Fall Release ’16. Now you can extend class instances, including adding state. This is available for any class in the system.   We already know we can extend class types. Which in essence allows us to introduce new methods that consumers of the class can...

==============
Источник: https://blogs.msdn.microsoft.com/mfp...g-class-state/

[trud]

Цитата:

Suppose you want to extend the SysUserLogCleanup class. Out-of-the-box this class is deleting records from the SysUserLog table. Let’s imagine you want to archive these records to a different table before they are deleted.

Довольно странный пост. ну да, сделали мы параметр в классе экстеншене, но в исходном run то этот параметр будет недоступен.

[fed]

Мне больше интересно - а нельзя ли такое же, но без статических методов ? Кажется довольно очевидным развитием идеи...

[trud]

Цитата:

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

Мне больше интересно - а нельзя ли такое же, но без статических методов ? Кажется довольно очевидным развитием идеи...

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

[fed]

Цитата:

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

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

Я не наследование предлагаю, просто неплохо было бы чтобы компилятор мог бы вот эти вот статические методы сам неявно создавать в момент генерации CIL. Они ведь при таких раскладах все равно более или менее стандартные - получил параметр, получил this, вызвал нестатический метод.

Ну и к слову сказать - если они там в яммере действительно отнимут возможность overlayering, то считай 90% вертикальных решений с рынка уйдет. Равно как и обычные партнеры начнут в сторону других систем смотреть. А если overlayering не запретят, так проще по старинке все делать чем заморачиваться с extensions.

[trud]

Цитата:

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

А если overlayering не запретят, так проще по старинке все делать чем заморачиваться с extensions.

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

[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 раза больше времени или идти в добрый МС и просить их добавить делегатик попутно обьясняя клиенту что эту хотелку сделать без изменения кода МСом не получиться. Так что осваивать новые танци прийдется в любом случае вне зависимотсти от желания

[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.

[trud]

Цитата:

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

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

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

[S.Kuskov]

Печально. На лицо ограничение достаточной длины верёвки... но закон дырявых абстракций никто не отменял.

"...любой, имеющий в доме ружье,
приравнивается к Курту Кобейну
любой, умеющий читать между строк,
обречен иметь в доме ружье." (c) Сплин

[fed]

Просто если Микрософт хочет действительно выпустить "Облачную автоматически обновляемую ERP без номера версии", то им действительно надо сильно ограничить права партнеров по кастомизациям. Проблема в том, что любой более или менее крупный клиент (а именно на этот рынок Аксапта и позиционируется), без серьезных доработок не внедряется. В принципе.
Так что у Микрософта есть два пути:
1. Продолжать продавливать текущую политику. В этом случае смерть Ax неизбежна. Крупный клиент без возможности доработки систему не купит. А для мелкого клиента облачный Navsion (или как они его там называют) и дешевле и проще. ISV-партнеры умрут; Обычные партнеры перепозиционируются на другие системы ну и т.д.
2. Выпустить on-premise версию, в которой overlayering не запрещен. В этом случае, рынок остается в том же виде в котором он был для Ax 2012. То есть - партнеры и клиенты ставят on-premise версию; Дорабатывают и внедряют ее как раньше; Облачная Аксапта используется только на продажах, прототипирования и тех 5% клиентов, которым серьезные доработки не нужны. Только вот есть подозрение, что в этом случае облачная версия тупо не будет генерировать достаточно выручки чтобы отбить затраты Микрософта на ее поддержку (даже забудем про развитие и доработки).

P.S. Забыл написать что в 1ом сценарии партнеры все-таки могут использовать схему "Copy on write". То есть - любой микрософтовский объект тупо копируется и правиться в копии. После чего стандартные формы и меню тупо скрываются, а новые - выводятся. То есть - в такой ситуации Микрософт только осложнит апргреды, потому что даже старая схема с upgrade wizard перестанет работать...

[Vadik]

Не, брат, с таким настроением ты слона не продашь

[fed]

Кстати - вчитался в What's new and changed in Dynamics 365 For Operation Update 3.
Пишут:

Цитата:

The Dynamics 365 for Operations platform includes the following models:
Application Platform
Application Foundation
Test Essentials
Corresponding form adaptor models
Locking the platform paves the way for seamless servicing and continuous update of the Dynamics 365 for Operations platform.

If you overlay any of the platform models, you will not be able to upgrade to this release. You will need to refactor your code to use metadata and code extensions.

При событиях такого масштаба, я бы ожидал что несколько блоггеров напишут какие-нить постинги в стиле "нам пришел песец" "Обратите внимание - огромнейшее новое преимущество в новой версии!". Но ничего - тишина. И даже те участники форума, которые вроде бы анонсировали свое участие в проектах на семерке скромно промолчали.
Все это очень хорошо говорит о глубине пенетрации рынка новой версией.

[Vadik]

Цитата:

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

И даже те участники форума, которые вроде бы анонсировали свое участие в проектах на семерке скромно промолчали

Участники спокойно, без паники и заламывания рук, за три дня обновились на Update 2, в котором Application Platform залочили. Надо будет - ровно так же обновятся на Update 3 или 1611, благо overlayering-ом не злопотребляют, тем более на системных моделях, и разумно пользуются расширениями

P.S. "Пенетрация рынка"

[skuull]

Цитата:

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

Кстати - вчитался в What's new and changed in Dynamics 365 For Operation Update 3.
Пишут:

При событиях такого масштаба, я бы ожидал что несколько блоггеров напишут какие-нить постинги в стиле "нам пришел песец" "Обратите внимание - огромнейшее новое преимущество в новой версии!". Но ничего - тишина. И даже те участники форума, которые вроде бы анонсировали свое участие в проектах на семерке скромно промолчали.
Все это очень хорошо говорит о глубине пенетрации рынка новой версией.

Так это не новость, еще с бородатых CTP* МС во всю говорил что залочит платформу и фаундейшен, прям документы рассылал как плохо их оверлеить, а потом взял и залочил. И теперь на яммере остались только ISV которые ноют и просят делегаты или еще как перенести свой код который не переносится. У нас были проблемы с багами в платформе которые раньше бы просто взяли и поправили, а теперь пришлось ждать HF.
Ну и еще то что теперь надо иметь два бранча для ISV потому что некоторый стандартный код переехал в другой пакет и соответственно референсы будут разные в апдейте 3 и 2.

[ax_mct]

Цитата:

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

Просто если Микрософт хочет действительно выпустить "Облачную автоматически обновляемую ERP без номера версии", то им действительно надо сильно ограничить права партнеров по кастомизациям. Проблема в том, что любой более или менее крупный клиент (а именно на этот рынок Аксапта и позиционируется), без серьезных доработок не внедряется. В принципе.
Так что у Микрософта есть два пути:
1. Продолжать продавливать текущую политику. В этом случае смерть Ax неизбежна. Крупный клиент без возможности доработки систему не купит. А для мелкого клиента облачный Navsion (или как они его там называют) и дешевле и проще. ISV-партнеры умрут; Обычные партнеры перепозиционируются на другие системы ну и т.д.
2. Выпустить on-premise версию, в которой overlayering не запрещен. В этом случае, рынок остается в том же виде в котором он был для Ax 2012. То есть - партнеры и клиенты ставят on-premise версию; Дорабатывают и внедряют ее как раньше; Облачная Аксапта используется только на продажах, прототипирования и тех 5% клиентов, которым серьезные доработки не нужны. Только вот есть подозрение, что в этом случае облачная версия тупо не будет генерировать достаточно выручки чтобы отбить затраты Микрософта на ее поддержку (даже забудем про развитие и доработки).

P.S. Забыл написать что в 1ом сценарии партнеры все-таки могут использовать схему "Copy on write". То есть - любой микрософтовский объект тупо копируется и правиться в копии. После чего стандартные формы и меню тупо скрываются, а новые - выводятся. То есть - в такой ситуации Микрософт только осложнит апргреды, потому что даже старая схема с upgrade wizard перестанет работать...

Есть третий путь. Единственно разумный и логичный.
Считать AX7 неким форком для Dynamics 365 и более не считать AX; cчитать AX 2012 последней версией и развивать ее далее.

P.S. И лично давно использую форум как свой блог передавая мысль что полярная лисица пришла с AX7