|
![]() |
#1 |
Участник
|
Цитата:
Цитата:
Присоединюсь к 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:
а также Как часто вы кастомизируете стандартные сервисы номенклатур. (!) 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 В чем преимущество каждого из подходов? Когда и какой применять? |
|
![]() |
#2 |
Участник
|
К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.
|
|
![]() |
#3 |
Microsoft Dynamics
|
Цитата:
![]() "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. |
|
![]() |
#4 |
Участник
|
спасибо, erudit.
Цитата:
и упорно уводите обсуждение в оффтопик. повторяю вопрос: Цитата:
"тривиальное описание" не дает ответа на вопрос "когда именно эффективнее использовать одно, а когда именно другое". что ж, спасибо хоть за информацию о том, что кроме "тривиального описания" пока ничего нет. |
|
![]() |
#5 |
Участник
|
Цитата:
Цитата:
5. При необходимости начать заполнять новое поле в зависимости от других полей во всех местах, где идет создание записей в таблице, достаточно поменять один класс - не надо менять десятки мест в приложении, где об этом поле раньше никто не знал (опять же принцип DRY, снижение стоимости сопровождения). 6. Это, по-моему, очень важно: методы initFromXX могут давать разный результат в зависимости от последовательности их вызова! При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX. Цитата:
Цитата:
Цитата:
![]() ![]() |
|
|
За это сообщение автора поблагодарили: mazzy (10), Logger (10), DmitrySt (1), konopello (3), wojzeh (1). |
![]() |
#6 |
Участник
|
Спасибо. Круть.
Цитата:
Сообщение от gl00mie
![]() При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX.
![]() Цитата:
Сообщение от gl00mie
![]() то в долгосрочной перспективе предпочтительным видится подход с использованием AxBC-классов. Он сложнее в реализации, требует фиговой тучи промежуточного кода (который, впрочем, можно во многом сгенерить мастером), требует выворачивания на изнанку привычной логики работы методов initFromXX (там изменили одно поле - и каскадом поменялась куча других, тут надо описывать изменение каждого отдельного "другого" поля в зависимости от возможных изменений кучи "исходных" полей). Но в общем и в целом он существенно снижает стоимость поддержки приложения.
Наизнанку, стало быть... А ведь, правда... Спасибо за хорошее слово... Цитата:
Сообщение от gl00mie
![]() Более того, опять хотел бы вернуться к процитированному фрагменту из "What's New - Technical in Microsoft Dynamics AX 2012 for Development": в следующей версии штатно будет реализована возможность редактировать данные в Excel - то, о чем мечтает, по моим впечатлениям, 95% пользователей Аксапты, особенно работающих с финансами.
Тогда годная задумка... Цитата:
Сообщение от gl00mie
![]() Эта возможность напрямую будет зависеть от наличия и корректности реализации AxBC-классов, так что их реализация и использование сейчас - это еще и большой задел на будущее. Но, разумеется, в определенных условиях (таблица используется лишь в нескольких местах приложения, либо нужно сделать простое решение, а на разработку AxBC-классов никто не выделит бюджет, либо все уже слишком запущено, и на рефакторинг всего существующего кода никто не выделит бюджет) придется использовать лучшее из имеющегося либо создавать "простые" initFromXX-методы.
А есть методика сопряжения старого (initFrom) и нового (axBC) подхода? Или они принципиально несопряжимы? Т.е. можно ли использовать initFrom из axBC-классов? и наоборот, можно ли использовать axBC из InitFrom? какие ограничения? при каких условиях это допустимо, а при каких нет? |
|
![]() |
#7 |
Участник
|
Цитата:
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, как правильно |
|
|