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

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

Цитата:

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

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

И как это поможет преодолеть проблему? Цель - беспроблемная езда. Тот факт, что я знаю из-за чего возникает проблема никак не помогает мне ехать.

Цитата:

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

Идеология системы предусматривает активную работу только с текущим, образно говоря, рабочим набором данных:

Да. И в этом ее недостаток.

1. Системное администрирование чрезвычайно усложняется с ростом базы данных. Банально сделать Backup - крайне сложно.
2. Нерациональное использование дискового пространства. Информация уже не нужна, а место занимает.
3. Значительные проблемы при любой модификации структуры базы данных. Вставить/удалить поле - большая проблема
4. Как уже упоминал Vadik, изменение PK таблиц-справочников также будет выполняться очень долго

Ну, отчеты - это отдельный разговор. Ну, не рассчитана Axapta на так любимые в РФ статистические отчеты. Попытка использования стандартных отчетов/классов приводит к глобальному подвешиванию системы на очень длительный срок.

Цитата:

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

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

Если Вы делаете PK на основании EDT и устанавливаете Relation, то такой пункты меню, как "Перейти к основной таблице" появляется как бы "автоматически". Вы ничего для этого специально не делаете. Вы можете ничего не знать, про факт существования такого пункта меню, но он все равно появится вне зависимости от Вашего знания.

Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией.

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

Цитата:

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

Надеюсь, этот пассаж про смешение презентационной и безнес-логики был лишь стёбом...

Здесь непонимание с обеих сторон. Вы не поняли о чем я говорил, а я не понял какое отношение Ваш пример имеет к моим словам. О чем шла речь я пояснил чуть выше на примере появления пункта меню.

Цитата:

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

Как минимум можно сообщить разработчику абстракции и получить хорошие шансы на то, что дырка будет им вскоре залатана; если разработчик не будет знать о дыре, очень велика вероятность, что проблема так никуда и не денется.Ну как так... вот, к примеру, падает тот же АОС при выполнении определенного кода, или клиент виснет в каких-то ситуациях, или все работает, но на ровном месте памяти отжирается невообразимо много... Пусть проблема в АОСе/клиенте/виндах/еще ком-то - но это же не значит, что ее не надо пытаться решать или хотя бы пытаться смягчить ее проявления? Деньги-то не за то платят, чтобы руки разводить и говорить "я не на том уровне"

Замечательно. Разбираем по пунктам

1. Нашли дырку в абстракции
2. Сообщили разработчику

Наши дальнейшие действия? Сидим, ждем выхода следующего релиза или фикса? И сколько ждать? А программа не работает! А деньги нам за что платят?

Что делает разработчки в этом случае? Ищет пути обхода. На своем уровне. А вовсе не на уровне дырки в абстракции. Тормозит Exists Join? Делаем Inner Join. Базовый класс сжирает всю память? Используем временные таблицы. И т.д. и и.п.

В результате имеем решение проблемы вообще никак не связанное с осознанием причины "дырки в абстракции". Мы просто знаем, что "Ты туда не ходи. Снег башка попадет" (с). Ну, и протаптываем "обходные пути"

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