опять 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 Евгений.

[smx]

1С лучше!

Хорошо, что Вы аттейн не видели

Основная Ваша ошибка в том, что Вы сравниваете системы как средства разработки. А ЕРП система, это не средство разработки, а СИСТЕМА и этим ценна, все остальное вторично. 1С же великолепен для задачи слабать за час-день-месяц(в зависимости от задачи). А вот сильных конфигураций у 1С до сих пор нет.

С другой стороны, Вы абсолютно правы в том, что будущее за системами в которых помимо таблиц есть готовые, а главное продуманные классы объектов, позволяющие с одной стороны быстро создавать приложение, а с другой покопаться в этих классах и шо-нить да изменить... в конце-концов ООП никто не отменял, а 1С про это упорно забывает...

[maxsmirnov]

В процессе накопления человечеством опыта по созданию erp-систем выяснилось что расставлять галочки дешевле чем программировать.
Откройте в AOT ветку Classes, а затем разверните список методов для всех классов которые вы там увидите. И под конец вы поймете в чем дело - оказывается, за нас кто-то уже написал мегабайты кода.
Конечно большинство алгоритмов настраиваются огромным числом параметров, и матричных, и скалярных, иначе их ценность была бы на порядок меньше.

[smx]

Zitat:

Изначально опубликовано maxsmirnov
В процессе накопления человечеством опыта по созданию erp-систем выяснилось что расставлять галочки дешевле чем программировать.

Конечно, я не волшебник, а только учусь
И совсем не знаю аксапту, однако подозреваю, шо она похожа функционалом на аттейн. А вот с последним такая история - я не представляю клиента, которому бы удалось успешно внедрить аатейн не накодировав несколько тысяч строк... хотя возможно, все это связано не с аттейном, а с качеством меня как специалиста... вопрос только в том, почему, например на нависофте вопросов по функционалу значительно меньше, чем по программингу? И почему так часто встречается "это баг, нужно либо поправить код там-то так-то, либо не юзать галку вообще"?

[Hamster]

Аксапта плохая?
Так внедряете 1С! Ктож мешает... Просто, дешево, менталитет здешний, бухгалтерам привычнее.....

Заодно посчитаете скоко тыс (и в какой степени) строк накодируете.....

[smx]

Дык, не может быть плохой аксапта. Продукт хорош или плох только применительно к конкретному проекту.... вот тут-то все и начинается...

[mazzy]

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

Zitat:

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

Для системного программитса - да. Если вы хотите программировать стеки/очереди/окна/сообщения, если вас интересует отладчик - возьмите delphi и не парьтесь.

Если же вас интересуют процессы, остатки, себестоимости, то в аксапте вы найдете массу готовых классов, которых нет в RAD системах по-определению. В общем, определитесь с точкой зрения и не смешивайте их.

Zitat:

Изначально опубликовано ushastik
1. Основа конечного приложения - плоская таблица. Пусть независимая от СУБД,
пусть с метаданными и методами, но плоская и тупая.

Вот оно - непонимание.
Основа системы - готовые классы, которые работают с таблицами.
Работать с таблицами напрямую - моветон. Хотя так делают. Как с точки зрения быстродействия, так и с точки зрения незнания. Читайте бест-практис.

Zitat:

Изначально опубликовано ushastik
Например, 1С-программист ничего не знает о реляционной модели. Он оперирует
действительно объектами, максимально приближенными к предметной области
(учет и анализ). Например - иерархический справочник (дерево). Да еще с
поддержкой истории изменения атрибутов. Или - многомерный накопительный
регистр. Накапливает ресурсы в разрезе аналитик. Или документ - допустимы
вложенные таблицы (документы). Понятно, почему создание простого склада на
1C - это день работы.

Со всем согласен. Ключевое слово - "простого"
Аксапта не покупается для того, чтобы делать "простой" склад. Аксапта покупается, когда ищут уже готовый функционал. Аксапту берут в расчете, что уж простой склад там точно есть, когда хотят гораздо большего.

Снова определитесь с точкой зрения.

Zitat:

Изначально опубликовано ushastik
Реляционная схема хранения создается автоматически,
пусть неоптимально, тормознуто (есть над чем работать), но суть в том, что
реляционная модель чрезвычайна бедна для отображения реальных понятий учета
и анализа. Можно и дерево построить, и регистры многомерные, и историю
добавить, и все на плоских таблицах, только я от этого велосипеда устал уже.

Все правильно. 1С и создавалась для небольших внедрений, для людей с небольшим опытом в области СУБД... И 1С представила продукт, который дает приемлимые результаты для запросов этих людей. 1С стала монополистом именно потому, что представила продукт, который полностью отвечал запросам.

Но. Когда уровень запросов повышается... Тормознутость, неоптимальность становится уже критическим фактором. И тут выясняется, что тормознутость появляется не из-за того, что в 1С плохие. А просто потому, в выбранной модели быстрее сделать практически невозможно.

Zitat:

Изначально опубликовано ushastik
Понятно, почему западные системы так долго внедряются. Постоение небоскреба
из кирпичей. А как же блочная технология, господа ? Или я не ту доку читаю ?

Нет не понятно
А какже классы ushastik? А какже готовый функционал?

Zitat:

Изначально опубликовано ushastik
Просто в первой главе книжки 1C всегда прописана система понятий. Я по
аналогии думаю, что глава "Developing Axapta Applications" тоже должна
основы давать, и что я вижу ? Только азы ООП и РСУБД.

Вот-вот. А в первой книжке по Аксапте прописан ГОТОВЫЙ функционал, а не инструмент для разработчика

Zitat:

Изначально опубликовано ushastik
2. Второй момент, который меня давно гложет - ориентация на данные, а не на
процессы. Я просто сужу с позиций биллинга - например заключение договора на
установку телефона - это документооборот, растянутый во времени, в который
вовлечены несколько сотрудников.

Вы снова смотрите не с той точки зрения.
Причем, у меня закралось сомнение в вашем представлении о СУБД.
Процесы в СУБД это по крайней мере две таблицы - сам процесс и подчиненная таблица свершившихся действий по этому процессу.
То, что вы описываете делается совсем не так. Даже в Аксапте.

Zitat:

Изначально опубликовано ushastik
И 1C для меня технологичнее Аксапты.

Да ну? Как скажете. Успехов вам.

[smx]

Zitat:

Изначально опубликовано mazzy

Вот оно - непонимание.
Основа системы - готовые классы, которые работают с таблицами.
Работать с таблицами напрямую - моветон. Хотя так делают. Как с точки зрения быстродействия, так и с точки зрения незнания. Читайте бест-практис.

ох, все больше хочу посмотреть на аксапту.

А есть классы содержащие не одну таблицу? Наследники? И тп? Т.е. можно ли , чтобы Поставщики и Покупатели были наследниками Контрагентов?

[france]

2 smx
Хорошая вешь Axapta)) Лучше, чем 1С))... (Хотя такое сравнение изначально некорректно).
Если хочешь узнать про возможнсти встроенного языка X++, то он Java подобен. Но нет множественного наследования и много чего еще из Java))) .

[mazzy]

классы не содержат таблиц.
классы используют таблицы.

про контрагентов, см. например map CustVentTable. см. например, абстрактный класс CustVendCreatePaymJournal и его семейство. Вообще посмотрите как используется наследование. Например, SalesTableType, inventMovment и т.п.

[smx]

если представится возможность обязательно посмотрю

[smx]

Zitat:

Изначально опубликовано france
2 smx
Хорошая вешь Axapta)) Лучше, чем 1С))... (Хотя такое сравнение изначально некорректно).
Если хочешь узнать про возможнсти встроенного языка X++, то он Java подобен. Но нет множественного наследования и много чего еще из Java))) .

Про возможности языка я читал
Меня интересовала именно библиотека классов. Т.е. возможность не копипастать код разработчика, таблицы и тд, а путем наследования абстрактного класса Document создавать свой вид документа... и тд.

[france]

"копипастать")) - эт как раз самая передовая идея 1С))..

[maxsmirnov]

Zitat:

Изначально опубликовано smx

возможность не копипастать код разработчика, таблицы и тд, а путем наследования абстрактного класса Document создавать свой вид документа... и тд.

Библиотека довольно большая, и сравнительно удобная, всегда есть от чего отнаследоваться
Только вот как раз к документам это не относится

[smx]

Zitat:

Изначально опубликовано france
"копипастать")) - эт как раз самая передовая идея 1С))..

Простите, а Вы с MBS Navision работали?

[ushastik]

smx:
Я именно как платформу их сравниваю. Есть такая трава - платформа для построения КИС. А про готовый функционал - я не спорю. Хотя, готовых мощных решений на базе 1С очень много. Если вы не франч, то о большинстве никогда не узнаете Ну не публикуют они базу для простых смертных Тех же биллинговых систем навалом. В основном упираются в производительность платформы, а отнюдь не в кривость языка или отсутствие ООП. Поэтому и крупных внедрений нет. Поэтому в восьмерке за производительность борются, а не за CVS или OOD.

maxsmirnov:
когда количество галок на один алгоритм больше 7 - лучше кодить. Мое субъективное мнение. Недаром в IDF0 ограничено количество боксов на странице.

Hamster:
Я знаю одного 1С партнера, который за всю свою историю не написал ни одной строчки кода. Только перепродажа готовых решений. Их база огромна. Не все качественные. Но выбор есть.

mazzy:
Спасибо за обстоятельный ответ.
Я понял про классы, но классы данных не инкапсулируют, то есть таблицы лежат рядом, такие плоские и доступные Наследование алгоритмов - это круто. Хочется еще наследование структур данных. Подождем, пока объектные СУБД подрастут ?

С уважением.

[france]

to smx
Увы, не работал)) все закончилось на стадии прочтения какой то документации по Navision.

[Hamster]

>Я знаю одного 1С партнера...............

И я знаю 2-х партнеров которые сделали из Axapta почти 1С и разорились, ну и что?

1С - это формально закодированный совковый менталитет ведения бизнеса.
Когда никто ничего не знает, ни за что не отвечает, любые проколы можно спрятать, а бизнес может накрыться через месяц.....
Для своей ниши - продукт незаменимый.

>Хочется еще наследование структур данных
И это есть.
Причем на 2-х уровнях.

[maxsmirnov]

Zitat:

Изначально опубликовано ushastik
smx:
Я именно как платформу их сравниваю. Есть такая трава - платформа для построения КИС

Тогда я с вами согласен.
Axapta - очень плохая платформа для построения КИС.
В первую очередь по финансовым показателям - стоит дорого (вместе с платформой впаривают саму КИС), и разработчики стоят дорого и их мало (в сравнении с рынком разработчиков на Delfi или MS VS, например). Не рекомендую, короче говоря, заниматься разработкой КИС на этой платформе.

[Hamster]

Мдя....
Axapta - платформа специально заточена под КИС, есть все средства разработки бизнес-приложений, готовая бизнес-логика (для дистрибьюции только настройками можно все).

А что вы тогда вообще под КИС понимаете?