Показать сообщение отдельно
Старый 25.01.2018, 00:20   #5  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Skolos Посмотреть сообщение
Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?
Тут просто несколько другая парадигма. Для чего мы хотим передать параметр в insert? Чтобы сделать 2 логики, которые будут по-разному отрабатывать при вставке данных в таблицу.

Теперь у нас есть события. Этих событий мы можем наплодить великое множество, гораздо больше, чем 2 варианта. Более того, мы в коде можем управлять последовательностью вызова обработчиков этих событий. Соответственно, теперь каждая логика будет иметь свой обработчик события insert().
Название: SNAG_Program-0024.png
Просмотров: 792

Размер: 15.7 Кб

Тут есть 3 варианта развития. Можно как-то внутри себя договориться и использовать единый обработчик insert-а (один класс) и в нем реализовывать все 100500 вариантов логики. Пример в прошлых версиях - класс InventUpdate и его наследники InventUpd_*. В нашем случае через GlobalCache можно будет создать единый инстанс этого обработчика и следить за этим. Минус такого подхода в том, что должен быть единый и постоянный архитектор, который за этим будет следить. Не все компании считают нужным содержать такого человека.

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

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

Еще маленькое замечание - в целом неважно как "обрастет" код и насколько будет сложно его поддерживать. Конечно есть еще компании, у которых работает AX 3.0, но в большинстве своем жизненный цикл конкретной версии системы не настолько большой (лет 10), поэтому рано или поздно ее все равно будут менять и по сути перевнедрять, т.к. много воды уже утечет с момента первого внедрения. Причем что примечательно, что как раз-таки те компании, которые до сих пор сидят на 3.0 вероятнее всего не имеют и давно уже не имели того единого архитектора, который бы мог все контролировать. Так что плюс-минус неважно насколько "плохим" или "хорошим" со стороны окажется Ваше решение по выбору обходного пути.

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

Последний раз редактировалось sukhanchik; 25.01.2018 в 00:31.