AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.05.2017, 15:20   #1  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
AX2012. Цель атрибутов в расширении наследования классов
Здравствуйте.
У меня возникли чисто теоретические вопросы.
1. Какая цель создания экземпляров классов через расширенные атрибуты
SysExtensionAppClassFactory::getClassFromSysAttribute(
?
2. Чем не устраивает старый дедовский способ construct ?
3. Как при создании экземпляра класса через расширенные атрибуты передать ему параметры в new?

ПС. Я исхожу из принципа, что вызывающий класс и так ВСЕГДА должен знать какого наследника он создает. Зачем тогда городить огород и не вызывать просто создание нужного наследника? Типа свич лишний, давайте загрузим ядро, у него голова большая, пусть думает? Или у нас наследники классов растут как грибы, не успеваем исправлять конструктор, нужно через атрибуты это делать?...
За это сообщение автора поблагодарили: mazzy (2), Logger (1).
Старый 28.05.2017, 16:01   #2  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Как вариант такое обьяснение. Для как бы mapping через metadata, то есть для связки но не трогая код.
Но я конечно не уверен, это так - для темы.
Цитата:
есть у вас класс Point с полями X и Y
class Point
{
public int X {get; set;}
public int Y {get; set;}
}
Вы хотите его сериализовать в JSON. Окей, не вопрос, даже ничего не понадобится. Однако теперь есть проблема, точки нужно отдать в стороннюю библиотеку, где они должны назваться PTXCOORD и PTYCOORD. Естественно, свой код вы захламлять не хотите, у точки есть координаты X и Y, не нужно все эти дебильные прфиксы и суффиксы писать (однако эта библиотека принимает данные только в таком формате. И вот, здравствуйте, атрибуты:

[DataContract]
class Point
{
[DataMember(Name = "PTXCOORD ")]
public int X {get; set;}
[DataMember(Name = "PTYCOORD ")]
public int Y {get; set;}
}
Всё. Ваш код будет работать с нормальными именами, библиотека получит данные в нужном формате, все довольны.

Про WCF я и не говорю, там чуть менее чем всё на атрибуты завязано.
Что такое атрибуты и зачем они? Для чего нужны директивы препроцессора? - C#
http://www.cyberforum.ru/csharp-begi...ad1776997.html
Старый 28.05.2017, 18:43   #3  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
В основном все это для того, чтобы при создании наследников не менять существующий код.
Цитата:
старый дедовский способ construct
Да, способ старый, да он понятен большинству разработчиков. Но этот способ требует изменения уже существующего отлаженного кода для добавления наследника.
Цитата:
передать ему параметры в new
new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет. Кстати и construct с параметрами не рекомендуется к применению с тех же пор.
Цитата:
вызывающий класс и так ВСЕГДА должен знать какого наследника он создает
Достаточно спорное утверждение. Тот же принцип Барбары незабвенной Лисков говорит как раз об обратном - код, использующий какие-то классы из иерархии не должен делать предположение о том, какой именно наследник используется, а наследники класса должны сохранять поведение базового класса.
Старый 28.05.2017, 22:14   #4  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
при создании наследников не менять существующий код
Код в месте, откуда происходит вызов наследников все равно придется менять, так как туда нужно будет передать новый добавленный атрибут для вызова нового наследника.
Шило на мыло. Тут мы добавляем новый атрибут, тут мы добавляем новый пункт свича для создания нужного наследника.

Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
уже существующего отлаженного кода
Правильное добавление наследника никак не может повлиять на существующий код.

Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет. Кстати и construct с параметрами не рекомендуется к применению с тех же пор.
Где в теории ООП написано, что конструктор должен быть без параметров?!
Совершенно не оправданное ограничение МС.
Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры?

Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
..код, использующий какие-то классы из иерархии не должен делать предположение..
Я не говорю о полиморфизме.
Я говорю именно о месте, где производится инициализация объекта нового класса.
В этом месте и в этот момент должно быть однозначно известно, какой наследник будет создан. И что это будет определять - атрибут или свич - совершенно все равно. Вопрос - зачем атрибут, если можно через свич легко и просто?
За это сообщение автора поблагодарили: mazzy (2), Ace of Database (2).
Старый 28.05.2017, 22:20   #5  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
Код в месте, откуда происходит вызов наследников все равно придется менять, так как туда нужно будет передать новый добавленный атрибут для вызова нового наследника.
Нет, не надо будет - надо будет добавить новое значение атрибута и не туда где он вызывается. А, навпример, в BaseEnum.

Цитата:
Я не говорю о полиморфизме.
Я говорю именно о месте, где производится инициализация объекта нового класса.
В этом месте и в этот момент должно быть однозначно известно, какой наследник будет создан. И что это будет определять - атрибут или свич - совершенно все равно. Вопрос - зачем атрибут, если можно через свич легко и просто?
Чтобы при мердже кода не мержить свитч.
Старый 29.05.2017, 03:08   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от ta_and Посмотреть сообщение
Вопрос - зачем атрибут, если можно через свич легко и просто?
Мне думается вот хорошее видео которое объясняет в целом концепцию
Антон Кекс — Как нам спасти Java
https://www.youtube.com/watch?v=TSAlj04_tkA
Вкратце - представьте что вас взяли архитектором в Микрософт. если вы предложите писать все через switch, то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают. Поэтому собственно идет расширение концепций(при чем принцип чем запутаннее, тем лучше).
Вот кстати товарищ Мартин предлагает вообще использовать библиотеку Автофак для подобных вещей
goshoom: IoC containers for extensibility
если он сумеет продвинуть это, то в следующей версии будем разбираться уже с этим
Кстати один из примеров который приводит Антон - это то что на каком то проекте куда они пришли довнедрять было вообще запрещено писать бизнес логику на Джава, все должно быть на SQL. когда начали разбираться откуда пошло это безумное требование, оказалось что если разрешить писать на Джава вещи типа сделать проводку, то получаются конструкции "когда класс создает другой класс чтобы через интерфейс вызвать третий" и т.п. и через некоторое время понять что происходит становится невозможно. SQL этого не позволяется, там собственно всегда можно увидеть что происходит с данными
это кстати вспоминается когда приходится отлаживать что-то из Source Framework в Ах.
За это сообщение автора поблагодарили: Ace of Database (2).
Старый 29.05.2017, 11:52   #7  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от ta_and Посмотреть сообщение
Где в теории ООП написано, что конструктор должен быть без параметров?!
В теории, разумеется, этого нет. Но Axapta - это не "теория". Это "экземпляр" теории Конкретная реализация, которая, разумеется, вводит свои собственные ограничения

Цитата:
Сообщение от ta_and Посмотреть сообщение
Совершенно не оправданное ограничение МС.
Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры?
Оправдано, оправдано. Но! Не "вообще", а в конкретной реализации ООП в системе Axapta. Самый простой пример - пакетные задания (Batch) начинаются с того, что создают экземпляр класса через

classfactory.createClass(classId);

передача параметров здесь не предусмотрена "в принципе". Все "параметры" поднимаются из unpack уже "потом". После инициализации

Разумеется, пакетные задания - отдельный разговор, но, вообще-то, в Axapta довольно много разных обслуживающих процедур, которые требуют создание экземпляра класса для выполнения какого-либо анализа по структуре класса. Если у Вас в метод new передается какой-либо параметр, то есть риск получить Exception в момент создания экземпляра. Как следствие, весь функционал перестает работать

Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов

Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила

Никаких параметров в методах new

Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: mazzy (10).
Старый 29.05.2017, 11:57   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов

Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила

Никаких параметров в методах new

Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать
Ураа!!! ответ по существу!!!!

а давайте вернемся к исходному вопросу?

Цитата:
Сообщение от ta_and Посмотреть сообщение
Здравствуйте.
У меня возникли чисто теоретические вопросы.
1. Какая цель создания экземпляров классов через расширенные атрибуты
SysExtensionAppClassFactory::getClassFromSysAttribute(
?
2. Чем не устраивает старый дедовский способ construct ?
3. Как при создании экземпляра класса через расширенные атрибуты передать ему параметры в new?

ПС. Я исхожу из принципа, что вызывающий класс и так ВСЕГДА должен знать какого наследника он создает. Зачем тогда городить огород и не вызывать просто создание нужного наследника? Типа свич лишний, давайте загрузим ядро, у него голова большая, пусть думает? Или у нас наследники классов растут как грибы, не успеваем исправлять конструктор, нужно через атрибуты это делать?...
Как утверждение "Никаких параметров в методах new"
довести до ответов на исходные вопросы?
__________________
полезное на axForum, github, vk, coub.
Старый 01.06.2017, 14:22   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
И чтобы закрыть темы, прозвучавшие в этой ветке.
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
передача параметров здесь не предусмотрена "в принципе". Все "параметры" поднимаются из unpack уже "потом". После инициализации

...

Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов

Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила

Никаких параметров в методах new

Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать
Нет. По факту это не так. Уж не знаю, к счастью или к сожалению.
И параметры в new вполне предусмотрены (я не знаю почему только 5 параметров),
и сам фреймворк, заменяющий технологию конструкторов, использует конструкторы...
Но пост мне очень понравился.
Поскольку проблема действительно была. Не знаю осталась ли она сейчас. Надо полагать, исправили.

https://www.facebook.com/photosm/pho...type=3&theater
Миниатюры
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 273
Размер:	35.5 Кб
ID:	11458   Нажмите на изображение для увеличения
Название: 2.PNG
Просмотров: 229
Размер:	46.1 Кб
ID:	11459  

__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 01.06.2017 в 14:43.
Старый 01.06.2017, 15:08   #10  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Охренеть. Switch case 1, 2, 3, 4, 5. Наверное когда додумаются передавать массив параметров (array[]) тогда оформят это патентом.
Старый 03.06.2017, 21:11   #11  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от ta_and Посмотреть сообщение
Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры?
Извините, что есть задержка с ответом - сменил место работы и после 15 лет работы в производстве теперь много времени уходит на то, чтобы понять что же такое "ритейл".
Для начала, чтобы не тратить время, определимся что такое конструктор. На мой взгляд, конструктор это то, что создает класс. В Аксе это метод new. Принято создавать статический метод construct, но, несмотря на название это все-таки не конструктор в общем понимании, а метод фабрики.
Пример проблемы параметров в new очень простой (речь про DAX2009, то есть пока про атрибуты даже не вспоминаем).
Создаем наследника RunBaseBatch в котором в new указываем параметры. Если запускаем этот класс через назначенный mtnuitem, то проблем нет. А теперь, представляем ситуацию, когда наш класс администратор хочет включить в пакетное задание в рамках журнала.
Он запускает "Основное \ Запросы \ Пакетное задание. Создает новое задание, переходит в "Просмотр задач", создает новую строку и пытается выбрать класс обработки. И получает ошибку, причем непонятную - я встречал и "тип операнда не соответствует оператору" и "типы несовместимы" и другие и без всякого указания на класс, вызвавший проблему.
На самом деле, даже не нужно создавать свой класс, MS, о нас позаботился и создал два такие класса. Если у Вас есть DAX2009 с Российской локализацией, включающей зарплату, то механизм создания журнала пакетного задания уже сломан из-за использования параметров в new. Пример тут: Создание пакетного задания DAX 2009

Последний раз редактировалось Raven Melancholic; 03.06.2017 в 21:17.
Старый 07.06.2017, 19:58   #12  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет.
Ок, Гугл!! ))
Я все время испытывал ужасный дискомфорт, когда нарушал это правило ВР.
И мне было неудобно перед теми программистами, кто знает ВР и может меня упрекнуть в нарушении этого правила.
И тут... тадам.
SysOperationServiceController
метод
new
!!!
Улыбаемся и машем!
Если кто-то скажет, что это неправильный класс и так нельзя делать, то даже не знаю что и подумать....
-----------------
На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.
В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.
Я не могу себе даже представить такую ситуацию, в которой необходим чистый класс, который на входе не принимает никаких параметров вообще.
Возможно, я ошибаюсь. Можете привести хоть один пример класса, в котором не нужны параметры?...
---------
Может быть выделить это обсуждение в отдельную тему? А то офтопик получается...

Последний раз редактировалось ta_and; 07.06.2017 в 20:10.
За это сообщение автора поблагодарили: Михаил Андреев (5), Pustik (2).
Старый 08.06.2017, 15:16   #13  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.
Почему не AnyType

Цитата:
В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.
Вероятно имеется ввиду, что надо делать protected new и инициализировать параметрами фабричными методами. Чтобы было

Circle::createByCenterAndRadius(p1, r1);
Circle::createByTwoPonts(p1, p2)

А не new Circle(null, 0, p1, p2)

Цитата:
Я не могу себе даже представить такую ситуацию, в которой необходим чистый класс, который на входе не принимает никаких параметров вообще.
Возможно, я ошибаюсь. Можете привести хоть один пример класса, в котором не нужны параметры?...
Какой-нибудь билдер, которому проще надиктовать параметры последовательно.
Старый 09.06.2017, 15:09   #14  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от belugin Посмотреть сообщение
Почему не AnyType
Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
Аргс используется как буфер обмена повсеместно, во всей системе, формы, main, джобы...Это де-факто - параметр по умолчанию. Почему бы его не использовать и для инициализации классов?
Старый 09.06.2017, 15:25   #15  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
А аргс конечно типизирован только там может быть незаполнено что угодно для конкретного класса.

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI. Он содержит UI специфичные параметры, а остальное фактически так же нетипизировано как AnyType
Старый 29.05.2017, 05:02   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ta_and Посмотреть сообщение
Шило на мыло. Тут мы добавляем новый атрибут, тут мы добавляем новый пункт свича для создания нужного наследника.
Угу.

Цитата:
Сообщение от belugin Посмотреть сообщение
Чтобы при мердже кода не мержить свитч.
Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases, все равно придется дописывать документацию, все равно придется обеспечивать совместимость.

Атрибут и свитч - это настолько небольшая часть работы в общем проекте. Но технология атрибутов получилась настолько отличной от остальной работы.

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

Цитата:
Сообщение от trud Посмотреть сообщение
Антон Кекс ... то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают.
Кекс экстремист своего рода )
Хоть и очень толковый. Но он судит людей по себе.

На самом деле все проще.
Как и остальные люди, специалисты в МС хотят сделать лучше, проще, быстрее. Просто "критерии лучшести" в МС сильно отличаются от остальных людей.

Можно много говорить на тему "почему отличаются". Это отдельная тема.

Но как бы то ни было, получаются решения типа советских панельных домов.
Которые получались неудобными для жилья, очень затратными в части отопления, дорогими в части перевозки (панелевоз всегда ездил порожняком со стройки в сторону панельного завода). Но зато сроки строительства минимальны и стоимость производства панелей минимальна за счет массового производства, а удобство-отопление-перевозки не включались расчет при оптимизации.
__________________
полезное на axForum, github, vk, coub.
Старый 29.05.2017, 08:51   #17  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
Угу.
Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases,
все равно придется дописывать документацию, все равно придется обеспечивать совместимость.
См. дальше дискуссия extensions vs overlayering. Скажу только, что можно скономить на легко автоматизируемых вещах время для трудноавтоматизируемых вещей.
Старый 29.05.2017, 08:58   #18  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
См. дальше дискуссия extensions vs overlayering.
)

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

экономия предназначена только для инженеров МС, проявляется только внутри МС и в только на environment МС, в ходе достижения целей, которые существуют только внутри МС.

любое последствие (хорошее или плохое) для других пользователей (клиенты, партнеры) - это скорее всего побочный эффект. причем, скорее всего, незапланированный заранее побочный эффект.
)
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 29.05.2017 в 09:07.
За это сообщение автора поблагодарили: ta_and (3), apanko (3).
Старый 29.05.2017, 09:31   #19  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от mazzy Посмотреть сообщение
экономия предназначена только для инженеров МС, проявляется только внутри МС и в только на environment МС, в ходе достижения целей, которые существуют только внутри МС.
ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.
Старый 29.05.2017, 11:00   #20  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Цитата:
Сообщение от ta_and Посмотреть сообщение
ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.
Цель МС давно известна - сделать разделение кода, так чтобы разработчики клиентов не лезли в её код.
В последующем времени, вероятно, все больше кода будет закрыто и опечатано сей корпорацией.
__________________
// no comments
Теги
sysextension framework, sysoperation framework, как правильно, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stephenmann: Technical History of Dynamics AX - From Axapta 3.0 to AX2012 Blog bot DAX Blogs 5 03.03.2017 10:22
dynamicsax-fico: Invoice search AX2012 vs. AX7 (Part 2) Blog bot DAX Blogs 0 01.04.2016 10:11
DAX2009 аналог friend классов. Как сделать? Raven Melancholic DAX: Программирование 9 07.11.2015 23:50
emeadaxsupport: Inventory closing differences between AX4.0 and AX2012 using weighted average costing method Blog bot DAX Blogs 0 27.12.2012 19:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра
Комбинированный вид Комбинированный вид

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:45.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.