опять 1C: чисто технические аспекты...

[ushastik]

Здрасти всем. Я совсем чайник по Аксапте, кое-что щупал в 1C, а вообще
программер из другой области
Читаю доку по Аксапте и не могу отделаться от ощущения того, что система
примитивна. Не поворачивается язык назвать ее предметно-ориенитрованной
средой. RAD-среда общего назначения. То есть ничего плохого сказать не хочу,
все очень продуманно и технически грамотно, но с таким же успехом можно
ERP-платформой назвать связку Oracle + Forms, или Interbase + Delphi. Если я
чего-то недопонял, ткните носом, как пиписка называется, я не обижусь.

1. Основа конечного приложения - плоская таблица. Пусть независимая от СУБД,
пусть с метаданными и методами, но плоская и тупая.
Например, 1С-программист ничего не знает о реляционной модели. Он оперирует
действительно объектами, максимально приближенными к предметной области
(учет и анализ). Например - иерархический справочник (дерево). Да еще с
поддержкой истории изменения атрибутов. Или - многомерный накопительный
регистр. Накапливает ресурсы в разрезе аналитик. Или документ - допустимы
вложенные таблицы (документы). Понятно, почему создание простого склада на
1C - это день работы. Реляционная схема хранения создается автоматически,
пусть неоптимально, тормознуто (есть над чем работать), но суть в том, что
реляционная модель чрезвычайна бедна для отображения реальных понятий учета
и анализа. Можно и дерево построить, и регистры многомерные, и историю
добавить, и все на плоских таблицах, только я от этого велосипеда устал уже.
Понятно, почему западные системы так долго внедряются. Постоение небоскреба
из кирпичей. А как же блочная технология, господа ? Или я не ту доку читаю ?
Просто в первой главе книжки 1C всегда прописана система понятий. Я по
аналогии думаю, что глава "Developing Axapta Applications" тоже должна
основы давать, и что я вижу ? Только азы ООП и РСУБД.

2. Второй момент, который меня давно гложет - ориентация на данные, а не на
процессы. Я просто сужу с позиций биллинга - например заключение договора на
установку телефона - это документооборот, растянутый во времени, в который
вовлечены несколько сотрудников. Его легко описать в виде сиквенс-диаграммы,
но невозможно закодировать в виде одного метода. Потому что процесс
длительный, и вызов метода ОЖИДАНИЕ_ПЛАТЕЖА() может длиться месяц.
Отсутствие языка программирования, напрямую поддерживающего длительные
процессы и асинхронную работу заставляет городить огород из временных
таблиц, таблиц маршрутов, матриц параметров. Мое мнение в вечном споре
"параметризовать или кодировать" - надо поступать естественно. Если для
человека восприятие процесса (аглоритма) естественнее, чем матрица
коэффициентов, значит кодировать - естественнее. И затраты времени на
понимание влияния 10 параметров на поведение алгоритма - меньше, чем чтение
кода этого алгоритма. Очень хочу иметь платформу, в которой система понятий
максимально приближена к системе понятий обычного человека. Регистр - мощнее
таблицы, значит меньше усилий. Процесс понятнее матрицы параметров и
маршрутов, значит должен появиться язык, поддерживающий длительные процессы
и сохраняющий стек процесса (нити) в периоды ожидания. Тем более, что
технология сериализации нитей уже есть. Тут ни 1C ни Аксапта пока ничем не
могут похвастаться. Кому интересна тема - пишите в мыло.

Итог: нет в мире счастья. И 1C для меня технологичнее Аксапты. Да, она
глючная и немасштабируемая, но и первая Java была не лучше. На тех
допотопных машинах. А сегодня мой сетевой сервис обслуживает 500 операций в
секунду. На Java. На домашнем писюке. Я даже не знаю, что делать, неужели 1C
впереди планеты всей ?
))))

lonelybeam@mail.ru aka Евгений.