Показать сообщение отдельно
Старый 14.06.2012, 11:54   #34  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,657 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Есть даже не анекдот, а быль советских времен. Когда ты приходил в институт, то тебе говорили: Забудь то, чему тебя учили в школе. Когда приходил на работу: Забудь то, чему тебя учили в институте. Не знаю, поменялось ли что-нибудь в этом плане сейчас...

Каждый язык программирования, а в особенности 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. Создателям "ядра" системы. Той области, куда программисту доступ просто запрещен. Даже на "посмотреть". Программист имеет дело уже не с теорией, а с неким продуктом, созданным на основе этой теории.

Ну, условно говоря, программист - это водитель автомобиля, а вовсе не механик. Он должен знать правила (приемы) управления автомобилем, а не то, как "расточить гильзы" или "продуть свечи"
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Pustik (5), kALVINS (3).