AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.06.2017, 22:34   #21  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
в частности команда Макса Белугина работает над проектом, который очень сильно оторван от интерфейса аксапты, но задевает достаточно глубинные механизмы. Я все ждал, что Макс сам расскажет об инструментарии. но раз он молчит, значит время еще не пришло.
EVGL уже написал пост и я даже в комментах поучаствовал. Что рассказывать про внутренню кухню можно, а что нельзя, я не знаю.

Цитата:
3.
Сценарии работы.
Уж не знаю к счастью или к сожалению, но в МС сейчас одержимы идеей "пользовательских сценариев". грубо говоря, некто продумывает "как будут работать пользователи" и это становится священным писанием, которое нельзя изменить.

Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя.
Их по-моему постоянно расширяют . Мне кажется сценарии нужны чтобы представлять, как будет работать пользователь на всех этапах бизнес процесса - чтобы одна фича согласовывалась с другой.
За это сообщение автора поблагодарили: mazzy (2).
Старый 15.06.2017, 22:53   #22  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,524 / 473 (19) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от belugin Посмотреть сообщение
Вполне возможно, что тут причина отчасти и в том, что у вендора, партнера и клиента разные задачи по отношению к этим 2000 строкам.
...
Так что для каждого отсутствия оверинжиниринга был бы разный уровень избыточности кода.
От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.
Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

Цитата:
Сообщение от belugin Посмотреть сообщение
Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?
Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Медленность нативного X++ это миф, бедность IDE - миф.
Скорость это железо, база данных и кэширование, бедность IDE - это плагины.
Старый 15.06.2017, 23:26   #23  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,635 / 3261 (150) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Медленность нативного X++ это миф, бедность IDE - миф.
Я разделяю мнение насчет программисткого подхода.
Но это уже перебор. Нативный X++ и медленный, и бедный.

и дело даже не в портировании на .net/vs.
каждый помнит тормоза при первом обращении к AOT, при создании программисткого проекта. для глобальной компиляции аж специальную утилиту сделали.

про бедность - стоит вспомнить, что X++ основан на java-виртуальной машине первого поколения. когда никакого JIT, никаких оптимизаторов, тривиальный сборщик мусора, убогая модель объектов в памяти, чудовищно неэффективные exception и кривая релиазция tread, никаких функций высшего порядка. (тривиальный-убогий-неэффективный конечно по нынешним временам и по современным меркам).

сейчас актуальной является java 8 поколения. ближайшим будущим является java 9.

бедность особенно проявляется в том же инструментарии. хотя тот же jUnit третьего поколения реализовали. актуальным является junit четвертого поколения.

событий в morphX до версии акс7 существенно меньше, чем есть в операционках.
контролов современных не хватает.

не говоря уже про убогий отладчик.

==========================
не, morphX - отличная вещь для своего времени, хорошо продуманная и крепко сделанная.
но рано или поздно все-таки надо двигаться дальше.
и хорошо, что двигаются.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 15.06.2017 в 23:31.
За это сообщение автора поблагодарили: macklakov (5).
Старый 16.06.2017, 01:11   #24  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,524 / 473 (19) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
Я разделяю мнение насчет программисткого подхода.
Но это уже перебор. Нативный X++ и медленный, и бедный.
...
но рано или поздно все-таки надо двигаться дальше.
и хорошо, что двигаются.
Спасибо за по существу. Но можно слушать пользователей, то есть не страдать аутизмом, но при этом продолжать болеть программизмом и в упор не видеть оverengineering.

Тормозов стало меньше? Что-то стало быстрее? Да на текущем железе оно летало бы.
Программировать стало легче?

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

оverengineering это когда нет чувства достаточности. Тот медленный и бедный нативный X++ был достаточен. Это как лопату усовершенствовать.
Старый 16.06.2017, 03:56   #25  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,918 / 810 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Если это про Microsoft Dynamics 365 for Talent
https://www.microsoft.com/en-us/dynamics365/talent
то это большой вопрос что есть
Оver-engineering - "зачем так сложно?"
если делать это как модуль AX или CRM.
А вот это уже очень интересно. Ради такого дела навороченный дизайн весьма оправдан.
Зачем? Чтобы развалить AX на множество взаимо-заменяемых модулей из которых можно компоновать решения.
__________________
Isn't it nice when things just work?
Старый 16.06.2017, 05:03   #26  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,918 / 810 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от mazzy Посмотреть сообщение
Знаешь, у меня и раньше было подозрение, что в разных странах в принципе одно и то же.
А теперь, когда напрямую поработал с запросами из разных стран, моя уверенность в том, что в основе стоят универсальные потребности, только увеличилась.

Типичный пример - счета-фактуры, книги продаж и покупок.
Сколько говорили про российскую специфику, про то, что их должны править задним числом. И т.п.
Нет, конечно accounting, в своей основе, более-менее похож везде. Но есть свои ньюансы. К примеру, как часто тебе приходилось настраивать рассчет себестоимости по LIFO? Или по каким принципам сейчас считается налог в Новой Каледонии? Как проводить взаимозачеты с клиентом в Китае, если и вы и клиент ведете бизнес в нескольких провинциях? Ну и всем нам знакомая корреспонденция, конечно. И этот самый счет фактура в какую сторону должен читаться? Слева-направо, сверху вниз? Или наоборот? Т.е. ядро ГК оно, конечно, почти всем подходит, а вот первичка...
И это банальные вещи, завязанные на местное законодательство. А есть же и новые бизнес-практики. К примеру agile компании, с взаимозачетами между подразделениями, оперативно перемещающиеся логистические хабы. Постоянно меняющиеся банковские и финансовые инструменты. Диктат со стороны бизнес-партнеров. Общая тенденция по переходу от торговли к аренде и сервисам.
Один поставщик не может за всем поспевать. "Универсальное" решение не сможет покрыть все варианты. А это означает, что таки придется отдавать значительные сегменты приложения на откуп сторонним поставщикам.
__________________
Isn't it nice when things just work?
Старый 16.06.2017, 10:33   #27  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Что-то стало быстрее?
ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них
За это сообщение автора поблагодарили: Vadik (1), Logger (3), mazzy (2).
Старый 16.06.2017, 10:47   #28  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.
А если расчленим хорошо - то он будет понятней. Если не расчленим, то придется расчленять на бумажке каждому читающему заново, чтобы понять.

Цитата:
Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.
Только вчера ревьюил фикс баги, которая бы не возникла если бы код не продублировали.

Цитата:
Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.
Докажите.

Цитата:
бедность IDE - это плагины.
Вы непонятно выражаетесь. "Граальность" VS в том, что плагинов там большая куча
Старый 16.06.2017, 10:50   #29  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
684 / 517 (19) +++++++
Регистрация: 14.10.2004
Цитата:
Сообщение от belugin Посмотреть сообщение
Только вчера ревьюил фикс баги, которая бы не возникла если бы код не продублировали.
Похоже, чтобы решить задачку из соседней ветки, придется продублировать целую форму. А в старых Аксаптах все решилось бы маленькой модификацией
добавить readonly датасорс на форму, для фильтрования
Так какой подход плодит больше багов: старый или новый?
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/
Старый 16.06.2017, 11:02   #30  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Ace of Database Посмотреть сообщение
Похоже, чтобы решить задачку из соседней ветки, придется продублировать целую форму. А в старых Аксаптах все решилось бы маленькой модификацией
Если бы там был метод в 2000 строк - было бы легче?
Старый 16.06.2017, 11:17   #31  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
684 / 517 (19) +++++++
Регистрация: 14.10.2004
2000 строк - это плохо. Но еще хуже, когда для добавления источника данных надо дублировать форму. Хотя в бест практис еще с древнеших времен писалось, что вместо того, чтобы модифицировать стандартную форму, надо ее скопировать в новую. Но на практике так редко делали. Прямо в форму SalesTable все пихали.
В принципе, в 1С вообще многие программисты живут только на внешних обработках. Стандартный функционал для них править - жесткое табу, т.к. 1С регулярно обновляется. Возможно, что Аксапта идет по пути 1С.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/
Старый 16.06.2017, 11:34   #32  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
750 / 151 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Платформа "устарела", "современные технологии" - это оно самое. Болезнь
"устарела" если нельзя полноценно CLR Interop
"современные технологии" - AIF, Sharepoint...

3.0 я привожу для чистоты примера. Да 2009 - лучше, но велика ли разница?
По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.
__________________
Axapta 3.0 sp - хз какой, kr2
Старый 16.06.2017, 11:37   #33  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Ace of Database Посмотреть сообщение
Но еще хуже, когда для добавления источника данных надо дублировать форму.
Это отдельное обсуждение на тему "Надо ли закрывать возможность overlayering, а если надо, то где и когда"
Старый 16.06.2017, 12:25   #34  
Logger is offline
Logger
Участник
Лучший по профессии 2014
 
2,807 / 1453 (54) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от belugin Посмотреть сообщение
ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора
Да, это так и CIL хорош для этих целей. (Хотя в случае корреспонденции, надо бы все же алгоритм оптимизировать, так как для большого числа строк CIL тоже не поможет. Слишком быстро растет время с ростом числа строчек в документе )
Но к сожалению есть ряд минусов, которые сильно портят впечатление.

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему Помогите найти: Сравнение производительности различных операндов при конкатенации строк
операция += в CIL ведет себя по-тормозному по сравнению с p-code. И никуда тут не денешься. только если переписывать код через StringBuilder или TextBuffer что сильно ухудшает читаемость.

пп. 1-2 зануляют все плюсы CIL
Рука тянется за револьвером
Старый 16.06.2017, 12:47   #35  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,880 / 2004 (74) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?
Ответ на этот вопрос я не знаю.

Цитата:
2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.
Как тогда реализовано Edit and Continue ?

Цитата:
3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему
Интересно. Тут вопрос за счет чего это и нельзя ли пофиксить помпилятор чтобы он для конкретного случая генерировал StringBuilder. Спасибо за ссылку
Старый 16.06.2017, 12:57   #36  
Logger is offline
Logger
Участник
Лучший по профессии 2014
 
2,807 / 1453 (54) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от belugin Посмотреть сообщение
Интересно. Тут вопрос за счет чего это ...
Вероятно, причина в этом:
Помогите найти: Сравнение производительности различных операндов при конкатенации строк
Старый 16.06.2017, 13:01   #37  
Logger is offline
Logger
Участник
Лучший по профессии 2014
 
2,807 / 1453 (54) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от belugin Посмотреть сообщение
Как тогда реализовано Edit and Continue ?
Интересно. Но если я не ошибаюсь, в аксапте такое не прокатывает. По ссылке речь об отладке в VS в специальном режиме.
За это сообщение автора поблагодарили: mazzy (2).
Старый 16.06.2017, 13:16   #38  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,524 / 473 (19) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от belugin Посмотреть сообщение
ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них
Моя категоричность она для чистоты лечения

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое решение.

Но нам же неинтересен плоский T-SQL так как 3D OOП, не так ли? Вот оно и есть - программизм.
Старый 16.06.2017, 13:22   #39  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,524 / 473 (19) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от egorych Посмотреть сообщение
По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.
При стандартной поддержке существующего эти kernel проблемы были бы решены в рабочем порядке.

А разница создания Web-сервис в 3.0 и 2009 - это программизм. Это вопрос новых классов/библиотек на уровне языка. Генерировать код можно на чем угодно.
Старый 16.06.2017, 13:24   #40  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,635 / 3261 (150) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Те же хранимые процедуры это стандартное и приемлимое решение.
Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь.

Цитата:
Сообщение от ax_mct Посмотреть сообщение
Моя категоричность она для чистоты лечения
не надо, пожалуйста.
открывайте балаган в курилке в новой ветке.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Теги
sysoperation framework

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ModelElementData_HasModelId_LayerId". The conflict occurred in database "YourDataBaseName_model", table "dbo.Model" Blog bot DAX Blogs 0 23.05.2014 13:11
Dynamics AX Sustained Engineering: Performance issue in "Open Transaction Edit" form Blog bot DAX Blogs 0 26.10.2009 20:05
Зачем нужны "Параметры кодов аналитики"? Кирилл DAX: Программирование 2 16.04.2004 14:22
Зачем нужна "Потребность в номенклатуре" Tony Green DAX: Функционал 4 02.02.2004 00:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:58.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.