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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.03.2011, 17:44   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от erudit Посмотреть сообщение
подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount().
Только это?

Цитата:
Сообщение от erudit Посмотреть сообщение
Исключения, только подтверждают правила :-) Можно найти разные примеры использования AxBC-классов вне модулей AIF и InterCompany (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.
Хм. Тогда зайдем с другой стороны
Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?

может я чего пропустил?

вот что есть на форуме
Цитата:
Сообщение от Blog bot Посмотреть сообщение
· AxBC (Ax) classes that provide an object API on top of the database tables referenced in the query.

Источник: http://blogs.msdn.com/dsiebold/archi...f-top-ten.aspx
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Источник: http://feeds.feedburner.com/~r/Insid...lbase-api.html
==============

The goal for creating Ax classes was to have an API available when creating and updating records in Dynamics AX tables. The design goals of the AxInternalBase API were as follows:
  • The API must be easy to use.
  • The API must handle related fields. The default value should apply when a field is updated. For example, when you update the customer account field on the sales order, the address fields should be populated with default values when you copy the address fields from the customer record to the sales order record.
  • The API must handle the sequence of field updating. For example, the invoice account field is a related field, which should revert to the default value when the customer account field is updated.
  • Field value defaulting might not always provide the expected end result. Consider an example: If the invoice account field is updated first and related fields' values are defaulted, and then the customer account field is updated and its related fields' values are defaulted, the defaulted value would then overwrite the explicitly provided value in the invoice account field.
  • The API must handle fetching numbers or identifiers from number sequences. For example, when you create a sales order, a sales order number must be fetched from a sales order number sequence. The business logic that handles this is implemented in these classes.
New Ax classes must inherit from the base class AxInternalBase. The AxInternalBase class keeps track of which methods have been executed to set a table field to a specific value.


а также
Как часто вы кастомизируете стандартные сервисы номенклатур. (!)
axStart: InfoPath with default AIF web services (!)
dax-lessons: 3 Clicks to generate AXBC code
dax-ideas: Creating a SalesOrder through .net applications or BC classes
parm-метод для AxBC-класса
Кастом поля и AIF
Preston.Larimer: Item import from CSV file made easy (Kinda)

а также по тегу axbc и тегу aif


=========================
и по прежнему остается вопрос: В чем преимущество ax-классов перед непосредственной работой с таблицами?

в ходе обсуждения выявлены следующие вкусности axbc-классов:
1. удобство для программиста для использования во внешних системах
2. автоматическая "подмена кода" в некоторых заранее прописанных местах
3. инструменты для генерации классов-оберток.

только в чем преимущество внутри Аксапты то?
Например, для работы с журналами внутри Аксапты есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и классы JournalTableData, JournalTransData, journalStactic.
= и куча классов типа LedgerJournalTransUpdate* и даже локализаторское семейство LedgerJournalCreate*
= и классы LedgerJournalTransType в зачаточном состоянии (причем LedgerJournalTableType отсутствует)
= и axLedgerJournal*

Чуть проще для SalesTable. Есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и SalesType*
= и axSalesTable

В чем преимущество каждого из подходов? Когда и какой применять?
__________________
полезное на axForum, github, vk, coub.
Старый 27.03.2011, 18:26   #2  
erudit is offline
erudit
Участник
 
36 / 52 (2) ++++
Регистрация: 19.03.2003
Адрес: Украина
Цитата:
Сообщение от mazzy Посмотреть сообщение
Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?
К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.
Старый 27.03.2011, 20:25   #3  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от erudit Посмотреть сообщение
К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.
Навскидку - есть немного в тренинге по AIF (один параграф в Chapter 2). Может еще где-то есть более подробное описание, хотя в общем и этого достаточно для описания сути. Можно конечно, продолжать искать черную кошку в темной комнате, если "тривиальное" описание не устраивает пытливый ум Сам по себе тренинг интересен как вводный в AIF.
"AXBC CLASSES
Base classes, or AxBC classes, are classes that expose any table used within a document to the AIF framework. Each AxBC class require a specific set of methods. There are get and set methods for each field on the table – these methods are named parm<fieldname> and set<fieldname>. There are also methods to return the current record, to set the current record, to return an empty record, and to return an orig() record."

https://mbs.microsoft.com/customerso...alse&stext=aif development

Последний раз редактировалось mifi; 27.03.2011 в 20:29.
Старый 27.03.2011, 22:10   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
спасибо, erudit.

Цитата:
Сообщение от mifi Посмотреть сообщение
Можно конечно, продолжать искать черную кошку в темной комнате, если "тривиальное" описание не устраивает пытливый ум Сам по себе тренинг интересен как вводный в AIF.
mifi, вы упорно пытаетесь ответить не на тот вопрос.
и упорно уводите обсуждение в оффтопик.

повторяю вопрос:
Цитата:
Сообщение от mazzy Посмотреть сообщение
и по прежнему остается вопрос: В чем преимущество ax-классов перед непосредственной работой с таблицами?
"тривиальное описание" не дает ответа на вопрос "чем лучше/хуже".
"тривиальное описание" не дает ответа на вопрос "когда именно эффективнее использовать одно, а когда именно другое".
что ж, спасибо хоть за информацию о том, что кроме "тривиального описания" пока ничего нет.
__________________
полезное на axForum, github, vk, coub.
Старый 28.03.2011, 01:02   #5  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
В чем преимущество ax-классов перед непосредственной работой с таблицами?
"Управление из одной точки", отсутствие явных завязок на бизнес-логику, определяющую взаимозависимости полей, в фиговой туче мест приложения, где нужно работать с таблицей (соблюдения принципа DRY, пользуясь другой терминологией). За счет этого при необходимости изменить эту логику достаточно поправить один класс вместо десятков мест в коде. Код инициализации записи максимально упрощается: накидали известные значения полей (причем в произвольном порядке!), дернули один метод - и готово.
Цитата:
Сообщение от mazzy Посмотреть сообщение
в ходе обсуждения выявлены следующие вкусности axbc-классов:
1. удобство для программиста для использования во внешних системах
2. автоматическая "подмена кода" в некоторых заранее прописанных местах
3. инструменты для генерации классов-оберток.
Генераторы классов-оберток - это не вкусности, а средства компенсации негативных моментов, связанных с использованием AxBC-классов: любой дополнительный слой абстракции требует дополнительных накладных расходов на его поддержку, и генератор AxBC-классов-оберток лишь несколько снижает эти накладные расходы.
Цитата:
Сообщение от mazzy Посмотреть сообщение
только в чем преимущество внутри Аксапты то?
4. Код, работающий с таблицами, намного меньше завязан на бизнес-логику, связанную с той или иной таблицей, он намного более унифицирован.
5. При необходимости начать заполнять новое поле в зависимости от других полей во всех местах, где идет создание записей в таблице, достаточно поменять один класс - не надо менять десятки мест в приложении, где об этом поле раньше никто не знал (опять же принцип DRY, снижение стоимости сопровождения).
6. Это, по-моему, очень важно: методы initFromXX могут давать разный результат в зависимости от последовательности их вызова! При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Например, для работы с журналами внутри Аксапты есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
Ничем не отличается от работы с любыми другими таблицами - со всеми описанными выше проблемами.
Цитата:
Сообщение от mazzy Посмотреть сообщение
= и классы JournalTableData, JournalTransData, journalStactic.
Не более чем код, реализующий общие моменты работы с журналами: ваучеры, номера журналов, итоги по строкам журналов в шапке, блокировки... В общем, ничего из того, что делают классы AxBC.
Цитата:
Сообщение от mazzy Посмотреть сообщение
= и куча классов типа LedgerJournalTransUpdate* и даже локализаторское семейство LedgerJournalCreate*
Слишком узкоспециализированы
Цитата:
Сообщение от mazzy Посмотреть сообщение
= и классы LedgerJournalTransType в зачаточном состоянии (причем LedgerJournalTableType отсутствует)
И ничего он не отсутствует Это уже ближе к теме, но все же недоразвито.
Цитата:
Сообщение от mazzy Посмотреть сообщение
= и axLedgerJournal*
Почти ничего не отличается от "голой" обертки, генерируемой мастером. Еще, наверно, стоило упомянуть семейство LedgerJournalEngine: раньше эти классы были жуткой смесью бизнес- и презентационной логики, к тому же работавшей строго на клиенте: они управляли и заполнением одних полей при изменении других, и доступом на редактирование всей текущей записи или отдельных полей, т.е. заведомо предполагалось, что курсор связан с datasource'ом и это предположение почти нигде не проверялось. Сейчас отчасти эти косяки исправлены, но остались те же "родовые проблемы", что и при использовании initFromXX: результат очень сильно зависит от порядка заполнения полей и дергания различных методов класса, плюс идея type-классов, как всегда, реализована не до конца: в базовом классе остался вагон и маленькая тележка мест, где явно прописан тот или иной тип журнала, вместо параметризации логики и перегрузки параметрических методов в классах-наследниках. И опять получается, что если в десятках мест создается журнал определенного типа, а потом в нем надо заполнять новое поле, то надо идти и править одинаковым образом эту хренову тучу мест, а если это стандартный функционал, то проделывать эту работу снова при любом крупном обновлении приложения.
Цитата:
Сообщение от mazzy Посмотреть сообщение
В чем преимущество каждого из подходов? Когда и какой применять?
Провокация какая-то Я лично не готов писать руководства в стиле Best Practices, могу лишь сказать, к чему пришел на собственном опыте после нескольких лет разработки: если речь идет не о контрактной работе по реализации разовых модификаций, то в долгосрочной перспективе предпочтительным видится подход с использованием AxBC-классов. Он сложнее в реализации, требует фиговой тучи промежуточного кода (который, впрочем, можно во многом сгенерить мастером), требует выворачивания на изнанку привычной логики работы методов initFromXX (там изменили одно поле - и каскадом поменялась куча других, тут надо описывать изменение каждого отдельного "другого" поля в зависимости от возможных изменений кучи "исходных" полей). Но в общем и в целом он существенно снижает стоимость поддержки приложения. А при реализации модификаций, если речь, опять же, не идет о разовой контрактной работе, нужно в первую очередь думать о перспективах поддержки, а не о стоимости решения текущей локальной задачи. Причем в стоимость поддержки входит как стоимость возможного изменения кода в будущем, так и стоимость его переноса на новые service pack'и и новые версии приложения. Более того, опять хотел бы вернуться к процитированному фрагменту из "What's New - Technical in Microsoft Dynamics AX 2012 for Development": в следующей версии штатно будет реализована возможность редактировать данные в Excel - то, о чем мечтает, по моим впечатлениям, 95% пользователей Аксапты, особенно работающих с финансами. Эта возможность напрямую будет зависеть от наличия и корректности реализации AxBC-классов, так что их реализация и использование сейчас - это еще и большой задел на будущее. Но, разумеется, в определенных условиях (таблица используется лишь в нескольких местах приложения, либо нужно сделать простое решение, а на разработку AxBC-классов никто не выделит бюджет, либо все уже слишком запущено, и на рефакторинг всего существующего кода никто не выделит бюджет) придется использовать лучшее из имеющегося либо создавать "простые" initFromXX-методы.
За это сообщение автора поблагодарили: mazzy (10), Logger (10), DmitrySt (1), konopello (3), wojzeh (1).
Старый 28.03.2011, 01:34   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Спасибо. Круть.
Цитата:
Сообщение от gl00mie Посмотреть сообщение
При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX.
о_О!

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Провокация какая-то


Цитата:
Сообщение от gl00mie Посмотреть сообщение
то в долгосрочной перспективе предпочтительным видится подход с использованием AxBC-классов. Он сложнее в реализации, требует фиговой тучи промежуточного кода (который, впрочем, можно во многом сгенерить мастером), требует выворачивания на изнанку привычной логики работы методов initFromXX (там изменили одно поле - и каскадом поменялась куча других, тут надо описывать изменение каждого отдельного "другого" поля в зависимости от возможных изменений кучи "исходных" полей). Но в общем и в целом он существенно снижает стоимость поддержки приложения.
Надо подумать....

Наизнанку, стало быть... А ведь, правда... Спасибо за хорошее слово...
Название: 1.PNG
Просмотров: 1271

Размер: 3.4 Кб


Цитата:
Сообщение от gl00mie Посмотреть сообщение
Более того, опять хотел бы вернуться к процитированному фрагменту из "What's New - Technical in Microsoft Dynamics AX 2012 for Development": в следующей версии штатно будет реализована возможность редактировать данные в Excel - то, о чем мечтает, по моим впечатлениям, 95% пользователей Аксапты, особенно работающих с финансами.
О, дык вот какая задумка была...
Тогда годная задумка...

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Эта возможность напрямую будет зависеть от наличия и корректности реализации AxBC-классов, так что их реализация и использование сейчас - это еще и большой задел на будущее. Но, разумеется, в определенных условиях (таблица используется лишь в нескольких местах приложения, либо нужно сделать простое решение, а на разработку AxBC-классов никто не выделит бюджет, либо все уже слишком запущено, и на рефакторинг всего существующего кода никто не выделит бюджет) придется использовать лучшее из имеющегося либо создавать "простые" initFromXX-методы.
О!
А есть методика сопряжения старого (initFrom) и нового (axBC) подхода?
Или они принципиально несопряжимы?

Т.е. можно ли использовать initFrom из axBC-классов? и наоборот, можно ли использовать axBC из InitFrom?
какие ограничения? при каких условиях это допустимо, а при каких нет?
__________________
полезное на axForum, github, vk, coub.
Старый 28.03.2011, 12:13   #7  
Zepp is offline
Zepp
Участник
MCBMSS
 
37 / 31 (2) +++
Регистрация: 26.10.2005
Цитата:
Сообщение от mazzy Посмотреть сообщение
... Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать? ...
Есть здесь:
APIs in the Standard Application
http://msdn.microsoft.com/en-US/library/aa873132.aspx
Application Integration Framework Overview
http://msdn.microsoft.com/en-us/library/bb496535.aspx

Также в книгах:
"Inside Microsoft Dynamics AX 4.0" Part II Chapter 9,
"Inside Microsoft Dynamics AX 2009" Part III Chapter 17.
__________________
Мой профиль
За это сообщение автора поблагодарили: mazzy (2), Logger (6).
Теги
ax-классы, axbc, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
daxdilip: Whats New in Dynamics AX 2012 (A brief extract from the recently held Tech Conf.) Blog bot DAX Blogs 7 31.01.2011 12:35
semanticax: Dynamics AX 2009 Installation - Application Blog bot DAX Blogs 0 22.12.2010 08:11
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Arijit Basu: AX 2009 - Quick Overview Blog bot DAX Blogs 4 19.05.2008 14:47

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:24.