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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.06.2017, 22:44   #81  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.
А можно поподробней про то как получилась эта цифра или она чисто отфонарная ?
Я вообще-то писал про умение не только писать тесты но и код который легко можно покрыть тестами, так вот второе не требует дополнительных затрат и автоматически исключает методы "бога" по 2000 строк как нетестируемые.

Последний раз редактировалось skuull; 18.06.2017 в 22:47.
Старый 18.06.2017, 23:30   #82  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Vadik Посмотреть сообщение
Для 1611 на сегодня - чуть менее 600 X++ хотфиксов.
...
В D365O если разработка по уму организована - это в большинстве случаев..
...
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы
Цитата:
Сообщение от skuull Посмотреть сообщение
...код который легко можно покрыть тестами, так вот второе не требует дополнительных затрат и автоматически исключает методы "бога" по 2000 строк как нетестируемые.
То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?
Старый 19.06.2017, 04:57   #83  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Vadik Посмотреть сообщение
Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Ок. Может усложнение исходников и оправданно. Если учесть что MS реально со всей дури впрягся за "вылизывание" стандарта, то вроде как традиционная "доработка напильником" на местах уходит в прошлое. Остаются только разработчики "вертикальных" решений. А им может и стоит задумываться над тем, как изолировать свое решение от стандарта.
Но, есть другой немаловажный момент. Данные! Вот уж что порублено на фарш, та это данные. В результате "программизма", размер таблиц стал чудовищным. При этом несмотря на невероятные усилия по оптимизации, включая переписывание кусков на хранимках, все равно есть места где откровенно подтормаживает. Но главное даже не в этом. Главное что данные нечитаемые. А это приводит к жутким проблемам с BI. Жутким проблемам с миграцией. Жутким проблемам с нарушением целостности.
В результате применения таких "правильных и прогрессивных" паттернов и нормализации, AX превратилась в систему, у которой очень большие проблемы с построением отчетности.
__________________
Isn't it nice when things just work?
Старый 19.06.2017, 05:57   #84  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.
*Adapter - чем плох? Название говорящее.
*Handler - это действительно непонятно.
*Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению.

Цитата:
тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...
Печать тоже не печатает, а иногда выводит для предварительного просмотра. Возможно стоило назвать Output, например.

Цитата:
а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...
Протяжка параметров это и хорошо и плохо. Хорошо тем, что делает связи явными (то есть при анализе кода можно понять данный параметр нужен только здесь или где-то еще). Плохо тем, что трудоемко. Правда, если параметр упакован в контракт данных, а контракт уже протянут, то может быть и не так трудоемко.

В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс
За это сообщение автора поблагодарили: mazzy (2), ta_and (4).
Старый 19.06.2017, 06:05   #85  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от fed Посмотреть сообщение
Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.
Мне кажется, что тут зависит скорее от задачи.
Если есть отдельный кусок, который часто модифицируется, и для которого просто построить тестовое окружение, то его разумно протестировать автоматически.

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

Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль
Старый 19.06.2017, 07:20   #86  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Цитата:
Сообщение от belugin Посмотреть сообщение
Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль
Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.
__________________
// no comments

Последний раз редактировалось dech; 19.06.2017 в 07:25.
Старый 19.06.2017, 07:52   #87  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от dech Посмотреть сообщение
Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.
Доступен фреймфорк а не сами готовые микрософтовские тесты.
Старый 19.06.2017, 09:17   #88  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Конечно же, 40-50 клиентов - это эспертная оценка. Вполне возможно что я малость неправ, и на самом деле - правильная цифра 25-30 (или наоборот - 50-60). Вопрос в том, что в любом случае - для одного клиента писать юнит-тесты невыгодно. Наверное уже раза 2-3 обсудили на этом форуме, что главная проблема разработки юнит-тестов в аксапте в том, что покрывать придется не только свой код, но и те места в микрософтовском коде, которые могут быть сломаны доработкой.
Если когда-нибудь микрософт опубликует свои собственные юнит-тесты,автоматизированное тестирование партнерских доработок станет выгодным и для меньшего числа клиентов (типа для 5-7). Но я очень сомневаюсь,что в случае разработки для одного клиента, автоматизированное тестирование когда-нибудь станет экономически оправданым. Всегда стоит помнить что стоимость предотвращения ошибки должна быть ниже чем стоимость исправления ее последствий. При этом в случае одного клиента, в 95% (или даже в 99%) случаев проще просто установить доработку в реальное боевое приложение и просто посмотреть что там реальные пользователи выкопают. Ну то есть - конечно консультанты и ключевые пользователи должны какие-то типовые сценарии потестить, но все равно - сложные случаи выловятся только во время боевой эксплуатации.

К слову сказать - первые 5 лет моей аксаптерской карьеры, я работал с версиями 2.1-3.0, которые тестировались в ручную. Там были баги в ядре. Там было много ошибок в российской локализации.В западной бизнес-логике, я за 5 лет столкнулся не более чем с тремя ошибками. В DAX2012, которая реально внедрялась 4 года, я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.

Последний раз редактировалось fed; 19.06.2017 в 12:23.
Старый 19.06.2017, 09:34   #89  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от ax_mct Посмотреть сообщение
То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?
Не все так однозначно.
Я сейчас наверно повторю сказанное ранее, но разбиение 1 класса на 3 есть усложнение для тех кто не понимает MVC и облегчение для тех кто понимает. Плюсы тут уже перечислили.
Как по мне, FormLetter стал легче для понимания и использования, а вот Subledger нет.
Старый 19.06.2017, 09:34   #90  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от fed Посмотреть сообщение
я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.
А кто сказал что юнит тесты имеют хоть какое-то представление о бизнес-функциональности?
Account structures работают? Работают! Default dimensions работают? Работают! Пользователь создал заказ, одобрил, скомплектовал, отгрузил, выписывает инвойс. Ошибка валидации. К кому притензии?
Как в той миниатюре Райкина. К рукаву претензии есть? Нет притензий, рукав отлично пошит. Пришит рукав качественно? Да, не оторвешь даже если захочешь. Так что вам не нравится?
__________________
Isn't it nice when things just work?
Старый 19.06.2017, 09:58   #91  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от belugin Посмотреть сообщение
Вообще, интересно, это свойство конерктной реализации или хотсваппинга в дотнете в вообще, как это делают в других продуктах на дотнете и нет ли проблем со стабильностью у хотсваппинга на оришинальной X++ машине.

(Как не смутно помнится, надо было очень аккуратно перекомпилировать наследников, если как-то не до конца это сделаешь, то будут странные ошибки или тихо данные возьмутся из другого поля)
Насколько я помню, это глубоко частный, спефицический случай, связанных с поведением внешнего оптимизатора (который в виде .net assembly поставляется, без исходных текстов). Но поскольку почти на всех внедрениях есть хоть какое-то призводство, приходится галочку везде отключать.
P.S. Официальное описание проблемы.

Последний раз редактировалось fed; 19.06.2017 в 11:57.
Старый 19.06.2017, 10:44   #92  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation...
видишь ли... никто с этим и не спорит.
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности.

в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных.
в результате нужно не только знать оба, но и знать как заставить их работать совместно.

с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.

и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2017, 12:33   #93  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Конечно же, 40-50 клиентов - это эспертная оценка.
А кто этот эксперт ? Хотелось бы узнать как проводилась оценка.
В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.
Старый 19.06.2017, 12:51   #94  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от skuull Посмотреть сообщение
В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.
Оффтоп.

У меня только одна просьба - не надо сводить к "недостаткам" людей.
Люди везде примерно одинаковые.
Не надо приплетать "леность", "неквалифицированность", "боязь" или что-то другое из арсенала "отношений".

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

сразу выводит на ответ:
на задачах, где тесты не дают ощутимого результата
на задачах, где трудоемкость по созданию тестов превышает ожидаемый эффект,
люди не создают тесты.

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

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

==============
естественно, чисто по индукции, подход "алкоголь в малых дозах безвреден в любом количестве"
может привести (и приводит) к тому, что и на больших проектах тесты могут отсутствовать.

==============
решить задачу "сделать так, чтобы люди писали тесты" очень просто. для этого не нужно изобретать Систему Воспитания.
для этого нужно предоставить доступ к тестам, которые есть.

Например, так как это делается для любого нормального проекта на gitHub.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 19.06.2017 в 13:01.
Старый 19.06.2017, 12:58   #95  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
А кто этот эксперт ? Хотелось бы узнать как проводилась оценка.
В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.
Гм - экспертная оценка, это оценка эксперта. Если оценка получена с помощью какой-то методики, то методика описывается. Если оценка получена просто на основании личного опыта эксперта - то это называется "expert judgment". Я привел свою собственную оценку.Ты тоже можешь свою экспертную оценку привести. Или можешь свою методику расчета окупаемости автоматического тестирования предложить.
А ответ на твой вопрос - достаточно прост: Если ISV разрабатывает add-on типа печати баркодов, хранения электронного архива или чего-то подобного, то точек пересечения с базовым функционалом не так уж много. В этом случае, есть шансы разработать автоматические тесты с более или менее разумными затратами на это (и есть шансы что разработка тестов окупится при меньшем количестве клиентов - типа 15-20-25). Если же ISV разрабатывает отраслевое вертикальное решение, то во первых, точек интеграции будет слишком много чтобы можно было бы покрыть тестами весь стандартный функционал, который может сломаться; Во вторых - в большинстве случаев, такие вертикальные решения собираются пост-фактум, просто добавлением в базовую ветку проектного функционала, разработанного под конкретного клиента. И как мы уже обсудили, при разработке под конкретного клиента, писать автоматизированные тесты просто не выгодно.
И к слову сказать - я вообще считаю что в Аксапте рынка вертикальных решений нет. В 99% случаев, смысл вертикального решения состоит в том чтобы продать консалтинг от их авторов. Я пока только одно отчуждаемое вертикальное решение видел, которое реально можно внедрить не эскалируя 85% проблем его авторам. Остальные вертикальные решения либо вообще в принципе не продаются другим партнерам, либо продаются, но при этом другой партнер реально только базовую настройку делает и пользователей учит (а реальное проектирование решения все равно остается разработчикам вертикального решения)..
Старый 19.06.2017, 13:00   #96  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
видишь ли... никто с этим и не спорит.
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности.
Она не гарантируется. Реально никто не заморачивается тем, чтобы сделать API на все.

Цитата:
в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных.
в результате нужно не только знать оба, но и знать как заставить их работать совместно.
Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:

- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом (у SysOP есть API который называется стандартно и представляет просто метод с параметром)

- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)

- Только pack можно использовать из другого pack (с runbase надо разбираться - они паковку не вынесли отдельно)


Цитата:
с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.
У какого-то количества классов уменьшилась - параметры, UI и бизнеслогика лежат в стандартных местах и их можно использовать отдельно

Цитата:
и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.
Мне кажется для живой системы это нормально - не все переводится единомоментно - это постепенный процесс, python 2.5 -> 2.6 -> 3.0 я уже упоминал, в SAP говорят про три механизма для всего: то, что было давно и оставлено для совместимости, то, что используют все сейчас, то, что новое клёвое, но пока мало кто использует.
Старый 19.06.2017, 13:41   #97  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
Реально никто не заморачивается тем, чтобы сделать API на все.
1. не надо демагогии и слова ВСЕ ))) речь идет о SysOperation, которая должна заменить RunBase.
2. "Реально никто [в МС] не заморачивается" - это и есть причина Оver-engineering с точки зрения остальных разработчиков.

Тут, наверное, мне стоит объяснить остальным участникам,
что фраза Макса "не заморачивается [API]" вовсе не говорит о том, что разработчики в МС не заморачиваются ничем.
В МС самая замороченная процедура приемки кода изо всех что я видел. Поэтому заморачиваться разработчику в МС приходится очень много чем.

Просто критерии важности в МС сильно отличаются от критериев важности на проектах заказчиков и партнеров. Следовательно заморачиваются в МС очень другими вещами, чем на проектах (собственно об этом я и говорил выше).

Цитата:
Сообщение от belugin Посмотреть сообщение
Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:
запустить через MenuFunction или любым другим способом.
пример - хелперы в процедуре закрытия склада.

Цитата:
Сообщение от belugin Посмотреть сообщение
- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом
вообще говоря, нет. см. MenuFunction.

Цитата:
Сообщение от belugin Посмотреть сообщение
- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)
э-э-э...
можно я не буду дальше комментировать?

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

Цитата:
Сообщение от belugin Посмотреть сообщение
У какого-то количества классов уменьшилась - параметры, UI и бизнеслогика лежат в стандартных местах и их можно использовать отдельно
я предполагаю о чем ты.
но для определенности, можешь привести пример?

Цитата:
Сообщение от belugin Посмотреть сообщение
в SAP говорят про три механизма
Ой, все! вот только не надо как 1Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже".
фиг с ними, с сапами, давай в своей системе разбираться/прибираться.
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2017, 16:13   #98  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
d
Цитата:
Сообщение от mazzy Посмотреть сообщение
а различия в критериях-подходах дают убийственную смесь.
Цитата:
Сообщение от belugin Посмотреть сообщение
*Adapter - чем плох? Название говорящее.
...
Цитата:
Сообщение от fed Посмотреть сообщение
В западной бизнес-логике, я за 5 лет столкнулся не более чем с тремя ошибками. В DAX2012, которая реально внедрялась 4 года, я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.
Разбиение кода, покрытие тестами - это просто утилизация чужих денег, не имеющая никакого смысла вне игры в программирование.

Все технические изменения сделанные программистами и для программистов - программизм который чаще всего оverengineering.

Как грамотно замечено Fed, критерий - отрицательный экономический эффект.
У меня у одного чувство что меня обворовали?
Старый 19.06.2017, 16:29   #99  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от ax_mct Посмотреть сообщение
У меня у одного чувство что меня обворовали?
Помню продавать начали 2012. Первый вопрос у заказчика - а в чем плюс для нас. Ну там краснея объясняешь мол Product Management стал вот такой... оптимальный. Ну AIF там... 7ая версия вовсе как я понимаю не продавалась. Но МС мало видимо. Такое впечатление, что в компании реально программисты рулят. А не экономисты
Старый 19.06.2017, 18:35   #100  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
SysOperation уже обсуждали здесь Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework
За это сообщение автора поблагодарили: mazzy (2), Logger (1), ax_mct (3).
Теги
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, время: 21:39.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.