AX2012. Цель атрибутов в расширении наследования классов

[sukhanchik]

Цитата:

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

Прямой вопрос к твоему тексту:
А как "уменьшение трудозатрат МСа" повлияет на число купленных лицензий? Увеличит? Сохранит на прежнем уровне? Уменьшит? Почему?

Никак. А почему должно повлиять?

Цитата:

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

Косвенный вопрос:
dech сказал "Цель МС давно известна - сделать разделение кода"
ты говоришь "Уменьшение трудозатрат ..., технология ... позволяет ему снизить свои издержки"
а "разделение кода" точно позволит МСу "снизить свои издержки"? каков механизм?

))))

Как сказал один умный человек "Не надо искать злого умысла там, где хватает обычного бардака" (с).

Итак, представляем себя на месте МС.
Имеется АХ, которую купили у Навижна. С ней надо чего-то делать. Берем человека с улицы и ставим ему задачу - увеличить прибыль по ней. Спрашиваем этого человека - что для этого нужно сделать и какие проблемы существуют сейчас?
Человек говорит - сейчас имеются большие трудозатраты по апгрейду кода, по слиянию кода - в общем по анализу кода.
Мы видим, что сейчас (мы же все равно выпускаем какие-то обновления) - действительно есть проблема в том, что любое исправление нам нужно сделать в нескольких приложениях, каждое со своим сервис-паком, чтобы выпустить корректный патч.
У нас есть экспертиза в виде Windows/Office и с позиции этой экспертизы - мы видим, что если АХ привести в состояние а-ля офис, то можно будет от нее ожидать максимальных продаж (как офиса).

Как мы понимаем - ничего "по щелчку" не делается и любое достижение цели - это процесс. Поэтому - раз мы один раз поставили себе глобальную цель привести АХ к состоянию Windows/Office - мы к ней плавно идем. Разделение кода - это одно из средств достижения цели.

Достигнет ли разделение кода конечной цели в виде увеличения прибыли - неизвестно. Но ... у нас же есть человек, который поставил понятную цель - привести АХ к Windows/Office. А дальше - это уже его зона ответственности. Если не будет продаж - то ... его можно будет уволить, а направление АХ закрыть, как неудачное

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

Так что совершенно необязательно действия МСа должны влечь за собой сиюминутную прибыль. Вполне вероятно, что они планируют ее увеличить потом в некотором стратегическом будущем и сейчас просто готовят платформу. Глобально - я считаю, что если у МСа уменьшатся внутренние затраты на апгрейды - им это будет проще. Даже если затраты на "оптимизацию" будут выше, чем эффект от результата. Решение все равно принимают люди и одни люди убеждают других людей. Сейчас считается, что текущий путь наиболее оптимальный.

[sukhanchik]

С позиции вендора надо учесть ситуацию наличия большого кол-ва разработчиков, которые между собой не всегда стыкуются. И хотя я не приветствую параметров в методе new, я могу понять разработчиков, которые это делают. Этим они фактически заставляют других разработчиков, которые не знают другой функционал - корректно вызывать и пользоваться объектами АХ.
Например, прогресс-бару нужно кол-во элементов, заголовок и текст. Вот пусть напрягается разработчик и думает, откуда их брать. И не совершает "детских" ошибок

[mazzy]

Цитата:

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

Никак. А почему должно повлиять?

В принципе да, но куда от нас уйти то… )))
Поживем - увидим.

Цитата:

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

Достигнет ли разделение кода конечной цели в виде увеличения прибыли - неизвестно. Но ... у нас же есть человек, который... это уже его зона ответственности. Если не будет продаж - то ... его можно будет уволить, а направление АХ закрыть, как неудачное

Тоже подход )))

[Vadik]

Цитата:

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

Так вот: а почему "не мержить свитч" лучше?

Прекрасный вопрос от человека которому по должности полагается помнить о том что вопрос "мерджить свитч или не мерждить" в недалеком будущем планируется сделать неактуальным, мерджилку отберут и крутись как знаешь (получится или нет - уже отдельная тема)

P.S. а ответ на самом деле дал Максим еще вчера - расширение без изменения предка и оверлееринга

[trud]

Цитата:

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

Цель МС давно известна - заработать.

"Сделать разделение кода" не является (и не может являться) целью корпорации МС )))

ну так и цель разработчиков - тоже заработать. т.е. надо создать такую модель, которая потребует максимальное кол-во ресурсов и будет максимально сложна в поддержке. ну и еще чтоб это все использовало новые технологии, чтобы обновить свое резюме.
т.е. достаточно посмотреть как сделаны экстеншены используя .нет дизассемблер - это отдельный набор классов на каждый тип(т.е. есть AxTable и AxTableExtension) - т.е. простым введением концепции трудоемкость поддержки AOT увеличилась вдвое

[mazzy]

Цитата:

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

Прекрасный вопрос от человека которому по должности полагается помнить о том что вопрос "мерджить свитч или не мерждить" в недалеком будущем планируется сделать неактуальным

именно! именно от такого человека.
и вопрос вовсе не означает, что человек не знает ответа.
знание ответа вовсе не означает, что человек не надеется узнать что-то новое.

Цитата:

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

P.S. а ответ на самом деле дал Максим еще вчера - расширение без изменения предка и оверлееринга

Прекрасно.

продолжим?
Так вот: а почему "расширение без изменения предка и оверлееринга" лучше?

[belugin]

makeObject вполне себе принимает параметры. Можно сделать фреймворк которые их ипользует. Тольпко при этом их надо будет обязательно задать заранее - то есть не подойдет - создать объект и сделать unpack - надо откуда-то брать параметры.

См, также http://picocontainer.com/constructor-injection.html

[trud]

А чем кстати плох вызов делегата в construct со всеми параметрами, соответствено если кому нужно может подписаться?

[EVGL]

Цитата:

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

продолжим?
Так вот: а почему "расширение без изменения предка и оверлееринга" лучше?

У меня есть встречный, не менее глубокий вопрос: по стене ползет, пятью ногами дрыгает. Кто это?
P.S. Сорри, должен был открыть для этого новую тему.

[mazzy]

Цитата:

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

У меня есть встречный, не менее глубокий вопрос: по стене ползет, пятью ногами дрыгает. Кто это?

в общем, ушел от ответа.

впрочем, каждый выполнить технику Пять почему в качестве самостоятельного упражнения.
Результат моего поиска первопричины при помощи этой техники я изложил здесь.

[belugin]

Цитата:

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

А чем кстати плох вызов делегата в construct со всеми параметрами, соответствено если кому нужно может подписаться?

1. Вместо того, чтобы просто пометить класс ключом надо будет писать код с XppPrePostArgs
2. Классы статически помечены ключом и можно проанализовать статически что они друг другу не противоречат - иначе придется анализировать код конструкторов
3. Понятно из кода, что реализуется паттерн "расширение"
4. Нельзя прокешровать зависимость ключ -> класс (виг знает, может в обработчике используется фаза луны)

[mazzy]

какие преимуществ получат разработчики партнеров и клиентов от этих возможностей?

[ax_mct]

Цитата:

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

Какая цель создания экземпляров классов через расширенные атрибуты
SysExtensionAppClassFactory::getClassFromSysAttribute(

Использование данного метода описано в книге Inside Microsoft Dynamics AX 2012
как часть паттерна расширения The extension framework. Для отсутствия связанности между приложением и его расширениями.
Используется class attribute framework как часть этого паттерна.
Ищется класс помеченный данным аттрибутом.

Да, телодвижений для программиста не меньше. Но наличие подобного подхода - оправданно.
P.S. По сути мы отвязываемся от имени класса. Наш атрибут как внешнее имя. Это очень хорошо на самом деле для расширения.

[ta_and]

Цитата:

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

Для отсутствия связанности

Спасибо.
Все понятно.
Это расширение сделано исключительно для того, чтобы не трогать базовый класс при добавлении наследника. Т.е. вся эта архитектура, дополнительные классы, дополнительная нагрузка на сервер, кэши и прочая байда исключительно для того, чтобы МС мог безопасно закрыть свои базовые классы. Цель понятна.
Выводы:
1. Для стороннего разработчика (не МС) эта технология создает исключительно дополнительные (и не спорьте) трудозатраты.
2. При разработке своих классов лучше продолжать использовать старый добрый свич для простоты поддержки, понятности и прозрачности.

ПС. Сейчас у меня стоит задача разработки сложной структуры классов и мне хотелось услышать мнение сообщества по поводу необходимости использования данной технологии. Я услышал. Еще раз спасибо.

[ax_mct]

Цитата:

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

Выводы:
1. Для стороннего разработчика (не МС) эта технология создает исключительно дополнительные (и не спорьте) трудозатраты.
2. При разработке своих классов лучше продолжать использовать старый добрый свич для простоты поддержки, понятности и прозрачности.

От версии.
Если это AX7 или существуют планы портировать на AX7, то старый добрый свитч - не хорошо. Если это AX2009, AX2012 - то пожалуй да, усложнять без необходимости нет смысла.

Development tutorial: SysExtension framework in factory methods where the constructor requires one or more arguments
http://kashperuk.blogspot.co.uk/2017...extension.html

At the Dynamics 365 for Operations Technical Conference earlier this week, Microsoft announced its plans around overlayering going forward.
The direct impact of this change is that we should stop using certain patterns when writing new X++ code.
Pattern to avoid
One of these patterns is the implementation of factory methods through a switch block, where depending on an enumeration value (another typical example is table ID) the corresponding sub-class is returned.

[mazzy]

спасибо )

Что мог бы сделать вендор: Extension Methods.

c# https://docs.microsoft.com/en-us/dot...ension-methods
Котлин https://kotlinlang.org/docs/reference/extensions.html

Вот это был бы настоящий и очень хороший extension.
Но вендор решил иначе.

[belugin]

Extension methods есть в Ax7 и они тут ни при чем. Это просто синтаксический сахар для вызова статических методов. Есть даже подобие companion objects в котлине

[mazzy]

именно!
синтаксический сахар.
именно для вызова статических методов.

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

Цитата:

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

и они тут ни при чем.

?!

как скажешь. бог с тобой.

[belugin]

Цитата:

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

я имел в виду "мог бы сделать Extension Methods вместо атрибутов для создания экземпляров классов".

Они никак не помогут в деле создания extensions - куда вставлять их вызов

[mazzy]

Вместо безумной конструкции
SysExtensionAppClassFactory::getClassFromSysAttribute

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

Насыпать сахара, который предоставлял бы дефолтное поведение по-умолчанию.

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