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

[mazzy]

Вопрос скорее на понимание.

В последних версиях есть ax-классы, которые являются обертками вокруг соответствующих таблиц. (axSalesTable, axSalesLine, axCustTable, axLedgerJournalTrans и т.п.)

Я как-то привык по старинке работать непосредственно с таблицами.

SalesTable.clear();
SalesTable.initValue();
SalesTable.initFromCustTable(ct);
...
SalesTable.insert();

И по старинке считал, что ax-классы используются сугубо в web-сервисах для доступа к таблицам. Но судя по наблюдаемому коду, это не так.

==================
Вопрос: а в чем преимущество ax-классов? в чем была задумка авторов, которые придумали эти соглашения по ax-классам?

[Михаил Андреев]

Попробуй сделать заказ типа "Заказ" при работе с классами AxSalesTable и AxSalesLine, и напрямую, через таблицы. В первом случае, все складские проводки классы сами сделают, а во втором случае....

[mazzy]

Цитата:

Сообщение от Михаил Андреев

Попробуй сделать заказ типа "Заказ" при работе с классами AxSalesTable и AxSalesLine, и напрямую, через таблицы. В первом случае, все складские проводки классы сами сделают, а во втором случае....

во втором - тоже
см. метод SalesLine.insert()

[kornix]

Подобные классы использовал всего несколько раз.
При написании кода в C# вызывать один класс через bc.net проще чем объявлять все необходимые объекты, а потом обрабатывать их. Если приложение стандартное - этими классами удобно создавать заказы/закупки и т.п.
На мой взгляд - классы нужны для внешних приложений, создаваемых в C# и работающих через .Net Business Connector.

[fed]

У меня такое ощущение, что эти классы разрабатывал какой-то выходец из .net-программирования и он пытался сэммулировать привычное наследование для таблиц. Потом в рамках какой-то группы (кажется - EP), использование этих классов вместо таблиц стало стандартом разработки. Но рефакторить остальной код никто не стал, да и другие группы этими классами не пользуются. Так что, на мой взгляд, большого смысла в использовании этой функциональности - нету...
Кстати - интересно как в 2012 с использованием этих классов...

[mazzy]

Цитата:

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

большого смысла в использовании этой функциональности - нету...

"Этой" - какой именно? ax-классов или работой напрямую с таблицами?

Конкретизирую вопрос:
В чем преимущество ax-классов перед непосредственной работой с таблицами ВНУТРИ самой аксапты?

[kornix]

Цитата:

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

"Этой" - какой именно? ax-классов или работой напрямую с таблицами?

Конкретизирую вопрос:
В чем преимущество ax-классов перед непосредственной работой с таблицами ВНУТРИ самой аксапты?

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

[mazzy]

Цитата:

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

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

В будущем? А сейчас какое преимущество?

Цитата:

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

2. Удобнее управлять местом выполнения кода: клиент или сервер.

Зачем? таблицы живут только на сервере.

Цитата:

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

3. Возможность написания более "объектно-ориентированного" кода.

э-э-э? это точно не маркетинговый булшит?

[kornix]

1. Ага, только в будущем
2. Имел ввиду ситуации, как, например, вызов табличного метода из формы. Если в методе написана какая-то логика - она будет выполняться на клиенте. А если вызывать класс - можно выполнить то же на сервере.
3. По идее, если вызывать отовсюду axSalesTable.insert() вместо salesTable.insert() - получается что вставкой записи уже управляет класс. Его удобно дорабатывать, в отличии от модификации табличных методов, которые обычно сильно раздуваются.

P.S.: Согласен с fed, лучше использовать Type классы (SalesLineType и т.п.). Если начать активно использовать ax классы изнутри - это как минимум будет резать глаз и сразу вызывать вопросы

[fed]

Цитата:

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

Зачем? таблицы живут только на сервере.

Насколько я помню, таблицы живут на том уровне, на котором был выполнен первый select или первый insert. То есть - если у тебя таблица на форме, то все нестатические методы будут вызываться на клиенте.

[fed]

Цитата:

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

"Этой" - какой именно? ax-классов или работой напрямую с таблицами?

Конкретизирую вопрос:
В чем преимущество ax-классов перед непосредственной работой с таблицами ВНУТРИ самой аксапты?

Этой - работы с классами.
Мне кажется - никакого преимущества нету. В принципе - можно для своих новых таблиц наделать аналогичных классов, и некоторую функциональность выкинуть в базовый класс axInternalBase. Но класс этот и так уже достаточно помоечный, и мне кажется что правильнее использовать паттерн с методом type() таблицы, который возвращает соответствующий класс. Можно даже табличное наследование ограниченное реализовать, если у тебя в базовой таблице есть поле типа и метод type() ищет соответствущую таблицу с данными подтипа и в ней вызывает метод type().

В общем - IMHO - за исключением узкой задачи сериализации документов, эти классы не функциональны.

Цитата:

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

Вопрос скорее на понимание.

В последних версиях есть ax-классы, которые являются обертками вокруг соответствующих таблиц. (axSalesTable, axSalesLine, axCustTable, axLedgerJournalTrans и т.п.)

Я как-то привык по старинке работать непосредственно с таблицами.

SalesTable.clear();
SalesTable.initValue();
SalesTable.initFromCustTable(ct);
...
SalesTable.insert();

И по старинке считал, что ax-классы используются сугубо в web-сервисах для доступа к таблицам. Но судя по наблюдаемому коду, это не так.

==================
Вопрос: а в чем преимущество ax-классов? в чем была задумка авторов, которые придумали эти соглашения по ax-классам?

Преимущество в том, что кроме самой табличной переменной, там есть инфа о toched полях. вот и всё
они в AIF вроде еще используются.

[mazzy]

Цитата:

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

Преимущество в том, что кроме самой табличной переменной, там есть инфа о toched полях. вот и всё
они в AIF вроде еще используются.

да, а зачем это ВНУТРИ аксапты?

всю жизнь пользовался проверкой bufcmp(record,record.orig()) для определения, что запись изменена.

или record.field == record.orig().field для определени измененности поля.

зачем нужен этот toched?

[mifi]

Цитата:

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

да, а зачем это ВНУТРИ аксапты?

всю жизнь пользовался проверкой (record.data() == record.orig().data) для определения, что запись изменена.

или record.field == record.orig().field для определени измененности поля.

зачем нужен этот toched?

Mazzy - ну написали люди классы ВНУТРИ AX, теперь пользуются ими внутри AX, что здесь такого? Оба способа приемлимы, так что это дело вкуса и привычки.

[mazzy]

Цитата:

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

Mazzy - ну написали люди классы ВНУТРИ AX, теперь пользуются ими внутри AX, что здесь такого? Оба способа приемлимы, так что это дело вкуса и привычки.

mifi, я верю. и не спорю, что приемлемы.

я хочу ПОНЯТЬ - что побудило их написать?
и что лучше использовтать в текущей версии аксапты?

практический смысл вопроса очень простой:
= надо ли заморачиваться и делать ax-обертки для своих таблиц/полей?
= нало ли заморачиваться и требовать от локализации наличия таких ax-оберток?

=================
кстати, не согласен насчет вкуса и привычки.
для многих таблиц и полей локализации ax-обертки отсутствуют.
кастомизированные таблицы/поля с огромной вероятностью не имеют оберток.

[gl00mie]

Цитата:

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

IMHO - за исключением узкой задачи сериализации документов, эти классы не функциональны.

Ага... читаем "What's New - Technical in Microsoft Dynamics AX 2012 for Development" про мечту 95% пользователей Аксапты (выделение курсивом - мое):

Цитата:

Редактирование данных в Excel
За счет использования Microsoft Dynamics AX 2012 Office Add-ins редактировать можно будет любые данные, опубликованные в виде доступного сервиса. Для этого подключитесь к AOS, укажите нужный сервис, перетащите поля, которые вас интересуют, в книгу Excel, обновите данные, чтобы заполнить книгу, затем отредактируйте их и нажмите кнопку, чтобы отразить изменения в системе. Редактирование данных в Excel включает следующие возможности:

• Интеграция с сервисами документов. Информация из любого сервиса может быть прочитана, изменена и обновлена в AX 2012 с полной поддержкой контроля доступа и сопутствующей бизнес-логики.
• Office Add-ins используют lookup'ы и инфраструктуру запросов из AX 2012.
• Можно определить матричные поля для агрегирования данных. При сохранении измененных значений матричных полей поля всех записей, на основе которых были получены агрегированные значения, будут пропорционально изменены.
• etc.

Цитата:

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

В чем преимущество ax-классов перед непосредственной работой с таблицами ВНУТРИ самой аксапты?

Тут можно вспомнить Программирование и конфликты 2.0 Роберта Гласса:

Цитата:

С точки зрения учебного процесса наука состоит из фундаментальных принципов, которые можно выделить и изучать и которые являются истинными. Каковы основополагающие начала программной инженерии? Некоторые говорят, что программная инженерия – это «гуманитарная наука», что не так-то просто установить ее основополагающие начала.
Я хотел бы предложить свой вариант. Моим кандидатом на роль основополагающего начала программной инженерии выступает понятие, которое мой коллега Ли Макларен (Lee MacLaren) из компании Boeing Military Aircraft называет «однототочечным управлением» (single-point control).
При такой организации вычислений задача, которая должна решаться в нескольких местах, решается только в одном, а во всех остальных местах на это одно лишь ссылаются при необходимости. В качестве самого распространенного примера такого управления можно привести программный модуль, например, библиотечную подпрограмму. Если нам требуется извлечь квадратный корень или выполнить сортировку в нескольких местах в программе, то мы не пишем всякий раз один и тот же программный код, решающий эту задачу. Этот код мы располагаем в каком-то одном месте и обращаемся к нему (вызываем его) по мере необходимости.
Почему мы это делаем? Конечно, потому, что такой код занимает меньше места. Разумеется, потому что это упрощает программную логику. И потому, что если необходимо изменить программный код, то это достаточно сделать один раз.

В Программисте-прагматике этот принцип называется DRY (don't repeat yourself). Бизнес-логика должна быть реализована в одном месте приложения, а не продублирована в куче мест, и при этом ее должно быть удобно использовать из других различных мест приложения (или даже из сторонних интегрируемых с приложением систем). При работе с теми же табличными данными через интерфейс клиента Аксапты очень просто реализовать бизнес-логику на основе вызываемых этим клиентом стандартных обработчиков modifiedField/validateField, при этом за счет интерфейса можно ограничить пользователя в том, в каком порядке и какие поля он сможет изменять. Когда же требуется проделать то же самое из кода, то с точки зрения разработчика таблицы порядок заполнения полей контролировать нельзя, равно как и нельзя обеспечить соответствующие вызовы modifiedField (в результате чего могут вызываться initFromXX). Получается, бизнес-логику нужно дублировать и поддерживать два разных "API": один - для работы через интерфейс (который не позволит выбрать договор, пока не задан тот же код клиента, и который приведет к вызову initFromCustTable() при смене кода клиента), а другой - для работы из кода, где нужно помнить, что сперва надо вызвать clear(), затем initValue(), затем - initFromCustTable(), после этого дернуть transferContractAccount_RU() и указать ему, чтобы не задавал лишних вопросов... Если напутать с порядком вызова методов, то установленные вами значения будут перезаписаны, и на выходе получится не то, что вы ожидали, если не дернуть вообще нужный обработчик, то не подтянутся значения связанных полей ("эй! мы всю жизнь просто заполняли одно это поле из кода - и все, откуда взялись связанные с ним поля?"). А так можно просто "набросать" те значения полей, которые известны, причем в любой последовательности, дернуть нужный обработчик - и он "размотает" всю логику заполнения записи и вызовет нужные обработчики в том порядке, в каком надо, а за счет пометки "тронутых" нами полей их значения гарантированно не будут перезаписаны в ходе этого процесса.

Цитата:

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

я хочу ПОНЯТЬ - что побудило их написать?

Сторонние системы не заставишь дергать все специфичные для Аксапты обработчики (с учетом того, что поля не обернуты в свойства со своими get/set) и/или заполнять поля в определенном порядке, а бизнес-логика приложения Аксапты при этом должна как-то отрабатывать. По-моему, из-за этого и решили нагромоздить все эти классы.

Цитата:

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

практический смысл вопроса очень простой:
= надо ли заморачиваться и делать ax-обертки для своих таблиц/полей?
= нало ли заморачиваться и требовать от локализации наличия таких ax-оберток? для многих таблиц и полей локализации ax-обертки отсутствуют.
кастомизированные таблицы/поля с огромной вероятностью не имеют оберток.

На первый вопрос, по-моему, нет однозначного ответа: реализация ax-оберток для таблиц довольно трудоемка и потому не всегда оправдана. Что же касается второго вопроса - по-моему, однозначно надо этим заморачиваться Иначе получается, что без доработки напильником достаточно мощных стандартный механизм нельзя использовать для таблиц, затронутых локализацией.

[mifi]

Цитата:

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

mifi, я верю. и не спорю, что приемлемы.

я хочу ПОНЯТЬ - что побудило их написать?
и что лучше использовтать в текущей версии аксапты?

практический смысл вопроса очень простой:
= надо ли заморачиваться и делать ax-обертки для своих таблиц/полей?
= нало ли заморачиваться и требовать от локализации наличия таких ax-оберток?

=================
кстати, не согласен насчет вкуса и привычки.
для многих таблиц и полей локализации ax-обертки отсутствуют.
кастомизированные таблицы/поля с огромной вероятностью не имеют оберток.

Mazzy - сам же изначально написал, что
"И по старинке считал, что ax-классы используются сугубо в web-сервисах для доступа к таблицам". Что в общем, верно, написаны они были для движка интеграции. Что не запрещает их использовать для каких-либо других целей.
Что касается локализации - по идее, обработка полей локализации должны присутствовать в классах-обертках системных таблиц, куда эти поля были добавлены. Что же касается таблиц локализации - то, если есть сценарии интеграции с их участием, обращайся к известным тебе людям, думаю, тебя услышат

[mazzy]

Цитата:

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

есть инфа о toched полях

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

[Wamr]

После того как познакомился с сериализацией (перевод объектов в XML) в .Net решил, что ax-классы - это промежуточный слой позволяющий без лишнего кодирования(?) получать из записей таблиц XML-документы и обратно из XML данные.
Естественно, при получении данных должна проходить какая-то обработка, которая и была реализована. В результате получились 2 механизма работы с данными. В DAX делались шаги по их объединению, но как-то это не стало "новой политикой" разработки повсеместно, да и поддерживать механизмы интеграции, если не планируешь их использовать получается накладно.

[erudit]

Так называемые AxBC-классы (с префиксом Ax) появились в AX 4.0 вместе с Axd-классами, как основа нового модуля AIF (Application Integration Framework).
AIF c Axd-документами пришёл на смену Commerce Gateway с XCBL схемами из Axapta 3.0, который не оправдал себя ввиду сложности добавления новых документов.
Axd-классы вместе с AxBC позволили легко добавлять и управлять новыми XML-документами для обмена данными между AX и другими системами (к примеру, в Axapta 3.0 Commerce Gateway - было всего 3 стандартных документа, в AX 4.0 AIF - 21, а в AX 2009 - уже 58).
Основная задача AxBC классов - управление defaulting'ом:
"
In order to solve intra-table field relations, where a table field should be defaulted to a specific value, when the value of another table field changes
"
Ранее упомянутая технология touched - используется для определения, было ли данное поле изменено ранее, и если да, то defaulting его не тронет. Это принциальное отличие от использования к примеру метода modified() на таблице, где легко перезаписать уже имеющиеся данные. К примеру, если вы получаете от клиента через AIF sales order (AxdSalesOrder-документ), из XML-файла в класс AxSalesLine передаются данные, скажем ItemId и SalesQty, и все остальные поля будут заполненны благодаря defaulting-функциональности AxSalesLine, но поле SalesQty - измененно не будет и сохранит данные из XML - такое стандартными средствами таблиц не сделаешь.
Также много других мелких положительных ньансов в использовании AxBC-классов в AIF, а не таблиц напрямую. К примеру, можно делать подмену значений прямо на лету (internal -> extrnal value и т.п.), что активно используется в InterCompany (заметьте - AxBC-классы предназначены только для использования в AIF или InterCompany, больше нигде).