Показать сообщение отдельно
Старый 26.06.2017, 16:10   #179  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?
А почему нет? Если "нет" только потому что это не соответствует ООП и нежеланию копипастить, то да, лучше нашлепать и тупо копипастить общую логику.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Конечно, есть "перекосы на местах", конечно, кое-где выделение общей логики для повторного использования подчас сделано топорно и приносит больше проблем, чем пользы, особенно когда имеешь дело с методами в сотни строк кода. Но не стоит, по-моему, с водой выплескивать и ребенка, заявляя, что все проблемы Аксапты - от ООП.
Проблемы Аксапты не от ООП как полезного инструмента, а от того что что вместо инструмента это стало религией для слишком многих. Любой код и таблицу можно "нормализовывать". Все знают о шести нормальных формах в проектировании БД,
но к сожалению таких четких форм нормальности/достаточности ООП - нет.

Мысль macklakov мне кажется очень интересной.
Цитата:
Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.