Цитата:
Сообщение от
Владимир Максимов
Насколько я понимаю, указание "Tmp" в имени объекта призвано подчеркнуть тот факт, что временная таблица - это объект приложения отличный от собственно таблицы. Другой тип объектов.
Стоит напомнить, что любая "обычная" таблица может стать временной либо за счет манипуляций в коде, либо за счет отключения конфигурационного ключа, к которому она привязана. Так что указание "Tmp" в названии таблицы служит лишь для того, чтобы проще было отличать "перманентно временные" таблицы от "конфигурируемо временных".
Цитата:
Сообщение от
Владимир Максимов
Однако по каким-то причинам разработчки Axapta не хотят или не могут довести это выделение до логического конца и выделить этот тип объектов в отдельную ветку AOT, как это было сделано с Maps и Views.
Ни разу это не другой тип объектов: свойства, поля, индексы, методы - все то же самое. Раньше времянки еще в базе не хранились, так в 2012-й появился тип временных таблиц, хранящихся в tempdb - и где же другой тип? Стоит напомнить также, что с точки зрения Dict-классов Map, View, обычная и временная таблица отличаются друг от друга лишь парой свойств. "Не умножайте сущности без необходимости".
Цитата:
Сообщение от
Владимир Максимов
Вот Best Practices и предлагает разработчикам делать это выделение в "отдельную ветку" AOT "вручную" используя специальный способ именования подобных объектов. Ведь если следовать рекомендациям Best Practices именно это и получится. Все временные таблицы будут сгруппированы в одном месте (в разрезе модулей), как если бы они были выделены в отдельную ветку AOT.
Если следовать рекомендациям Best Practices, получим группировку таблиц, во-первых, по модулю, во-вторых, по тому, является ли таблица "перманентно временной" или же "конфигурируемо временной". Раньше с точки зрения Best Practices приоритетность группировки была иной.
Цитата:
Сообщение от
Владимир Максимов
В пользу подобного предположения говорит тот факт, что для именования View тот же Best Practices рекомендует использовать именно окончание "View", а для именования MAP вообще нет каких-либо рекомендаций, хотя многие MAP имеют соответствующее окончание. Т.е. если объекты уже выделены в отдельную ветку AOT, то используется именно окончание, а не prefix или infix, поскольку это, очевидно, удобнее для разработчика.
Все проще: "map" и "view" - это существительные, а tmp - сокращение от прилагательного. В английском языке, как уже отмечалось, существительные в предложениях принято ставить после относящихся к ним прилагательных, поэтому "map" и "view" - суффиксы, а "tmp" - infix; если бы в именование объектов приложения Аксапты была заложена грамматика, скажем, французского языка, то и Best Practices по именованию объектов были бы совсем иными
Опять же, обратите внимание, что "map", "view" и таблица - это
разные сущности (существительные), в то время как "temporary" - это лишь
свойство сущности (прилагательное).
Цитата:
Сообщение от
Владимир Максимов
Рекомендация Best Practices о наименовании временных таблиц имеет смысл, если предполагается выполнение неких групповых операций с однотипными объектами именно в AOT. Не в программном коде, а непосредственно в дереве объектов. Или я ошибаюсь в своих предположениях?
По-моему, это заблуждение. Best Practices по именованию объектов приложения призваны решить задачу отражения в имени разнородных способов классификации объектов (для тех же таблица - принадлежность к модулю, "перманентно временная" или "конфигурируемо временная", тип содержимого - справочник, группы, транзакции, etc.), да еще с учетом грамматики английского языка - и Best Practices предлагают вполне приемлемое решение этой задачи. Не стоит пытаться искать в Best Practices по именованию объектов приложения какие-то недомолвки и намеки - это противоречит их сути.
Цитата:
Сообщение от
Владимир Максимов
Если эти операции не имеют отношения к процессу разработки, может, лучше не следовать рекомендациям Best Practices в данном случае?
Еще одна ценность следованию Best Practices - облегчение другим программистам, знакомым с ними, понимание кода и вообще модификаций, хотя насколько эта возможность ценна, каждый решает для себя сам.