|
![]() |
#1 |
Участник
|
re
Простите, что напоминаю, но
Axapta реализована на базе СУБД ORACLE и MS SQL ... как правило .. и как следствие этого просто обязана пользоваться средствами доступа к данным вышеупомянутых СУБД, т.е. SQL, что порождает дополнительные затраты на вычесления (все то же стандартное выполнение произвольного запроса, + предварительный разбор на сервере приложений и формирование соответствующего SQL запроса...) и перекачивание данных - с СУБД на сервер приложений - клиент и обратно ... Причем перекачиваются все данные, относящиеся к базовому отношению определенному в запросе, не важно нужны они, или нет, что естесственно отрицательно сказывается на общем времени реакции системы ... Чтобы в этом убедиться, можно просто открыть так называемый "паспорт записи". То, что средства разработки Axapta предоставляют в качестве классов и прочих дел - не более, чем надстройка представляющая из себя более высокий уровень абстракции для конечного пользователя (разработчика) ... и являющейся схемой метаданных для работы интерпретатора (как я думаю и тому в подтверждение по крайней мере две причины: 1. Формы, процедуры, запросы и т.д. разрабатываются средствами Axapta и создаются непосредственно в Axapta - выполнение запросов на сервере приложений, отображение на клиенте ... 2. Средства выполнения и отладки - это на мой взгляд - ключевой момент, т.к. любая ошибка созданного модуля, запускаемого на уровне ОС может привести к краху этой самой ОС, а возможность отладки - вообще недопустима, т.к. система на это время остановится, в то время, как Axapta допускает возможность вызова системных функций ... правда я так подозреваю - не всех... некий аналог пользовательских типов можно создать cредствами container, но опять же ... представлены не все атомарные типы данных byte, word, dword ... нет, функций для работы с указателями (не в интерпретации X++) и приведения типов данных ... вобщем методов работы с памятью... ) ядра сервера приложений ... И все эти самые средства разработки имеют одну, на мой взгляд основную цель - скрыть от пользователя (разработчика) истинную логическую модель данных в самой СУБД. Кстати ... именно по этому (на мой взгляд) в схеме СУБД не определено ни одного ограничения (кроме NOT NULL) ... вся логика зашита в слои разработчика, к которому естесственно никто не пустит ... ![]() По поводу "программных слоев" - широко разрекламированное, якобы Know How фирмы ... На мой взгляд в этом нет ничего революционного ... Любой программист, пишущий под любую ОС любую программу использует системные вызовы ... чувствуете связь ...? На всякий случай - объясню. Описывая создание на любом языке (Object Pascal [Delphi], C++, VB, Perl и т.д.) например окошка (если например под винды..) компилятор все-равно запрашивает функцию CreateWindow ... а теперь запустите программу под 98 а потом под XP ... даю 101% гарантии, что окошки будут разные по форме ... но функция то осталась та же ... короче есть стандарт, называется API ... так вот это оно и есть ... На самом деле Axapta не такая уж плохая система ... ничем не хуже остальных ... таких же... Имеющая возможность доработки (правда с некоторыми оговорками...) С наилучшими пожеланиями ... |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|