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

[gl00mie]

Цитата:

Сообщение от 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]

Спасибо. Круть.

Цитата:

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

При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX.

о_О!

Цитата:

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

Провокация какая-то

Цитата:

Сообщение от 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?
какие ограничения? при каких условиях это допустимо, а при каких нет?