В какой системе быстрее вести разработку? AX или NAV

[mazzy]

Тема выделена отсюда Предложите вопросы с ответами для следующего опроса "Портрет участника"

Цитата:

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

В какой системе быстрее вести разработку?
* AX
* NAV

Попробую ответить, поскольку знаю эти две системы и несколько других.

Определение: "быстрее вести разработку" значит добиваться заранее определенных результатов посредством программирования за меньшее время.

Ответ: быстрее вести разработку в той системе, где связей меньше.

Пояснение: "скорость разработки" зависит не от удобств самой системы, а от количества объектов, которые затрагиваются (прямо или косвенно) данной разработкой.

Следствие: Чем более функционально развитая система, тем больше вероятность зацепить большое количество системных объектов. Тем больше вероятность "медленной" разработки.

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

Возвращаемся к исходному вопросу: число связей в AX и в NAV - сравнимо. Поэтому "скорость разработки в этих системах" - сравнима и почти одинакова.

==============
Выворачиваем определение наизнанку - "по 1Совски".
Определение 2: "быстрее вести разработку" значит за меньшее время написать какую-то игрушечную конфу с нуля в стиле демонстрационных баз к MS SQL или MS Access.
http://office.microsoft.com/ru-ru/te...010142616.aspx

Ответ: если определить скорость разработки таким образом, то в NAV-е такие игрушечные приложения с нуля пишутся быстрее, потом по скорости Access, потом AX, потом 1С (особенно восьмерка).

==============
Добавил: если же определить скорость создания интерфейса, то InfoPath - вне конкуренции. И качественно выглядит, и оффлайн появляется, и связки с базами хорошие.

[oip]

Сергей, а поясни, пожалуйста, за счет чего в Наве быстрее игрушечные приложения пишутся? Кратко, на пальцах.

[mazzy]

Цитата:

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

Сергей, а поясни, пожалуйста, за счет чего в Наве быстрее игрушечные приложение пишутся? Кратко, на пальцах.

нет меток
не надо парится с типами
не надо парится с menuItem'ами
не надо парится с классами
не надо парится со слоями (можно переопределять все)
до версии 2009 не надо парится с трехуровневостью (появилась в NAV 2009)
таблицы определяются гораздо проще (свойств поменьше, кэширование почти неуправляемое, нет требований по стандартным статическим методам)


В общем все то, что в Аксапте начинает играть красками не в игрушечных примерах, а при более менее сложном девелопменте.

[BOAL]

А можно в этот критерий (игрушечного приложения) добавить условие учесть добавление чего-то нового в полученный результат (масштабирование новой фичей)? И еще раз сравнить
Останется ли рейтинг тем же?

[mazzy]

Цитата:

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

добавить условие учесть добавление чего-то нового в полученный результат (масштабирование новой фичей)?

Не понял. Честно.

[BOAL]

Скорость разработки чего-то простого по "Определение 2" приведена в виде итогового рейтинга.
Если эту оценку добавить еще фактор потребности модификации этого "решения" (не стандартного), при этом другим (новым) разработчиком, который решение не знал. Как это повлияет на порядок следования в рейтинге при различном инструментарии самой разработки, типа проваливания в код, поиска, где используется элемент, сравнения слоев и тп.

[mazzy]

Цитата:

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

фактор потребности модификации ... "решения" ... разработчиком

"фактор"... четыре существительных в родительном/творительном падеже переполняют мой буфер.

Хочешь спросить:
в какой системе быстрее вести разработку, если взять игрушечное приложение и добавить в него много функционала?

Другими словами, когда число связей увеличивается до некоторого критического порога, то где вести разработку быстрее?

Так?

На мой взгляд, скорость разработки в AX растет медленнее из-за типов, menuitem'ов, классов, morphx, перекрестных ссылок и т.п. (добавлю также из личного опыта axAssist - офигительно повышает продуктивность). И с некоторого момента сложности скорость разработки на AX становится очень высокой. Но сложность разработки тормозится из-за почти недокументированных семейств классов, из-за неочевидных вещей, связанных с производительностью и трехуровневостью.

На NAV сложные проекты писать менее удобно. Но за NAV остается простота языка и SIFT... Все-таки одной формулой получать одновременно и отфильтрованные суммы, и drill-down... Это офигительно! И офигительно сокращает время разработки. Ну и матричные формы... Это что-то (тынц, тынц, тынц). Ну, а матричная форма с SIFT... Это пестня.
Но с какого-то момента в NAV'е начинает сильно мешать слабая типизация, слабая объектная модель, недостаточные инструменты для управления производительностью, поддержка совместимости с устаревшей моделью запросов, отсутствие инструментов анализа кода...

В результате, как я уже говорил, скорость разработки сложных проектов в Аксапте и Навике сравнима. (Хотя в следующей версии Навика обещают полноценную трехуровневость - посмотрим как они сохранят простоту и скорость разработки ).

[BOAL]

Спасибо. Этого развернутого ответа и не хватало. А то засунутая АХ далее Аксесса задевала за живое.
Мои знакомства с НАВ, Аксессом и 1С были менее глубинные, чем с АХ и с более древними версиями (<2003) и лично мне значительно быстрее сделать тоже самое на АХ и рейтинг бы у меня был иной, где НАВ был бы вообще в конце .
Тут (в оценке) работает все равно предвзятость оценщика. И личные познания в том или ином. В чем-то будет предпочтение тому или иному от опыта работы и методологии смой разработки, выработанной из опыта (а значит и скорость работы).
Правда АХ у нас обвешана набором утилит, которые на 20-30% по замерам (нет простоев на кликах и ожидании поп-ап меню или поиску по АОТ, обеспечивают однокликовый длил-даун в коде) увеличивают скорость разработки.
Потому в стандарте я вообще нормально работать и не могу. Переход на АХ2009 вылился в перенос утилит и уже потом с ними в нормальном (приятном, без "хватит тормозить, железка!") режиме переноса слоя бизнес модификаций.

[Сисой]

Mazzy, можно прокомментировать, за счет чего "игрушечный" склад на 1С создать сложнее, чем в Аксапте?
Мое мнение отличается: я считаю, что "игрушечное" приложение как раз быстрее создавать на 1С, а вот модификация готового приложения сопоставимой сложности в 1С более трудоемка.
Ведь все то, что перечислено в пользу Нава, можно применить и к 1С:
(заменив NAV 2009 на 1С 8.2).

Цитата:

нет меток
не надо парится с типами
не надо парится с menuItem'ами
не надо парится с классами
не надо парится со слоями (можно переопределять все)
до версии 2009 не надо парится с трехуровневостью (появилась в NAV 2009)
таблицы определяются гораздо проще (свойств поменьше, кэширование почти неуправляемое, нет требований по стандартным статическим методам)

[ibc]

Цитата:

Сообщение от Сисой

Mazzy, можно прокомментировать, за счет чего "игрушечный" склад на 1С создать сложнее, чем в Аксапте?
Мое мнение отличается: я считаю, что "игрушечное" приложение как раз быстрее создавать на 1С, а вот модификация готового приложения сопоставимой сложности в 1С более трудоемка.
Ведь все то, что перечислено в пользу Нава, можно применить и к 1С:
(заменив NAV 2009 на 1С 8.2).

Кроме этого

Цитата:

Но за NAV остается простота языка и SIFT... Все-таки одной формулой получать одновременно и отфильтрованные суммы, и drill-down... Это офигительно!

Хотя, честно говоря не очень понимаю, чем SIFT проще 1С-го регистра? Мне кажется, что не проще!

[mazzy]

Цитата:

Сообщение от Сисой

Mazzy, можно прокомментировать, за счет чего "игрушечный" склад на 1С создать сложнее, чем в Аксапте?
Мое мнение отличается: я считаю, что "игрушечное" приложение как раз быстрее создавать на 1С, а вот модификация готового приложения сопоставимой сложности в 1С более трудоемка.
Ведь все то, что перечислено в пользу Нава, можно применить и к 1С:
(заменив NAV 2009 на 1С 8.2).

В Аксапте связки между таблицами очень удобны. Особенно по сравнению с 1С.
http://axapta.mazzy.ru/lib/steps/step07.html

Для игрушечных приложений можно обойтись по одному типу на каждый Primary Key. И вперед.
В 1С есть понятие подчиненная таблица. И все.
Даже в последних версиях 1С со связками между таблицами нужно поработать (Кнопка Перейти наверху каждой формы).

В Навике немножко по-другому устроены связки/переходы. Поэтому в Навике проще. И в Навике очень многое решается матричными формами... Поэтому в игрушечных примерах особо над связками в Навике и не парятся.

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

и в 1С намного проще нумераторы (хоть они и менее функциональны, но их вполне достаточно для игрушечных примеров). С нумераторами что в Аксапте, что в Навике приходится покодить.

Цитата:

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

Хотя, честно говоря не очень понимаю, чем SIFT проще 1С-го регистра? Мне кажется, что не проще!

Тем, что SIFT - это не только суммирование, но и Drill-Down одной формулой.
Регистры в 1С - это только суммирование, фильтрация. чтобы сделать Drill-Down надо код/запрос писать.


==================
Готов согласится что тема - во многом холиварная.
В зависимости от определений и от приоритетов можно вывести на первое место любую систему.

Но инвариантом остается следующее утверждение IMHO:
= чем больше связей/объектов затрагивается доработкой, тем выше вероятность того, что она будет "медленной".
= при определенном числе связей "удобство среды разработки" уже не оказывает влияния на скорость разработки.

[ibc]

Цитата:

Drill-Down одной формулой.

Можно пример, скриншот?

[mazzy]

Цитата:

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

Можно пример, скриншот?

пожалуйста (хотя по Навику вопросы лучше задавать на http://forum.mazzy.ru )

Типичное FlowField в плане счетов (Аксаптоведы тут же узнают колонку Сальдо и тут же вспомнят как мало сделано для интеграции этой колонки с кнопкой Проводки/Операции)

1) Фильтр не включен.
2) Показывается общий оборот за все времена.
3) Кнопочка Drill-Down выводит все записи, которые формируют данный оборот.


теперь включаем фильтр по полю Отдел = ПРОДАЖИ.
Тут же сумма показывает оборот с этой финансовой аналитикой.
А кнопочка Drill-Down... только не удивляйтесь!... снова выводит все записи, которые формируют данный оборот.



Настраивается просто.


Навижиноводы любят данную фичу и используют ее повсеместно.

[ibc]

Цитата:

Тем, что SIFT - это не только суммирование, но и Drill-Down одной формулой.
Регистры в 1С - это только суммирование, фильтрация. чтобы сделать Drill-Down надо код/запрос писать.

Запрос (конструктором) - да в СКД, а код - вроде нет!

"Drill-Down одной формулой" - формула в nav тот же запрос, ещё и пишется вручную, в 1С запрос пишется конструктором, а текст выделяется цветом.

[kornix]

Цитата:

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

"Drill-Down одной формулой" - формула в nav тот же запрос, ещё и пишется вручную, в 1С запрос пишется конструктором, а текст выделяется цветом.

Насчет СКД (Система компоновки данных) - штука мощная, не спорю, но!
В версии 8.0 и 8.1 довольно часто натыкался на то что конструктором многие запросы не написать. Т.к. в свое время разобрался как они строятся - дальше начал писать вручную (или копируя куски из уже написанных). В чем выгода такого конструктора? Скорость написания простых запросов? Это можно реализовать самостоятельно, например в Ax, начиная с 3-ей версии, но на моей практике, никто подобного не делал и не пользовался.

P.S. Если не ошибаюсь, в Ax есть мастер для построения запросов.

[Reaper]

Цитата:

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

Насчет СКД (Система компоновки данных) - штука мощная, не спорю, но!
В версии 8.0 и 8.1 довольно часто натыкался на то что конструктором многие запросы не написать.

Могло такое быть. Но начиная с 8.2.11 конструктор запросов успешно видит даже временные таблицы головного запроса при конструировании условий виртуальных таблиц. О прочей мелочевке и не говорю. Нынче можно в конструкторе составить запрос любой сложности. Но смак СКД не в этом, а в параметризуемых связях наборов данных компоновки. Благодаря им СКД может решать задачи разузлования без написания прикладного кода, циклов/гигантских запросов.

[mazzy]

Цитата:

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

"Drill-Down одной формулой" - формула в nav тот же запрос, ещё и пишется вручную

нет, не тот же

[ibc]

Цитата:

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

нет, не тот же

Да! В Навижен это просто строчка, похожая на запрос SQL.
Если я не прав, поправьте!

Цитата:

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

Но начиная с 8.2.11

может с 8.1.11?

[Reaper]

Цитата:

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

может с 8.1.11?

Если бы. Если вызвать конструктор для формирования запроса в условии виртуальной таблицы - то в 8.1 временные таблицы основного запроса видны не будут. Вроде