Нужна ли теоретическая подготовка при программировании в Axapta?

[Владимир Максимов]

Есть даже не анекдот, а быль советских времен. Когда ты приходил в институт, то тебе говорили: Забудь то, чему тебя учили в школе. Когда приходил на работу: Забудь то, чему тебя учили в институте. Не знаю, поменялось ли что-нибудь в этом плане сейчас...

Каждый язык программирования, а в особенности FrameWork (чем является Axapta), в своей основе имеют некую идею того, как "правильно" надо программировать. Все конструкции языка "затачиваются" под эту идеологию. К сожалению, я не встречал чтобы кто-нибудь, когда-нибудь, озвучивал эту самую идеологию конкретной среды программирования. Однако ее можно почувствовать по косвенным признакам.

Если разработка происходит как бы "сама по себе". Не успел сказать "А", а среда уже сделала за тебя "Б", "В" и "Г". Значит, программирование идет в согласии с базовой идеей среды разработки. Ты "угадал" то, как "правильно" надо программировать в данной конкретной среде разработки.

Разумеется, есть Best Practices, но это не совсем то. Точнее, это слишком "низкий" уровень абстракции. Нужно подняться чуть выше

Пример. Первичный ключ. Основа основ реляционной базы данных. Какая идея (по моим предположениям) была положена в основу реализации связи PK-FK? Показательным примером может служить цепочка: Шапка заказа - строки заказа - складские проводки.

Идея звучит так: Если Вам нужен первичный ключ, то Вы создаете (!) новое поле и формируете его значение по-умолчанию на основе номерной серии. Пример: SalesId, InventTransId.

Если Вам нужен внешний ключ, исходя из предположения, что таблица может быть связана с несколькими таблицами-родителями, то в качестве идентификатора таблицы-родителя Вы создаете (!) новый Base Enum. Пример: TransType + TransRefId в складских проводках.

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId.

И что имеем в результате? Постоянные матюки и пожелания самых разных "успехов" тем "умникам", которые сделали связку через RecId+TableId. Никаких тебе "автоматических" "плюшек" в виде "перехода к основной таблице", поиска по ключу на форме и т.д. и т.п. Постоянное программирование, программирование и еще раз программирование.

Аналогичная проблема с InvoiceId. Вместо того, чтобы создать новое поле на роль PK, знатоки теории начали наращивать дополнительных поля, чтобы обеспечить хоть какую-нибудь уникальность комплекса полей. Результат все-равно вышел сомнительным. Использовать его сущее мучение...

Ну, хорошо, проектирование баз данных никогда и не была сильным местом программистов. Может, с программным кодом они лучше обращаются?

Смотрим на классы. Насколько я понимаю, предполагалось, что "точкой входа" в любой класс в Axapta должен быть статический метод main(). Это, в свою очередь, предполагает, что при программном вызове класса необходима предварительная подготовка по формированию параметра args. Причем объект args имеет входные параметры в методе new().

А что в результате сделали знатоки "теории"? Про метод main() они узнают только тогда, когда оказывается невозможным привязать класс к пункту меню. Никто и никогда не инициализирует объект args (если вообще про него вспоминают) передавая в метод new() параметры. В общем случае, найти в коде, каким же образом инициализируется и запускается тот или иной класс - это всегда проблема. Каждый разработчик выдумывает что-то свое. Особенное. В соответствии со своим пониманием того, "как правильно".

Знание теории, откровенно мешает "правильному" программированию с точки зрения конкретного FrameWork. "Теоретик" все время пытается сделать "по теории", а не так, как это предполагает конкретный FrameWork. В результате, просто "ломает об колено" среду разработки.

Теория нужна разрабтчикам этого самого FrameWork. Создателям "ядра" системы. Той области, куда программисту доступ просто запрещен. Даже на "посмотреть". Программист имеет дело уже не с теорией, а с неким продуктом, созданным на основе этой теории.

Ну, условно говоря, программист - это водитель автомобиля, а вовсе не механик. Он должен знать правила (приемы) управления автомобилем, а не то, как "расточить гильзы" или "продуть свечи"

[oip]

Цитата:

Сообщение от Владимир Максимов

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId.

И что имеем в результате? Постоянные матюки и пожелания самых разных "успехов" тем "умникам", которые сделали связку через RecId+TableId. Никаких тебе "автоматических" "плюшек" в виде "перехода к основной таблице", поиска по ключу на форме и т.д. и т.п. Постоянное программирование, программирование и еще раз программирование.

В этой связи не могу не вспомнить о axdaily: Surrogate keys in AX 2012. Все течет, все меняется. "Знатоки теории" побеждают.

[Vadik]

Цитата:

Сообщение от oip

"Знатоки теории" побеждают.

Цитата:

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId

Тот кто видел как в терабайтной БД элементы справочников (клиенты, номенклатуры, основные средства) переименуются при работающих пользователях, в выводах не так котегоричен
Хотя наследование таблиц это конечно та еще песня

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

Если разработка происходит как бы "сама по себе". Не успел сказать "А", а среда уже сделала за тебя "Б", "В" и "Г". Значит, программирование идет в согласии с базовой идеей среды разработки. Ты "угадал" то, как "правильно" надо программировать в данной конкретной среде разработки.

Чтобы правильно задать вопрос, нужно знать большую часть ответа, чтобы понимать, сделала ли за тебя среда "Б", "В" и "Г", нужно банально про них знать. Мне в этом плане вспоминается пример с теми же обработчиками изменения полей. Начинающих программистов тянет напихать их на форму, кому-то хватает ума перекрывать modified() на поле datasource'а, а не на контроле - если он, к примеру, слышал про пользовательскую настройку форм и возможность добавления новых контролов, связанных с одним и тем же полем. Следующим шагом идет вынос логики в modifiedField() таблицы - это уже очень большое достижение. Но потом возникает, скажем, задача при изменении определенных полей в шапке пробрасывать их в строки - и там подтягивать связанные значения полей. Хм, это уже интереснее, потому что пробрасываться могут значения сразу нескольких полей; подождите-ка, где-то это уже было... А, в заказах же такое сделано! Сейчас посмотрим, как именно... Опа! а там, оказывается, какие-то непонятные ax-классы с вывернутой наизнанку логикой, и выходит, все потуги выноса кода в modifiedField() таблицы пошли прахом... По-моему, невозможно такое угадать, не может это прийти "само по себе": про такие вещи либо знаешь и заранее готовишься к ним, либо не знаешь и потом "огребаешь" в один прекрасный день, а до того дня среда никак тебе не намекнет, что все на самом деле надо делать по-другому.

Цитата:

Сообщение от Владимир Максимов

Насколько я понимаю, предполагалось, что "точкой входа" в любой класс в Axapta должен быть статический метод main().

По-моему, разработчики Х++ просто слишком увлекались Java

Цитата:

Сообщение от Владимир Максимов

А что в результате сделали знатоки "теории"? Про метод main() они узнают только тогда, когда оказывается невозможным привязать класс к пункту меню.

Точно помню, что в экзамене Development Introduction есть такой вопрос. Если знатоки "теории" не сдавали базовые экзамены, зачем допускать их к разработке?..

Цитата:

Сообщение от Владимир Максимов

Никто и никогда не инициализирует объект args (если вообще про него вспоминают) передавая в метод new() параметры.

Сама по себе идея Args как универсального "транспорта" для передачи (фиксированного перечня) параметров вызываемому объекту приложения имеет свои ограничения, которые наиболее ярко проявляются как раз-таки в классах. Где-то числовые параметры передаются через строковый parm(), а где-то и вовсе через parmObject() передается ссылка на объект со всей необходимой информацией, которую не удалось "запихнуть" в свойства Args. К тому же, для наследников RunBase метод main() традиционно вызывает prompt(), который при вызове класса из кода оказывается ну совсем не кстати, поэтому в коде вызовы main(args) класса скорее - дурной тон (если уж надо что-то интерактивное запустить, для этого есть MenuFunction).

Цитата:

Сообщение от Владимир Максимов

В общем случае, найти в коде, каким же образом инициализируется и запускается тот или иной класс - это всегда проблема. Каждый разработчик выдумывает что-то свое. Особенное. В соответствии со своим пониманием того, "как правильно".

Если разработчик не пренебрегает модификаторами доступа (public/protected/private) и придерживается контрактного подхода, то обычно все не так плохо

Цитата:

Сообщение от Владимир Максимов

условно говоря, программист - это водитель автомобиля, а вовсе не механик. Он должен знать правила (приемы) управления автомобилем, а не то, как "расточить гильзы" или "продуть свечи"

Дырявые абстракции зачастую заставляют "лезть под капот"...