AX 2012: Правила именования объектов

[mazzy]

Цитата:

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

Вопрос к тем, кто может быть в курсе изменения политики именования объектов. Какие теперь существуют правила именования объектов и по какому принципу можно догадываться о предназначении того или иного объекта?

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

могу ошибаться, но мне кажется, что сейчас аксапту пишут те, кто плохо знает функционал старых версий и имеющиеся политики.

[sukhanchik]

Цитата:

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

Термин "entry" (точнее, фраза "journal entry") обычно обозначает запись журнала в учёте. Это касается как бухгалтерских проводок, так и всех остальных, например, складских.
ИМХО, Entry заменило слово Trans для журналов.

Ок, я не против смены терминов - лишь бы они были заменены везде .

Цитата:

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

Короче, надо документацию искать. Наверняка, это описано где-то.

А вот тут я категорически возражаю . Ну не было в природе такой документации по 3.0 (не считая конечно красивых файликов по локализации, которые рисовал EVGL). И это не мешало разбираться в системе. А теперь получается - что без документации - мешает.

Цитата:

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

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

могу ошибаться, но мне кажется, что сейчас аксапту пишут те, кто плохо знает функционал старых версий и имеющиеся политики.

А вот это увы четко прослеживается . Я просто думал (в душе надеялся), что люди, которые плохо знают функционал предыдущих версий все-таки будут стараться изобрести некую свою систему именования. Пусть заменят Trans на Entry. Пусть еще что-нибудь заменят. Но оставят (или придумают свой) принцип именования объектов. Важно! Который бы был и которому бы придерживались. Ведь смогли разработчики еще тогда аксапты (в далеком 19хх году) внедрить такой принцип при построении системы - чем разработчики в МС хуже?

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

Цитата:

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

А вот тут я категорически возражаю . Ну не было в природе такой документации по 3.0 (не считая конечно красивых файликов по локализации, которые рисовал EVGL). И это не мешало разбираться в системе. А теперь получается - что без документации - мешает.

Как это "не было"? Было. Другое дело, что кусками.
Вот, например, цитата:

Axapta standard

Prefix: "Tmp" for temporary tables + Module short name, for example TmpCustLedger.
Infix: Logical description of contents, for example CustCollectionLetterTrans.
The postfix typically denotes the type of contents, for example *Trans, *Jour, *Line.
The primary tables for the major business areas are postfixed with the word “table”.
Examples are
CustTable
InventTableLedgerTable
ProjTable
VendTable
VendTrans


Не помню, где-то ещё видел...

[sukhanchik]

Цитата:

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

Как это "не было"? Было.

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

[MikeR]

Коллеги бы же документ AX40datamodel_ru.doc.
В нем общие модули описывались.
Где бы получить новый документ по 2012?
Я бы перевел...

[fed]

Цитата:

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

Коллеги бы же документ AX40datamodel_ru.doc.
В нем общие модули описывались.
Где бы получить новый документ по 2012?
Я бы перевел...

Документ ax40datamodel был результатом одноразового творчества американского MBS-C (то есть - не разработчиков, а консалтеров). Насколько я знаю, какой-то американский клиент поднял бучу на тему отсутствия документации по таблицам и модели данных и, как следствие, невозможности применять разрекламированный Business Intelligence. После этого были выделены некоторые фонды на документирование, которые были переданы MCS, который, в свою очередь, породил эту документацию. Которую потом Ваня Кашперук опубликовал у себя в блоге.
То есть - это не было частью нормального релиза программного продукта, а просто некоторым экстроординарным проектом, предпринятым только для того чтобы успокоить конкретного клиента.
Так что я бы не стал ждать чего-то подобного для очередной версии. (Могу ошибаться).

[sukhanchik]

Цитата:

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

Коллеги бы же документ

Документ был по 4.0 и разовый, как верно заметил fed. Но не по 3.0

[George Nordic]

Цитата:

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

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

Сергей. Разработчики могут называть объекты, как им заблагорассудится. На то и ставят ведущих, которые обучают новичков и контролируют качество кода и соблюдение BestPractises. А когда дело касается столь существенных изменений, то всем заправляет Архитектор Системы - именно он отвечает за правильную работу всей функциональности, корректность взаимосвязей и т.п. И я не верю, что на таком уровне может твориться подобный бардак. Или так было задуманно специально, и последуют изменения ВР в части именования объектов, или дело не в разработчиках, а в архитекторах. Но это было бы крайне печально....

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Разработчики могут называть объекты, как им заблагорассудится. ...
И я не верю, что на таком уровне может твориться подобный бардак.
Или так было задуманно специально, и последуют изменения ВР в части именования объектов, или дело не в разработчиках, а в архитекторах.

Могут.
А я - верю.
Если сделано специально, то какой смысл в ТАКОМ изменении?

[fed]

Цитата:

Сообщение от George Nordic

Сергей. Разработчики могут называть объекты, как им заблагорассудится. На то и ставят ведущих, которые обучают новичков и контролируют качество кода и соблюдение BestPractises. А когда дело касается столь существенных изменений, то всем заправляет Архитектор Системы - именно он отвечает за правильную работу всей функциональности, корректность взаимосвязей и т.п. И я не верю, что на таком уровне может твориться подобный бардак. Или так было задуманно специально, и последуют изменения ВР в части именования объектов, или дело не в разработчиках, а в архитекторах. Но это было бы крайне печально....

С Уважением,
Георгий

Проблема в том, что Архитектор в Микрософтовской разработке не отвечает за такие мелочи. Архитектор в микрософтовской разработке, это такой профессиональный балабол (с окладом на уровне GM), который не за конкретные вещи, а только за СТРАТЕГИЮ. Типа - поддерживаем ролеориентированный интерфейс, делаем интеграцию с WEB, интегрируемся за Visual Studio, нормализуем таблицы и тп. А как на практике это воплощается - это архитектора не колышет. Ты ведь помнишь анекдот про то как мышки к сове пошли за советом ? "Это тактика, а я только стратегическими вопросами занимаюсь". Вот и получается что нанятые по объявлению C#-программисты (без опыта внедрений и знания аксапты), под руководством програм манагеров (которые в разработке не разбираются как правило, ибо это постановщики, зачастую тоже без опыта внедрений) и напрограммировали то, что нас сейчас ожидает с выходом 2012 версии.