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

[Vadik]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

Прекрасно.

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

[EVGL]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

[S.Kuskov]

mfp: SysExtension Framework – to the rescue

[mazzy]

а также доп.вопросы к SysExtension framework:
Kashperuk Ivan: Development tutorial: SysExtension framework in factory methods where the constructor requires one or more arguments

[mazzy]

Давайте отвечу публично:
Нет, это не придирки к русскому языку и правописанию.

Допустим, что в утверждении подразумевался не МС, а некие мифические "разработчики МС".
Тогда получается утверждение "Цель разработчиков МС давно известна - сделать разделение кода".
Но при этом утверждение, что "цель корпорации МС - заработать" остается верным.

Отсюда тривиальный вопрос - а как выполнение цели этих мифических разработчиков МС позволит выполнить цель корпорации МС? каков механизм?

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

[sukhanchik]

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

[mazzy]

Логично, чё!

Цитата:

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

Уменьшение трудозатрат МСа при выпуске новых версий даст возможность уменьшить расходы.

Предположим )))

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

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

))))

В общем, ребяты, давайте тщательнее. Пожалуйста.

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

))))

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

[mazzy]

да, рекомендация "Никаких параметров в методах new" хороша с точки зрения партнера и клиента. но рискну задать вопрос с позиции вендора.

да, classfactory.createClass() и DictClass.makeObject() используется дофига где.
существуют ли на ваш взгляд более оптимальные (для всех причастных к аксапте) решения нежели "Никаких параметров в методах new"?

[sukhanchik]

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

[belugin]

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

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

[trud]

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

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