Dynamics: v8: Сравнение Navision и 1С глазами программиста

На связь вышел Навизионер. Он сделал несколько мелких замечаний, от которых общая парадигма статьи не меняется. Т.е. существенных замечаний нет.

Немного погодя выложу исправления в статье, но в общем суть претензий такова:

>> Интерфейс разрабочика (Object designer)? Или вообще интерфейс Navision? Из-за тех пунктов, которые вы привели – интерфейс ничуть не хуже. Я через 4 года работы с Навижн увидел, что в 1С можно «закрепить» окна. И что? Наверное это удобно…Но во первых – не всем. Во-вторых, не настолько, чтобы сформулировать вывод, что интерфейс 1С лучше. Увы, здесь я не согласен. Может быть это – дело визуального вкуса. Но мне интерфейс Навижн кажется гораздо лучше и правильней, чем в 1С. И уж поверьте, не из-за того что я – навиженец.

Не принимаю. Да, интерфейс разработчика. Под интерфейсом имеется ввиду весь интерфейс. И он действительно хуже, вот список, как минимум (мало?):
• Symbol Menu, основное средство для ускорения ввода кода в Navision, периодически срабатывает неправильно.
• Окошко свойств (используется чаще всего в Navision) иногда можно вызвать по правой кнопке мышки, а иногда нельзя – только по shift+F4.
• Большинство списков имеют огромный размер и в них нельзя выполнять отбор или сортировку – например выбор типа реквизита. Приходится запоминать номера, чтобы вводить их, экономя время выбора из списка.
• В Navision нет панели открытых окон - только классический список окон в пункте меню Window. В 1С каждому открытому окну соответствует иконка на панели окон. Очень удобно, когда окон открывается очень много.
• Нельзя закрепить окна (Docking).

>> Если система (в своей основе) сделана 5-10 лет назад – то ни фига нелогично ожидать этой фичи. А в будущих версиях – как раз оправдано.

Написано - в идеале (а не для Навижн), не привередничайте...

>> в Навижн-аналогично. •В 1С можно посмотреть значение переменной, наведя на нее курсор

ОК.

>> Как правило – только при экспорте. Так как в основном, в лицензиях не включен доступ к отладчику.

Ну это не принципиально, но поправлю.

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

А что, переменные модуля нельзя назвать с пробелами? Если это так, то сори, но суть не меняет - код пестрит кавычками. Уточните, плиз.

>> Обработка строк. Опять та же постоянная ошибка -неправильный вывод. Морально устарела? Ну, наверное. Но откуда вывод, что это-источник лишнего труда?! Да если я, (и не только я) – 2-3 раза в год использую операции со строками в работе – то какая мне разница, что обработка строк устарела?! Только, не надо опять говорить: «значит вы не работаете на больших проектах и не делаете серьезных модификаций и т.д.». Нормально всё, работаем. Но нет нужды – постоянно работать со строками, да ещё в каких-то хитрых извращениях.

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

>> В Navision очень мало типов данных. Например, нет типа для форм, элементов управления. (для форм - Неправда – есть.)
Да ну, и что вы можете сделать с переменной формы, как вы ее можете обработать? Для буквы я поправлю, но по смыслу верно.

В Navision очень мало типов данных. Например, нет типа для элементов управления и т.п. А тип для форм хоть и есть, но с ним мало что можно сделать – разве что запустить форму. Соответственно невозможно эффективно работать с такими объектами.

>> Например, программист Navision, создавая новый документ, всегда обязан при удалении документа прописывать программный код, который удаляет строки этого документа. Он должен держать это в голове.
??? Создавая новую таблицу наверное? Так как программисты не создают документы – их создают пользователи.

Здесь все верно. Читайте - таблицы для нового документа. Ладно, поправлю, но что то поправки у вас мелкие, придирки что ли:
Например, программист Navision, создавая таблицы для нового документа, всегда обязан при удалении документа прописывать программный код, который удаляет строки этого документа. Он должен держать это в голове.

>> Разработчики Navision пришли к соглашению об именовании таблиц, т.к. таблицы Navision делятся по назначению. Есть таблицы основных сущностей, таблицы шапок документов, таблицы строк документов, таблицы справочных объектов, таблицы связей и т.п. Программист должен помнить и следовать этой схеме
??? А кто сказал, что она есть?? Именно поэтому, за месяц или за 2 можно понять как кодить в Навижн – но стать реальным программистом – займет в разы большее время. Именно, потому что, нет такой схемы.

!!! Это сказал Микрософт в своей схеме для разработчика. И именно это реализовано в Навижн. Незачот.

>> Наличие кода в Navision порождает такие проблемы, как конфликты кодов при загрузке прикладных объектов в конфигурацию. По сути, объекты и их реквизиты могли бы быть сопоставлены по идентификатору, но они сопоставляются по коду. Изменить способ сопоставления нельзя.
??? А отсутствие кодов не порождает проблемы? Да и какая проблема? Что есть таблица номер 15 – а мы вкачиваем таблицы из новой версии тоже с номером 15 – и Навижн говорит, что номера совпадают, что нужно что-то сделать (заменить, слить и пр.) - в чем здесь проблема? Или я не так понял?
!!! Да, можно обойтись только сопоставлением идентификаторов, нафига сравнивать еще и коды.

>> В 1С числовой тип более заточен под финансовые нужды – в нем указывается число цифр целой и дробной части и округление производится именно под указанную разрядность. В Navision тип для хранения денежных величин – тип с плавающей точкой. Соответственно об округлении приходится заботиться программисту
??? Это -скорее плюс, чем минус.
!!! Это ваше имхо, почитайте об этом у Нуралиева. ;-)

>>> Конечно, такой способ обработки данных требует большого времени на проектирование и отладку, поэтому обработку данных в Navision нельзя назвать простой.

??? С чего такой вывод? Вы правы по поводу временных таблиц и массивов. Однако, что дальше? Это свойство никаким образом не выливается в большее время или отладку.

Чем больше сложность кода, тем больше времени нужно на отладку, вы не знали?

>>> Поэтому программисты Navision редко пробуют свои силы в изменении типового кода, потому что он слишком сложный по сравнению с типовым кодом 1С.

??? Именно потому, что он сложный. А сложный он из-за функционала, а не из-за недостатка средств обработки данных.

!!! Не скажите, партионный учет в УПП не менее сложный, но программисту легче разобраться в коде 1С, чем в Навижн, потому что объекты 1С проще и код нагляднее, соответственно программисту нужно меньше времени, чтобы достигнуть квалификации, позволяющей вмешиваться в код.

>>> Лично меня, больше всего от Navision отталкивает именно ограниченный набор средств обработки данных. В той же Axapta, например, существует SQL-подобный язык запросов.

??? Не имею ничего против «отталкивания», однако не вижу никакой ограниченности в обработке данных. Может и должны быть некие дополнительные средства обработки данных, но того, что есть в Навижн - хватает с лихвой.

!!! Не спорю, некоторым бухгалтерам и счетов хватает с лихвой, гыгыгы...

>>> В 1С для хранения данных существует большое разнообразие типов прикладных объектов (справочник, документ, регистр, план счетов), что облегчает работу программиста с разнообразными данными.

??? Извините за тупость ещё раз, а это всё – не таблицы. Или не наборы таблиц? И в них нет полей? А в полях нет значений?

!!! Нет, для программиста 1С это именно объекты, ему по барабану, состоят они из таблиц или нет, по сути это не таблицы.

??? Зато в 1С не нужно беспокоиться о длине поля, используемого для связи. В Navision, нельзя связать две таблицы с разной длиной ключа, например ключи ‘JOHN’ и ‘JOHN ’ несопоставимы.
В 1С связи реализованы с помощью

>>> Зато в 1С не нужно беспокоиться о длине поля, используемого для связи. В Navision, нельзя связать две таблицы с разной длиной ключа, например ключи ‘JOHN’ и ‘JOHN ’ несопоставимы.
??? Ну конечно же можно! А пример, который вы приводите – это уже ЗНАЧЕНИЯ ключевых полей! И с моей точки зрения, в примере не только длина разная – но и значения разные: в одном значении есть пробел, в другом нет. А посему поля – не идентичны.
!!! Так можно или нельзя связать две таблицы с разной длиной ключа? И речь идет о выравнивании, а не о разных значениях... Все таки - можно сделать связь с разными ключами? Если точно можно, я исправлю.

>> Navision не поддерживает иерархические списки, например иерархию номенклатуры. Это большой недостаток, т.к. иерархическая организация данных увеличивает производительность пользователей и 1С широко поддерживает иерархию – от структур хранения данных до синтаксиса языка запросов.

??? Не согласен. Для некоторых – это недостаток. Для некоторых – большой. Для некоторых- и не недостаток вовсе. Всё субъективно. А раз так – добавьте подзаголовок в вашу статью, типа «необъективное мнение» или «мое ИМХО»

!!! Гыгыгы, конечно, те кто не пробовал халвы, не знают ее вкуса, вы пересадите пользователей с 1С (с группами) на Навижн (без иерархии) и увидите, что это - объективно недостаток.

>> В Navision нельзя программно обработать уже сформированный отчет. Поэтому для вывода отчета в другой формат (например, в Excel) программисту приходится переписывать весь код отчета

??? Ну отвечал же уже в форуме – не надо там ничего переписывать! Надо дописывать код вывода на секциях.

!!! ОК. Напишу так (придираемся к букоффкам, суть то прежняя):

В Navision нельзя программно обработать уже сформированный отчет. Поэтому для вывода отчета в другой формат (например, в Excel) программисту приходится дописывать код практически во всех разделах отчета.

>>> В Navision тоже можно формировать отчеты, с произвольным порядком группировок, однако это требует некоторого мастерства от программиста и большего объема кода, чем в 1С. В Navision нельзя явно переставить местами DataItems, поэтому приходится эмулировать такую перестановку.

??? Не очень понял эту фразу – что значит нельзя явно переставить местами DataItem

!!! OK
В Navision нельзя >>>программно<<< переставить местами DataItems, поэтому приходится эмулировать такую перестановку.

>>> Резюмируя, объективно можно сказать, что отчеты в 80 существенно лучше отчетов Navision.

??? Ваша оценка не является объективной – однако с выводом я согласен: отчеты в 1С существенно лучше отчетов в Навижн. Естественно не по всем параметрам. Например простота формирования отчетов в Навижн – значительно лучше чем у 1С(исключая работу с графикой).

!!! А вот простота формирования - это ваша субъективная оценка, гыгыгы или конкретные примеры приведите.

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

??? Не обязательно. Как вы понимает SIFT поля описываются в таблице. Соответсвенно, почему бы там не быть полю «Оборот», которое и будет суммировать оборот за указанный период. И не надо ничего отнимать.

!!! Тогда вам придется использовать два поля, то бишь для одной операции нужно будет иметь два поля, вот вам и нагрузка на программиста. Ну да ладно, поправим:

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

>>> Регистры 1С – это объект предметной области, поэтому работа с ними проще работы с SIFT.
??? Это кто сказал?! Почему проще?! Не вижу этой простоты! Индексы(или ключи) так как же как и таблицы– понятия универсальные. И понять их может любой грамотный программист, а то и не программист вовсе. А регистры – это как раз прикладной объект, то есть специфической. И вам как 1С-ку кажется – что это как пол-пальца … Однако ведь это не для всех так!
!!! Гы, ну конечно же... Регистрам на курсах 1С учат очень быстро, а вот индексы - гораздо более сложная тематика. Я имел ввиду "изучение с нуля". Можем конечно, провести объективное сравнение, но все равно окажется, что регистры проще и ближе "человеку", чем "Сифты". ;-) А почему? Да потому, что регистры - более высокий уровень абстракции, чем индексы.

>>> Допустим, мы занимаемся продажей товаров с нескольких складов.
Нам нужно получить отчет об остатках товара за период дат с А по Б.
??? Идея верная – описание в корне неправильное.
!!! окей, поправлю. ;-) Замечания верные, но принцип остается тем же.

>>> В 1С есть привилегированные модули, в которых можно сосредоточить программный код, который исполняется без контроля прав доступа. В Navision такого нет - это недостаток.

??? С какой стати? Мне это ни разу не понадобилось. А вы возможно используете это каждый день. И что? Опять субъективный вывод – если это никому(или большинству – так корректнее) вообще никогда не надо – то почему это – недостаток системы?! Наоборот, избавление от лишних и ненужных функций.

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

??? Меню Navision можно реализовать средствами 1С, меню 1С нельзя реализовать средствами Navision, т.к. главное меню Navision недоступно для изменения.

!!! Меню Navision можно реализовать средствами 1С, меню 1С нельзя реализовать средствами Navision, т.к. главное меню Navision недоступно для динамического программного изменения.

>>> При этом возникает вопрос – как обеспечить возможность обновления типовой конфигурации новыми релизами от ее поставщика, чтобы при этом эти изменения не входили в конфликт и не уничтожали изменения, сделанные на предприятии?
??? В силу самого вопроса это – невозможно.
!!! Темный вы, посмотрите хотя бы как в Аксапте это сделано.

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

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

??? Не имеет смысл сравнивать по производительности файловые версии Navision и 1С, так как в промышленных масштабах у обеих систем используется MS SQL SERVER.
Это что за заявление?! А каков он промышленный масштаб? Для Навижн – целевая аудитория 3-75 одновременных пользователей. Большинство – 10-25 человек – вполне возможно использование родной базы.

>> Ну и что, часто пользователи экономят на спичках в Навижн, ставя файловую вместо СКЛ? Как факт, а не как можно... 1С в файловом варианте тоже будь здоров пользователей допускает.

>>> Navision/Axapta практически не используется для разработки приложений, т.к. требуют большего времени для начального обучения программированию и проектированию, стоят дороже и регламентируют разработку различными лицензиями, которые нужно дополнительно покупать.
??? А то, что вы подразумеваете – здесь! Именно проектирование, то есть глубокое понимание всех связей в таблицах и механизмов учета – и занимает огромное время от года и больше. Неправда – требуют совершенно коротких вводных курсов. Этому способствует ИСКЛЮЧИТЕЛЬНО низкая цена. Если бы был продукт с простой схемой лицензирования и простой схемой разработки – но стоил бы 100 мил. дол. – он бы никогда не стал популярным
!!! Уважаемый, речь идет о разработке других приложений, а не кастомизации... Понимаете разницу??? На 1С пишут и мелкие базки, со специфическим учетом, которые до этого делали на Аксессе или дельфях.Незачет.

>>> функционал УПП не менее сложный
??? Более правильно второе предложение. Ну не судите вы по функционалу по количеству таблиц – это даже смешно.
!!! Обоснуйте, почему вам смешно, мне смешно, что вы не понимаете системного анализа, отрицая возможность такого сравнения.

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

??? А связано это с тем, что 1С – по определению простая система. Уж не обижайтесь – но маленькая(до 8.0)! И доработать её под заказчика – не проблема вообще!
Дак вот как раз наоборот. Поскольку данные представляют собой предметную область – программист 1С должен знать эту самую предметную область для серьезных изменений. И для этого нужно все-таки иметь не низкую квалификацию.

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

>>> В Navision в одной базе ведется учет разных фирм, но данные по фирмам хранятся абсолютно изолированно, что может вызвать проблемы с консолидацией данных по разным фирмам

??? Что значит «абсолютно»? Во-первых, из одной фирмы я могу получить данные другой фирмы. Во вторых, можно объявить таблицу – общей для всех фирм. Ну и где здесь – абсолютно изолированные?!
!!!
1. Много таких таблиц?
2. Как вы можете из одной фирмы получить доступ к другой.
3. Я так понимаю, что откуда можно получить, задается до начала работы с базой данных, после того, как таблицы стали не общими, фиг получишь доступ.

Или я ошибаюсь?

Пока не принимаю, жду ответа.

>>> В Navision пользователь может целиком удалить план счетов и завести новый. В 1С 80 существуют счета, которые можно удалить только в конфигураторе. Таким образом, конфигурации 1С ориентированы более на конкретные планы счетов, что мешает задуматься об универсальных особенностях бухгалтерского учета для различных систем учета и реализовать эти особенности в конфигурации, как это сделано в Navision.
В последних конфигурациях 1С начинает обращать внимание на универсальность, и сделала возможность гибкой настройки для выбора счетов учета в документах.

??? Это извините не просто «мешает задуматься»! Если используете жесткие термины для Навижн – используйте их и для 1С! Невозможность создания своего плана счетов – это не просто недостаток. Это очень существенный недостаток.

!!! Свой план счетов использовать можно и проводки к нему лягут, нельзя убить стандартные счета, их можно только скрыть. Гм, как бы это расписать.

В Navision пользователь может целиком удалить план счетов и завести новый. В 1С 80 существуют счета, которые можно удалить только в конфигураторе (или скрыть их в списке). Хотя и можно настроить проводки так, что они будут осуществляться целиком на введенных пользователем счетах, но старые счета будут хоть и спрятанными, но существовать в плане счетов. Таким образом, конфигурации 1С ориентированы более на конкретные планы счетов, что мешает задуматься об универсальных особенностях бухгалтерского учета для различных систем учета и реализовать эти особенности в конфигурации, как это сделано в Navision.
В последних конфигурациях 1С начинает обращать внимание на универсальность, и сделала возможность гибкой настройки для выбора счетов учета в документах.

>>> В Navision декларируется принцип простоты (simplicity) – сложные данные пытаются организовать как можно проще, с помощью таблиц. В принципе неплохой подход, но разработка прикладных объектов для предметной области (1С) еще больше увеличивает простоту разработки.
??? Не согласен. Навижн действительно прост – как ведро. А модель данных 1С – я простой назвать не могу.
!!! Ассемблер тоже прост по сравнению с Си, так что напрягитесь и подумайте.

>>> Однако идеологи запрета заднего числа не правы:
• В базе появляются движения, которых на самом деле не было (ошибочные вводы, скорректированные позже), но они числятся в базе и усложняют картину операций.
• Обычно нельзя даже пометить операцию флагом, что она была скорректирована, чтобы отфильтровать скорректированные операции.
• Все-таки ввели отмену по отгрузке товаров, но таки все-равно через возврат.
• Для отслеживания изменений удобнее использовать отдельные журналы регистрации действий пользователей и внесенных ими изменений, чем загружать рабочую базу ошибочными документами.
• Некоторые процессы учета просто невозможно реализовать без перепроведения.
• При оперативной работе перепроведение документов, ограниченное только рамками текущего дня, полезнее введения корректировок, которые только запутывают учет.
??? Не совсем так. Система отражает не реальную отгрузку – а ДЕЙСТВИЯ пользователя по оформлению этой отгрузки. Именно по этому эти операции должны «числиться» в базе. В том числе и для того, о чем вы сказали выше – чтобы было видно как работают люди. Возможно. Если бы при отмене – формировался лог, кто что и куда – то это один из аргументов в пользу возможности отмены. Не всех и с оговорками – но в принципе согласен.

!!! Ну и что? Где преимущества функционала Навижна перед ведением лога изменений в 1С?

>>> Поэтому обычно на предприятиях Navision используется для управленческого учета, т.к. в ней реализован неплохой функционал управления предприятием, а бухгалтерские проводки выгружаются из нее в 1С.
??? Везде, где ставил – Навижн использовался для бухгалтерии (помимо всего прочего конечно)
!!! Странно, а вот у маззи рекомендуют выгружать проводки в 1С.

??? Фильтры справочников и документов есть в Navision и 1С, в Navision можно еще фильтровать и строки документов. А нельзя проще сформулировать? : В Навижн можно фильтровать вообще всё, что пользователь видит.
!!! В 1С тоже все, кроме строк документов, так что ограничимся. ;-)

>>> • Поддержка мультиязычности есть в обеих системах. Но в 1С нет поддержки разного наименования товаров на разных языках.
??? В 1С можно сделать интерфейс английским?
!!! Да

>>> Так как в Navision нельзя работать задним числом, то при переходе со старой системы вопрос отслеживания изменений в старой программе нетривиален.

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

>>> 1С обучаться проще, чем Navision, потому что программист работает с более простыми объектами, чем таблицы
??? Шок! Это какой же объект проще чем таблица? Поле что ли? Но это вроде не совсем объект…? Так что здесь не согласен - я уже выше говорил: обучиться тупому кодингу в Навижн проще, чем где бы то ни было, в том числе и в 1С.
!!! Справочник - программист не должен знать, что такое индекс, он может вообще оперировать термином список.

??? Нет, не согласен. Никакой легкости в программировании я в 1С не увидел – по итогам сравнения в документе.
>>> Ну, ну... Пусть вам по этому поводу ответят программисты 1С и большое обилие курсов по 1С, а также лозунг "Доступно и всерьез". Не захотели увидеть.

>>> Раньше приходилось доплачивать за возможность изменения каждого дополнительный прикладной объект.
??? За создание и редактирование собственных НОВЫХ таблиц отчетов и пр. – нужно платить и сейчас.
!!! Значит сотрудник Микрософт, с которым я обсуждал этот вопрос по телефону меня нагло обманул (втюхал)???

>>> В Navision используется программная продлеваемая лицензия, следовательно, пользователю придется периодически обращаться к Navision для продолжения лицензии
??? Нет. Клиентская лицензия – всегда бессрочная. Лицензия разработчика – обновляемая.
!!! OK

!!! По лицензиям поправлюсь:

Наиболее близкая по функционалу к Navision программа УПП под MS SQL сервер «1С:Предприятие 8.0. Управление производственным предприятием для 10 пользователей + клиент-сервер» стоит 6000$.

Каждый дополнительный пользователь (конкурентное соединение) в 1С стоит 150$ (до 90$ при оптовой покупке 50 пользователей).

В Navision одно конкурентное соединение в полной версии (сопоставимой по возможностям разработки с 1С) стоит около 3000 евро. Самый дешевый вариант 1С - бухгалтерия для одного пользователя (с возможностью разработки) стоит 300$, в Navision – те же 3000 евро. Пользовательская лицензия без возможности доработки стоит 1500 евро.

В общем, в больших системах, разница цен – на порядок 150$ и 1500 евро. Например, система на 50 пользователей будет стоить в 1С 10 тысяч $, а в Navision – 76,5 тысяч евро. За разницу в 66,5 евро можно, например, нанять команду из 4х человек (программистов и консультантов) на год для внедрения и доработки типовой конфигурации.

>>> перспективных вещей, но интерес сугубо познавательный – 1С все-таки использует самые новые технологии программирования, которые пока еще не реализованы нигде.
??? Нет, правда – не смешите людей.
!!! Ну и где реализована работа с объектами прикладной области, а не с таблицами? В Cache???

По многочисленным просьбам, еще раз поподробнее, почему все же отстой. Появилось время выгреб все упоминания в статье системы DynamicsAX (далее Axapta, Аксапта, AX)

>>О чем эта статья?
>>Это сравнение будет интересно в первую очередь программистам, чтобы узнать, в >>чем различается разработка в различных системах и выбрать ту, что больше по >>душе.

>>Иногда в сравнении участвует Axapta – система, имеющая много общего с >>Navision.

Человек не знакомый с Ахапта, будет воспринимать дельнейшую информацию по Navision, как справедливую и для Axapta.
"В Navision нет таких полезных конструкций, как прерывание цикла и пропуск цикла." - в аксапте есть
"Очень печально, что в Navision нет обработки исключений. Невозможно написать надежное приложение без такой обработки." - то же есть.
и т.д. и т.п
Очевидно я не собираюсь дописывать, как это на самом деле в аксапте к каждой фразе с информацией по навижн.
Подавляющее большинство изложенных в статье фактов о системе навижн (я не оцениваю их достоверность), не верно для системы Аксапта.
Не надо вводить в заблуждение читателей материала. Пусть автор потрудится, явным образом указать общее между Аксаптой и Навижн или уберет эту фразу.

Соответственно
2. Статья-отстой.

Полезная информация для программера о разработке в Аксапта сводится к "В той же Axapta, например, существует SQL-подобный язык запросов." и тому, "что
там используется ООП.". ИМНО, с точки зрения программиста, ООП и рализованные на уровне языка (X++) возможности для получения и изменения данных в
таблицах, как раз СУЩЕСТВЕННО отличают AX от NAV. У автобуса много общего с самолетом, салон, колеса, педали, мотор, тормоз, а на наличие крыльев можно
забить ))) За вывод про "много общего" в данном контексте, еще раз
2. Статья - отстой.
И за объем представленных читателю сведений (интересных в первую очередь программистам) о DynamicsAX, от человека который "изучал, запускал, работал. В
пределах учебных курсов."
2. Статья - отстой.
Тот кому интересно получить предствление об Аксапте в духе "в мерседесе есть ручка на правой передней двери, у него задний привод и обычно он ездит
только вперед" - оценит эту статью. На этом можно было бы и остановиться, но уж больно требовали попредметней - получите (что-то пункт "понравилось" без всяких объяснений принимаете)

>>Благодарности
>>К сожалению, программисты Navision/Axapta (www.mazzy.ru) негативно отнеслись >>к моей попытке сравнения и отключили меня от всех посещаемых форумов в Рунете >>по Navision/Axapta.

Да, вот такие они нехорошие люди, программисты аксапта, вот все вместе взяли и отключили от всех ресурсов. )))
1. Маззи не программист, позиционирует себя как "известный специалист в области внедрения Microsoft Axapta, разработки программного обеспечения,

управления проектами. Управляющий партнер компании."
2. На посещаемых форумах по Navision и Axapta, совсем не одни программисты тусуются.
3. Для тех кто в танке - банит на форуме модератор, а не программист или врач.
4. ИМХО причина не в попытке сравнения, а в "дятел долбит"
Плиззз, добавьте в опрос пункт КГ\АМ.

>>Общие особенности интерфейса
>>К тому же, планируется, что все средства разработки Dynamics (Navision/Axapta >>в том числе) будут переведены на Visual Studio. А значит, интерфейс
>>разработчика изменится в лучшую сторону.
В статье ни слова об интерфейсе разработчика в аксапте, однако вывод - будет лучше присутствует. Интерсно, а аксаптовский интерфейс автор видел когда
нибудь? Может поведает, что ему не понравилось?
За необоснованное утверждение
2. Статья - отстой.

>>Прикладные объекты данных
>>Существенное отличие 1С от Navision/Axapta и других классических систем(Access) в том, что она создала прикладные объекты, которые для
>>программиста и пользователя выглядят одинаково - как объекты предметной >>области, для которой они реализованы. При этом такие объекты состоят из
>>множества взаимосвязанных таблиц, но их обработка осуществляется в терминах >>предметной области, а не в терминах реляционной базы данных. При этом,однако, можно получить доступ к этим объектам, как к совокупности составляющих их >>таблиц, например, с помощью SQL запросов.
Ок, хоть определение "прикладного объекта" весьма неконкретно, в Аксапта прямого аналога нет.

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

>>Достоинства использования прикладных объектов предметной области
>>В Axapta программист может создавать классы, описывающие поведение прикладных >>объектов, однако таблицы, из которых состоит такой класс, приходится >>создавать вручную.

Класс не состоит из таблиц, покажите учебный курс, где вы такой бред вычитали. Есть структура данных и есть бизнес-логика. Реализовать бизнес-логику
можно разными способами, методы на таблицах, классы, методы форм и отчетов, можно функцию или Job в конце концов написать

>>Кроме того, поведение прикладных объектов 1С описано на языке базы данных. А >>поведение объектов в Axapta придется описывать на ее встроенном языке. Т.е. реализация прикладных объектов в 1С может быть более эффективной за счет их непосредственной реализации на языке работы с базой данных.

Опять неувязочка, если очень хочется, можно и transactSQL или PLSQl из Аксапты поюзать.

>>Перспективы использования прикладных объектов предметной области
>>Учитывая достоинства и недостатки использования прикладных объектов >>предметной области, усилия разработчиков в будущем будут сосредоточены на
>>следующем:

>>Возможность разрабатывать свои прикладные объекты, описывая код или на >>встроенном языке системы (Axapta), или на языке базы данных (не реализовано). >>Правда, в последнем случае могут возникнуть проблемы с совместимостью кода с >>различными базами данных.
Да из-за возможности юзать и SQL и Oracle, в связке с аксаптой, не рекомендуется использовать "язык базы данных", но это возможно.
>>Автоматическое создание таблиц для хранения экземпляров прикладных объектов (1С).
>>Создание новых типов прикладных объектов, от которых, наследуя, можно создавать новые типы и т.п. (Axapta).

>>Обработка данных в 1C
>>В той же Axapta, например, существует SQL-подобный язык запросов.

Верно, точнее встроенный язык Х++ поддерживает sql-подобные конструкции для выборки и обновления данных. Еще есть возможность динамически создавать
произвольные запросы с помощью т.н. Query объектов и прямой доступ к СУБД. Изучавший, запускавший, работавший, в рамках учебных курсов, мог бы это
заметить.
2. Статья-отстой (за невнимательность при изучении или за способность тщательно скрывать знания)

>>Особенности обновления конфигураций

>>При этом возникает вопрос – как обеспечить возможность обновления типовой >>конфигурации новыми релизами от ее поставщика, чтобы при этом эти
>>изменения не входили в конфликт и не уничтожали изменения, сделанные на >>предприятии?

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

Не надо выдумывать, "гений", для обновления "конфигураций новыми релизами от ее поставщика" в аксапте используется т.н. концепция слоев. При разработке
как раз очень часто вносятся изменения именно в "стандартный" код. Бизнес-логика это не только классы. В Axapta нет "конструкторов".
2. Статья-отстой (за буйную фантазию и нулевое владение материалом)

>>Например, если нужно, чтобы функция F(X) возвращала значение на единицу больше, чем она возвращает сейчас:

>>Class A
>>Function F(X)
>> F:=X*2;
>>End Function

>>Class B->A
>>Function F(X)
>> F:=A::F(X)+1;
>>End Function

>>Elem=New A();
>>R:=Elem.F(1)

>>Пока мы не опубликуем класс B, в переменную R будет заноситься двойка, после >>публикации класса B вместо класса A всегда будет создаваться класс B, и в >>переменную R будет заноситься тройка.

Это был Х++ :)? Впрочем, не буду придираться к синтаксису. Как это может на первый взгляд показаться, возможности вызвать из наследника, именно метод
"отца" - нет. Перекрыть метод мы можем, и соответствующий код отработает, но это совсем не явныей вызов A::F(X)..
Класс B вместо А после публикации никогда создаваться не будет..
new A() - создаст именно A.
2. Статья-отстой (за неработающий пример, за нечеткое изложение материала)

>>Идеальную методику системы Axapta невозможно реализовать в 1С 80 и Navision. >>Но в 1С 81 придумали некоторую альтернативу (подписка на события), в то время >>как программисты Navision вообще ничего не имеют в этом плане.
Не идеальна она. И ООП в Axapta, к сожалению, скорее "псевдо" ООП.

>>Среда для разработки приложений
>>Navision/Axapta практически не используется для разработки приложений, т.к. требуют большего времени для начального обучения программированию и
>>проектированию, стоят дороже и регламентируют разработку различными >>лицензиями, которые нужно дополнительно покупать.

Axaptу практически не используют для разработки приложений, поскольку адекватные люди для забивания гвоздей покупают молоток, а не телевизор, хотя он
тоже тяжелый.
Для разработки в Axapta достаточно иметь лицензию на разработку. Человек имеющий представление о базах данных, С++ или Java, научится программировать
на Х++ и проектировать структуры за два три дня. (помним, что речь именно о среде для разработки?, естественно на изучение существующего функционала,
потребуется на порядки большее время).

>>Поэтому если Navision/Axapta ценны только вместе с типовым функционалом, то >>1С – неплохой инструмент для быстрой разработки среднего размера баз данных.
Просто нет слов. Откликнитесь 1Сники, кто покупал и юзает 1С для разработки баз данных, выкинув типовой функционал, есть пара вопросов..

>>Политика развития типового функционала
>>Navision (и Axapta) развивают одну типовую конфигурацию.
Удивительно, но почему-то на днях вышел долгожданный релиз восточно-европейской (EE) версии AX 4.0. Трешка тоже была не одна, да и 2.5...
>>Партнеры могут делать свои доработки к ней и продавать их, как готовые >>решения.
Могут, но есть и т.н. "вертикальные" решения, которые признает и продвигает сам MSBS. Так что про "одну типовую" не надо.

>>Особенности типового функционала
>>В Navision/Axapta стремятся уложить бизнес-процессы предприятия в схему >>типовой конфигурации, в 1С обычно доминирует позиция заказчика, т.е.
>>типовой функционал изменяется под нужды заказчика.
С чего вы это взяли, при внедрении Axapta задаются вопросом, как бизнес-процесс предприятия можно отразить в системе и если стандартная
функциональность не годится, то она модифицируется под бизнес-процесс .

>>Это связано с тем, что модель данных 1С проще представляет предметную область >>(с помощью объектов предметной области, а не таблиц) и программист даже
>>меньшей квалификации может делать достаточно серьезные изменения в типовой >>конфигурации.
Бездоказательно

>>Работа задним числом
>>В Navision/Axapta используется идеология запрета заднего числа, т.е. после >>проведения документа невозможно отменить его проведение.

>>Navision/Axapta позиционируют себя, как единая система для любой страны мира. >>Но, увы, для России ее идеология мало подходит именно из-за
>>невозможности работы задним числом.
В России не все конторы мухлюют, в остальных мухлюют в совершенно конкретной области учета, для мухлежа всегда можно выгрузить информацию в 1С :), так
что идеология вполне подходит и можете поинтересоваться у Нуралиева, какой кусок рынка Dynamics "увел" и сколько он "стоит".
Любителям все перепроводить подкину задачку, пусть в полтерабайтной базе перепроведут накладную "разнесенную" два года назад (есть и такие конторы, и ничего нормально живут в AX)
>>Выводы
>>В данной статье я попытался систематизировать свои знания об 1С и системах >>Dynamics – Navision и Axapta.
Знаний по Axapta не увидел

>>Я не интересовался преимуществами функционала Dynamics или 1С. Меня >>интересовали эти системы с точки зрения программиста. Мне хочется работать с >>той системой, которая открывает программисту больше всего возможностей.
Да? тогда почему в статье работа задним числом обсуждается? Совсем мало инфы о собственно "программировании" набор типов данных, структур, операторов,
фич, характерных приемов и т.п. где? По анаонсу хотелось узнать из статьи о программировании в NAV и 1С и ничего..
2. (вот тут просто статья не понравилась)

>>Поэтому мне не интересна система Navision. Немного интересна Axapta, в ней >>есть много перспективных вещей, но интерес сугубо познавательный – 1С
>>все-таки использует самые новые технологии программирования, которые пока еще >>не реализованы нигде.
2. Статья-отстой (за бездоказательный гон)
"самые новые технологии программирования, которые пока еще не реализованы нигде" это "прикладные объекты, которые для программиста и пользователя
выглядят одинаково"? или что-то еще? Плиз. список технологий в студию, поговорим и о новизне и о перспекивах в AX.