|
06.10.2010, 14:23 | #1 |
северный Будда
|
Я считаю, что для почти всех кастомных объектов (кроме проектов) нужен единый для компании префикс. Т.е. новаю таблицу надо называть не блаблаTable, а Х_блаблаTable. Это сразу покажет, какие именно объекты нестандартные + обезопасит от возможных перекрытий имён при переходе на новые версии продукта. Название проекта должно начинаться с префикса-идентификатора разработчика.
Суффиксы нужны только в классах-потомках и нигде более.
__________________
С уважением, Вячеслав |
|
06.10.2010, 14:28 | #2 |
Administrator
|
После того как таких объектов переваливает за 5 штук - это становится неудобным (см мой пост про XXX_InventJournalTable и YYY_InventJournalTable) и ненужным (уже смотрится на модуль)
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:31 | #3 |
Участник
|
Цитата:
а почему не суффикс? |
|
06.10.2010, 15:53 | #4 |
Участник
|
Цитата:
Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму - по функциям коду и принимать решение о слиянии (удалении своих). Здесь еще плюс есть - приложение уже работоспособно сразу после перехода (ну почти сразу). А без преффиксов\суффиксов - в двух местах - есть два варианта развития событий. И приложение с ошибками! еще момент - а если код партнера\клиента лучше MS DAX ? пройтись по своим классам и переименовать + код по ссылкам - то есть обратные действия? А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало? Вот именно - нужны дополнительные действия. В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало! Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться. еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний. и еще - практикуется продажа решений айти компаниями - суффиксы объектов в таких проектах хро очень даже кстати. И не всегда сразу ясно, что будет решение при начальном создании объектов. |
|
06.10.2010, 18:02 | #5 |
Administrator
|
Полезны для кого? Для внедренца? Дык не им же потом (возможно) придется разгребать чужой код. Польза д.б. в первую очередь для конечного клиента. Как следствие - если конечный клиент обратится к внедренцам - им проще будет.
Потому что о нем в первую очередь и речь. Очень сильно вспоминается приложение в котором половина объектов с PRK_, из оставшегося - половина - штатный функционал, а половина - XXX_ и YYY_. Понятно - что внедренец "слепил" код с разных проектов. Если не брать во внимание этические/правовые моменты - то просто мне как разработчику, которому нужно чего-то усовершенствовать в этом коде - просто замучаться разбираться как можно поаккуратнее "вклиниться". Цитата:
Сообщение от pitersky
Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.
клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект. почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки Цитата:
Сообщение от pitersky
Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.
Именно из-за наличия префикса модуля - табличка в сводном никогда не пересечется с табличкой в ГК к примеру. Поэтому - никогда не следует создавать табличку RequestTable. Она должна относиться к чему-то. Либо это LedgerRequestTable (А может быть даже и LedgerRequestJournalTable), либо это InventRequestTable, smmRequestTable, MyModuleRequestTable и т.д. Цитата:
Хотя это и вполне так бывает - но я бы стал отталкиваться от штатного кода как от эталона. По причине его тиражируемости. Таблицу CustTable знают все. А таблицу XXX_MySuperTable - никто. Цитата:
Цитата:
Сообщение от titov
В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!
Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться. Цитата:
Сообщение от titov
еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.
1. Если делать префикс/суффикс - то он должен обозначать внедренца, но никак не клиента. 2. Развести исполнителей по модулям и включить систему контроля версий. Не верится - что одновременно 2 исполнителя будут править один и тот же объект. Если же рассматривать работу исполнителей во времени - то как раз получим ворох разнопомеченных объектов. Не спасет суффикс от неработоспособности функционала. Тут нужно как-то по-другому организовывать работу. Проектами может делить.
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:31 | #6 |
Axapta
|
Слои.
Цитата:
Цитата:
Кстати, ужасно раздражает, когда в название проекта в виде префикса зашивается не только код заказчика (это как раз правильно), но и внутренний номер модификации.
__________________
С уважением, Олег. |
|