AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.10.2010, 14:31   #21  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1409 (52) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Цитата:
Сообщение от pitersky Посмотреть сообщение
Это сразу покажет, какие именно объекты нестандартные
Слои.

Цитата:
Сообщение от pitersky Посмотреть сообщение
обезопасит от возможных перекрытий имён при переходе на новые версии продукта.
Есть хоть один реальный пример пересечения? Много такого? Как по мне, так риски и трудозатраты на исправление, если даже ситуация возникнет, минимальны. И как правильно заметили выше, "Если логика программиста вдруг совпала с логикой от МС - то это повод задуматься об удалении /изменении собственного кода"!

Цитата:
Сообщение от pitersky Посмотреть сообщение
Название проекта должно начинаться с префикса-идентификатора разработчика.
Зачем? Разработчик должен быть указан в коде. Проект тоже удобно искать используя стандартный Naming Convention с названием модуля в его начале и так далее. А в вашем случае придется несколько раз сканировать. И все ради чего?

Кстати, ужасно раздражает, когда в название проекта в виде префикса зашивается не только код заказчика (это как раз правильно), но и внутренний номер модификации.
__________________
С уважением,
Олег.
Старый 06.10.2010, 14:40   #22  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от oip Посмотреть сообщение
По коду всегда должно быть сразу понятно, кто, когда и зачем его писал. У вас код не помечается меткой, в которой указан разработчик, дата, код проекта и желательно название модификации?
помечается.

но бывают вариант когда по каким то причинам метки такой нет. (разработчик забыл, забил или ещё что то)

ещё раз хочу обратить внимание, я против суфиксов и префиксов. просто предположил, что единственный случай когда, на мой взгляд, можно как то попробовать объяснить их присутствие это обозначение компании (клиента).
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 06.10.2010, 14:49   #23  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Гм. Я тоже пожалуй выскажусь.
Во первых - я, в целом, негативно отношусь и к префиксам и к суффиксам. Читаемость кода они, однозначно, снижают, а легкость апгрейда повышают весьма незначительно.Кроме того, в большинестве случаев, никакого апгрейда в наших условиях не бывает, а бывает перевнедрение. Нет, есть конечно исключение, но если на проекте было так много доработок что стали префиксы/суффиксы использовать - значит там над аксапточкой надругались настолько сильно и противоестественно, что никакого апгрейда там точно не случиться.

Использование кодов имени программиста, партнера или кода проекта в качестве префикса/суффикса - однозначный тупик. Классический пример попытки решения организационной проблемы (плохого разграничения ответственности между разработчиками или партнерами) с помощью программных механизмов. Причем попытки заведомо неудачной. Если в качестве префикса/суффикса используется код клиента (типа у партнера три клиента и для каждого свой префикс), то это вообще верх демонстрации неуважения к клиенту. Какое мне дело, что у моего партнера еще 4 проекта и его программеры запутались в собственных доработках?
Я считаю допустимым (и наверное иногда даже полезным) использование префикса модуля, но только в том случае если модуль большой, достаточно отдельно стоящий (а не состоящий из кучи дополнений к штатным таблицам и формам) и более или менее переносимый...

Удалять префиксы из существующего приложения как отдельную задачу - я бы не стал. Если вы там какой-то кусок в порядок приводите - то удалите. Если переносите более или менее в лоб - пусть остаются, эти префиксы противные, но не страшные...
За это сообщение автора поблагодарили: sukhanchik (2), oip (2), _scorp_ (2).
Старый 06.10.2010, 14:51   #24  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
На самом деле мы уже говорим, когда в системе все хорошо, в первую очередь архитектура приложения и бизнес процессы, тогда можно браться за префиксы. Просто был на проекте, где некий архитектор вычесывал блох типа, что надо писать в validateWrite, а не во Write и так далее. А в архитектуре была просто разруха. Весь модуль состоял из четырех-пяти таблиц с одинаковым набором полей и при записи в одну таблицу шла длинная очередь записи в другие. Не учитывались возможные блокировки, транзакции, наследование и так далее.
Использование префиксов говорит о том, что разработчик со стажем и более ничего. При нынешних технологиях можно, конечно, обойтись и без этого. Но на мой взгляд - это не главное с чем стоит боротся.
__________________
Axapta book for developer
Старый 06.10.2010, 14:53   #25  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
чтобы лишний раз сказать клиенту - что вам впарили код с такого-то клиента
Работаю на клиенте. Компания-внедренец в своих объектах (которых немало, т.к. это тиражируемое отраслевое решение) ни префиксы, ни суффиксы не использует. Однако дисциплинированность в комментариях их программмистов легко позволяет обнаружить в нашем приложении коды для нескольких других предыдущих клиетов. (Да и я свои принес, чего уж там).

Лично я - сначала предпочитал использовать префиксы, причем только в именах объектов (но ни в коем случае не в полях таблиц). Потом мнение изменил. Сейчас префикс (идентифицирующий компанию) использую, но только в именах классов специально написанных тут на клиенте отчетов, и более нигде. Так показалось удобнее с ними работать, так как таких отчетов уже под сотню (!), дорабатывать приходится часто (или писать новые на основе предыдущих), и так легче их искать, так как они в классах АОТ лежат рядышком, с одним префиксом.

Рефакторинг - в общем случае я бы не стал делать, не стоит того. В частном случае - делал, когда перенёс ряд доработк (в основном отчеты) с предыдущего проекта (почившего вместе с компанией-заказчиком, так что совесть чиста), имевшие префикс заказчика. Естественно, переделывал на другой префикс (попутно рефакторил код под реалии нового заказчика).

Последний раз редактировалось Zabr; 06.10.2010 в 15:00.
Старый 06.10.2010, 14:59   #26  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
На мой взгляд, префиксы с кодом клиента очень даже полезны. Как раз в случае "тиражируемых решений" часто есть соблазн продать модификацию сразу 2 клиентам, хотя в договоре прописано, что код остается в собственности первого клиента. Если в этой модификации теперь поменяем XX_ на YY_, то чисто формально код окажется разным, и придраться будет труднее.
Старый 06.10.2010, 15:05   #27  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1409 (52) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
EVGL, то есть префикс делать для того, чтобы потом можно было в будущем попытать с чистой совестью обмануть клиента? Кстати, сильно сомневаюсь, что в случае каких-то судебных разбирательств измененние префексов будет признано достаточным условием для того, чтобы код не считался собственностью клиента, если такое условие в договоре прописано. С таким же успехом можно просто в коде делать метки с названием клиента, а потом для следующего клиента производить их автозамену на новые.
__________________
С уважением,
Олег.
Старый 06.10.2010, 15:06   #28  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
После того как таких объектов переваливает за 5 штук - это становится неудобным (см мой пост про XXX_InventJournalTable и YYY_InventJournalTable) и ненужным (уже смотрится на модуль)
Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.
Цитата:
Сообщение от mazzy Посмотреть сообщение
компании клиента или компании разработчика?
а почему не суффикс?
клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект.
почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки
Цитата:
Сообщение от oip Посмотреть сообщение
Есть хоть один реальный пример пересечения? Много такого? Как по мне, так риски и трудозатраты на исправление, если даже ситуация возникнет, минимальны.
Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.
__________________
С уважением,
Вячеслав

Последний раз редактировалось pitersky; 06.10.2010 в 15:45.
Старый 06.10.2010, 15:23   #29  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от EVGL Посмотреть сообщение
На мой взгляд, префиксы с кодом клиента очень даже полезны. Как раз в случае "тиражируемых решений" часто есть соблазн продать модификацию сразу 2 клиентам, хотя в договоре прописано, что код остается в собственности первого клиента. Если в этой модификации теперь поменяем XX_ на YY_, то чисто формально код окажется разным, и придраться будет труднее.
Почему-то сразу вспомнился Коламбус 1999-2001 годов
Старый 06.10.2010, 15:43   #30  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
По-моему - префиксы/суффиксы совершенно бесполезная штука. Где я ошибаюсь?
Использую префиксы для обособленно созданных модулей, типа Reports...... Не очень удобно, но так как отсутствует понятие пакетов (неймспейсов или как там их еще) приходится пользоваться этим.

Для других разработчиков удобно - так как они сразу видят, что это мое и со всеми вопросами надо подходить ко мне. Мне удобно финальный проект собирать.

Из минусов - увеличивается количество символов при декларации переменных в коде.

Естественно префикс использую только для именования элементов АОТ. В наименовании полей, методов и прочих элементов n-го уровня вложенности префиксы не использую.
Старый 06.10.2010, 15:46   #31  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Стоит ли рефакторить приложение избавляясь от кодов разработчиков/компаний?
Меня, кстати, в этом случае больше интересует моральный и этический аспекты. То есть, я правильно понял, что мы просто берем чужой модуль и стираем в нем префиксы, который по сути является единственным признаком авторского права разработчика?
За это сообщение автора поблагодарили: titov (2).
Старый 06.10.2010, 15:48   #32  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
мне кажется логично использовать префикс компании (клиента) в своих костомизациях
Мне этот подход не очень нравится, ибо система контроля версий рулит, но этого часто требует заказчик. Префикс, как идентификатор разработчика, теряет свой смысл как только с объектом поработало несколько разработчиков (компаний).
Старый 06.10.2010, 15:50   #33  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Что мешает делать префикс у кода проекта?
Количество Shared проектов сильно ограничено и нам приходится периодически их удалять.
Старый 06.10.2010, 15:53   #34  
titov is offline
titov
Участник
 
73 / 87 (3) ++++
Регистрация: 23.12.2005
Адрес: Казань
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Если логика программиста вдруг совпала с логикой от МС - то это повод задуматься об удалении /изменении собственного кода.
Вывод - свой код и код от МС тут хорошо "скрестить" и этто повод делать делать не потом "генеральную уборку", а сразу не мусорить за собой.
По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы...
Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму - по функциям коду и принимать решение о слиянии (удалении своих). Здесь еще плюс есть - приложение уже работоспособно сразу после перехода (ну почти сразу). А без преффиксов\суффиксов - в двух местах - есть два варианта развития событий. И приложение с ошибками!

еще момент - а если код партнера\клиента лучше MS DAX ? пройтись по своим классам и переименовать + код по ссылкам - то есть обратные действия?

А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало?
Вот именно - нужны дополнительные действия.

В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.

еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.

и еще - практикуется продажа решений айти компаниями - суффиксы объектов в таких проектах хро очень даже кстати. И не всегда сразу ясно, что будет решение при начальном создании объектов.
Старый 06.10.2010, 16:30   #35  
_scorp_ is offline
_scorp_
Участник
Аватар для _scorp_
MCBMSS
 
488 / 369 (13) ++++++
Регистрация: 25.07.2007
Адрес: Москва
Вопрос уже не раз поднимается. Всегда пишут, что раньше по BP нужно было использовать префиксы, а теперь суффиксы. Но где в данный момент находятся актуальные рекомендации? Тут вообще нет ни слова не про одно не про другое.
Цитата:
General Rules
All names must be in U.S. English.

The default rule is to use logical and descriptive names if no other specialized rules apply.

Identifier names have a limit of 40 characters.

Names in the Application Object Tree (AOT) and in X++ code must correspond to the names in the U.S. English user interface.

Names must be spelled correctly.

Names must be used consistently.

Each path in the AOT must be unique; nodes must not have identical names.

All texts that appear in the user interface must be defined by using a label. (This rule applies only if you want your solution certified as an international solution.)

Do not begin a name with "aaa", or "CopyOf". Do not begin a name with "DEL_" unless it is a table, extended data type or enum, and it is needed for data upgrade purposes. Names that use these prefixes cause a best practices error when you check the objects into the version control system.
Цитата:
Where possible, application object names should be constructed hierarchically from three basic components:

{business area name} + {business area description} + {action performed (for classes) or type of contents (for tables)}
Может это означает, что по BP их(префиксы/суффиксы) уже не нужно использовать?
Старый 06.10.2010, 16:41   #36  
wb is offline
wb
Участник
 
86 / 16 (1) ++
Регистрация: 26.01.2004
Адрес: Краснодар
Цитата:
Сообщение от mazzy Посмотреть сообщение
Но рано или поздно по ним нужно принять решение.
Двойное-тройное сканирование объектов АОТ тормозит как нас, так и программистов/администраторов самого клиента.
Надеюсь, что убирание префиксов повысит скорость дальнейшей работы.
)
мой опыт такой уборки показал, что скорость повысилась, но очень не значительно, поскольку знание, чем каждый объект занимается необходимо. Большой плюс остался только эстетическое наслаждение

Цитата:
Сообщение от mazzy Посмотреть сообщение
Хотелось бы сосредоточиться на конкретно префиксах/суффиксах.
плюсы/минусы? стоит ли избавляться? (если все остальные вопросы решены)
Префикс удобен в названиях проектов (содержит код из реестра модификаций) и отчетах (удобно искать, похожие отчеты, но из разных модулей, разные сотрудники заказывали), в остальном считаю крайне вредным.

Суффикс удобен, чтобы 1) ловить объекты без комментария 2) в стеке сразу видно, где пошли другим путем.

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

Ихмо, лучше использовать только один суффикс/префикс, только чтобы отличать доработки для клиента от системы
За это сообщение автора поблагодарили: mazzy (2).
Старый 06.10.2010, 17:06   #37  
titov is offline
titov
Участник
 
73 / 87 (3) ++++
Регистрация: 23.12.2005
Адрес: Казань
Цитата:
Сообщение от _scorp_ Посмотреть сообщение
Each path in the AOT must be unique; nodes must not have identical names.
в цитате из ВР требование к уникальности. Уникальность по оси АОТ, или еще и по оси времени, то есть и на будущее, там где новые версии?
Вопрос каверзный.
Либо автор ВР действительно исключил префиксы\суффиксы, рекомендуя в будущем совмещать совпадающие объекты, либо пропустил момент уникальности на завтра, либо отдал нам на откуп. Узнать бы... А пока спорим
Старый 06.10.2010, 17:41   #38  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре Посмотреть сообщение
То есть, я правильно понял, что мы просто берем чужой модуль и стираем в нем префиксы, который по сути является единственным признаком авторского права разработчика?
Если бы модуль, то я бы даже не спрашивал, а оставил.
нет, не модули. а ошметки, группы таблиц и группы полей, оставшиеся от разных разработчиков.

после перехода на ax2009 префиксы потеряли всякий смысл, поскольку все совсем другое.

соображение насчет авторских прав - понял. спасибо.
подумаем и посоветуемся.
__________________
полезное на axForum, github, vk, coub.
Старый 06.10.2010, 17:47   #39  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре Посмотреть сообщение
Меня, кстати, в этом случае больше интересует моральный и этический аспекты.
И еще одно. автор остается в свойствах объекта (кто и когда создал, когда и когда последний модифицировал).

у полей, методов таких свойств нет
зато есть у таблиц, классов.

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

в общем, не думаю, что это решающий аргумент
хотя подумать над этим надо.
__________________
полезное на axForum, github, vk, coub.
Старый 06.10.2010, 18:02   #40  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,271 / 3465 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
На мой взгляд, префиксы с кодом клиента очень даже полезны.
Полезны для кого? Для внедренца? Дык не им же потом (возможно) придется разгребать чужой код. Польза д.б. в первую очередь для конечного клиента. Как следствие - если конечный клиент обратится к внедренцам - им проще будет.

Цитата:
Сообщение от fed Посмотреть сообщение
Почему-то сразу вспомнился Коламбус 1999-2001 годов
Потому что о нем в первую очередь и речь. Очень сильно вспоминается приложение в котором половина объектов с PRK_, из оставшегося - половина - штатный функционал, а половина - XXX_ и YYY_. Понятно - что внедренец "слепил" код с разных проектов. Если не брать во внимание этические/правовые моменты - то просто мне как разработчику, которому нужно чего-то усовершенствовать в этом коде - просто замучаться разбираться как можно поаккуратнее "вклиниться".

Цитата:
Сообщение от pitersky Посмотреть сообщение
Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.

клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект.
почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки
. Вот поэтому и нужно делать суффикс (если делать) - чтобы все было в одном месте и было наглядно видно и сразу пропадало желание делать Y_SourceTable

Цитата:
Сообщение от pitersky Посмотреть сообщение
Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.
На самом деле не совсем все так. Просто так дубль не появится. Обязательно будет префикс модуля. А вот уж если в МС "забыли" поставить префикс модуля и программист у клиента тоже забыл - то это уже урок этому программисту - что надо думать.
Именно из-за наличия префикса модуля - табличка в сводном никогда не пересечется с табличкой в ГК к примеру. Поэтому - никогда не следует создавать табличку RequestTable. Она должна относиться к чему-то. Либо это LedgerRequestTable (А может быть даже и LedgerRequestJournalTable), либо это InventRequestTable, smmRequestTable, MyModuleRequestTable и т.д.

Цитата:
Сообщение от titov Посмотреть сообщение
По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы... Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму
"Безобразно но единообразно" - это точно.

Цитата:
Сообщение от titov Посмотреть сообщение
еще момент - а если код партнера\клиента лучше MS DAX ?
Хотя это и вполне так бывает - но я бы стал отталкиваться от штатного кода как от эталона. По причине его тиражируемости. Таблицу CustTable знают все. А таблицу XXX_MySuperTable - никто.

Цитата:
Сообщение от titov Посмотреть сообщение
А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало??
Вот именно - нужны дополнительные действия.?
Как уже писал fed - случаи апгрейда редки. Значит ими можно пренебречь. Вероятность такого события - очень мала. Да и оно некритично - сборка приложения делается не в авральном режиме за ночь. Т.е. берем перекрестные ссылки и проходимся у себя и выясняем - насколько отличается бизнес-логика, завязанная на это поле. После этого либо поле переименовываем - либо переделываем наши модификации на новые реалии (опять-таки - по проекту из перекрестных ссылок - это не такая проблема)

Цитата:
Сообщение от titov Посмотреть сообщение
В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.
Да, но есть такой инструмент как слои. Они очень хорошо показывают все расхождения. Без них конечно - было бы сложнее. Кстати - при желании - можно выгрузить все в хпо, а дальше сделать поиск и замену

Цитата:
Сообщение от titov Посмотреть сообщение
еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.
2 вывода:
1. Если делать префикс/суффикс - то он должен обозначать внедренца, но никак не клиента.
2. Развести исполнителей по модулям и включить систему контроля версий. Не верится - что одновременно 2 исполнителя будут править один и тот же объект.
Если же рассматривать работу исполнителей во времени - то как раз получим ворох разнопомеченных объектов. Не спасет суффикс от неработоспособности функционала. Тут нужно как-то по-другому организовывать работу. Проектами может делить.
__________________
Возможно сделать все. Вопрос времени
Теги
как правильно, полезное, holywar

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Что лучше, много номенклатур или много конфигураций? axvrp DAX: Функционал 75 21.09.2010 16:13
Как лучше вносить изменения в чужой класс ski DAX: Программирование 13 18.08.2009 10:15
LedgerJournalTable как лучше сделать новую форму kitty DAX: Программирование 2 20.02.2008 12:36
Site в складской аналитике. Как лучше перевести? mazzy DAX: Прочие вопросы 73 07.01.2008 12:18
подскажите. как лучше сделать kitty DAX: Программирование 4 02.11.2007 11:14
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:46.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.