В чем преимущество 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. Возможность написания более "объектно-ориентированного" кода.

[fed]

Цитата:

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

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

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

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

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

[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. То есть - если у тебя таблица на форме, то все нестатические методы будут вызываться на клиенте.

[mazzy]

Цитата:

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

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

так вроде было раньше.
в ax2009 все таблицы живут на сервере.

[mifi]

Цитата:

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

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

Первый insert - это правило относится только к временным таблицам. Второе предложение никак не связано с первым, на самом деле Интересно также понять, как на клиенте отрабатывает нестатический метод insert(), куда именно он вставляет данные, если таблица постоянная

[fed]

Цитата:

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

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

Кстати - если уж очень хочется поместить сложную логику в табличный insert(), то надо в нем вызывать this.type().insert() (не вызывая super()), а в методе insert() соответствующего класса, тупо вызывать table.doinsert(). Так, помниться, вставка в строки заказов и закупок отрабатывает...

[fed]

Цитата:

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

Первый insert - это правило относится только к временным таблицам. Второе предложение никак не связано с первым, на самом деле

Угу - спасибо что напомнил.

Цитата:

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

Интересно также понять, как на клиенте отрабатывает нестатический метод insert(), куда именно он вставляет данные, если таблица постоянная

Ну вставит он конечно в таблицу БД. Но мне казалось что в этом случае, если логика метода insert() переопределена, то она будет на клиенте отрабатывать ?

Цитата:

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

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

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

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

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

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

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

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

[mifi]

Цитата:

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

Угу - спасибо что напомнил.

Ну вставит он конечно в таблицу БД. Но мне казалось что в этом случае, если логика метода insert() переопределена, то она будет на клиенте отрабатывать ?

Нет, метод будет исполнен на сервере.

[mazzy]

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[mifi]

Цитата:

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

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

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

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

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

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