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