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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.03.2011, 17:07   #19  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
Похоже не было причин для внутреннего использования. только внешние.
Были причины, и чем дальше, тем больше. Когда приложение начинает разрастаться, а потом вдруг нужно добавить какую-нить логику для поля, ранее фактически не использовавшегося, то очень жалеешь, что подобные ax-классам механизмы не использовались ранее, ведь так было бы просто подпилить один класс и, к примеру, автоматом получить заполнение нового поля таблицы в сотне мест, где создаются в ней записи. А из-за того, что прежде годами и ты сам, и люди до тебя, да и разработчики стандартного приложения использовали подход clear/initValue/initFromXX/insert (хорошо еще, если initFromXX, а то бывает и тупое заполнение отдельных полей), получается, что нужно по перекрестным ссылкам все эти места найти, допилить совершенно одинаковым образом (ненавистный copy-paste! ), не ошибиться еще при этом нигде, а потом на каждом новом service pack'е и hotfix rollup'е проделывать эту работу заново. Переделывать же весь такой код на ax-классы - обычно задача просто неподъемная, особенно если существенная часть такого кода - в стандартном приложении.
Или взять тот же подход с классами, завязанными на тип записи: все это прекрасно и чудесно, только непоследовательность губит всю затею на корню. Сколько раз в коде приходилось встречать конструкции вида "если тип такой-то или такой-то, то делаем то-то". Какого ж [censored] было заводить тогда семейство отдельных классов? Надо, допустим, сделать новый тип журнала, во много схожий с уже существующим, а как глянешь по перекрестным ссылам, сколько прямых завязок на этот существующий тип журнала - просто руки опускаются... Вот и с ax-классами также: все в них хорошо (ну... подумаешь, привычная логика заполнения полей вывернута на изнанку), вот только когда "созреваешь" для их использования, то объем модификаций, необходимых, чтобы привести все к "каноническому виду", просто вгоняет в депрессию, и хочется пожелать "всего хорошего" тем твоим предшественникам, которые некогда сэкономили время, поленились нормально написать код, а тебе теперь - отдуваться...
За это сообщение автора поблагодарили: Zabr (4), aidsua (1).
Теги
ax-классы, axbc, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
daxdilip: Whats New in Dynamics AX 2012 (A brief extract from the recently held Tech Conf.) Blog bot DAX Blogs 7 31.01.2011 12:35
semanticax: Dynamics AX 2009 Installation - Application Blog bot DAX Blogs 0 22.12.2010 08:11
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Arijit Basu: AX 2009 - Quick Overview Blog bot DAX Blogs 4 19.05.2008 14:47

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:43.