![]() |
#101 |
MCP
|
Цитата:
Это как использовать гигантский агропромышленный комбаин для поездки на рыблку ![]() |
|
![]() |
#102 |
Axapta
|
Цитата:
А дописать три символа не сложно, кто бы спорил.
__________________
С уважением, Олег. |
|
|
За это сообщение автора поблагодарили: kornix (1). |
![]() |
#103 |
Гость
|
> реальных недостатков у префиксов полно и они в этой теме уже подробно описаны и неоднократно
а можно ссылку? а то я не вижу "реальных" недостатков |
|
![]() |
#104 |
Axapta
|
Я понимаю, что данная тема уже сильно разрослать, но мне бы не хотелось по второму кругу еще раз одно и тоже обсуждать. Пожалуй, я присоединюсь к
__________________
С уважением, Олег. |
|
![]() |
#105 |
Участник
|
Цитата:
![]() Использование префиксов было рекомендовано первыми выпусками Best Practis в ранних версиях Axapta. В последующих выпусках Best Practis (новых версиях Axapta) этой рекомендации больше нет. "Но осадок остался" (с) ![]() Цель: Исключение пересечения имен с именами стандартных объектов с целью облегчения выделения кастомизированных объектов при переходе на новые версии/фиксы Возражение: 1) Заявленная цель носит скорее теоретический характер. Никто и никогда еще не говорил на форуме о подобной проблеме. 2) При переходе на новую версию, "простой" upgrade в российских условиях - редкость. Обычно это выливается в написание нового приложения. Как следствие, переносится не код, а логика. Т.е. исходные имена объектов в "старой" версии не так уж и важны 3) Если имя кастомизированного объекта совпало с именем стандартного объекта в новом фиксе, то это повод пересмотреть логику использования данного объекта. Цель: Идентификация компании/модуля/разработчика/фикса (в зависимости от того, что "шифруют" в префиксе) с целью последующего "разбора полетов" Возражение: 1) Для идентификации автора объекта существует ряд других способов, не связанных с именованием объектов 2) Если проблема, связанная с объектом выявляется достаточно быстро, то и так все знают, кто автор. А если проблема выявляется не сразу, то на момент обнаружения проблемы уже не важно, кто автор. Надо проблему решать, а не искать крайнего 3) Префикс фиксирует момент создания объекта, а при "разборе полетов" требуется определить всю цепочку изменений, приведших к текущему состоянию объекта. Не переименовывать же объект после каждой модификации! 4) Если в префиксе "шифруется" разработчик или код фикса, то возникают проблемы при модификации подобного объекта. Ведь его префикс перестает соответствовать содержанию. 5) Если в префиксе "шифруется" компания, для которой сделана кастомизация, то возникает проблема при портировании решения для других компаний. Безотносительно к правовой стороне данного вопроса. Префикс перестает соответствовать содержанию. Если же рассматривать правовую сторону подобного портирования, то она решается внепрограммными средствами. Префикс не может рассматриваться как предмет авторского права. 6) "Шифрование" в префиксе модуля оправдано только в случае, если это действительно отдельный независимый модуль. Но, в этом случае использование префикса фактически совпадает со "стандартной" идеологией именования объектов в системе Axapta. "А если нет разницы, то зачем...?" (с) Цель: Идентификация кода модификаций в именах проектов Возражение: Это единственный случай, который не вызывает существенных возражений ![]() В случае многочисленных модификаций придется поднимать все проекты, в которые включен данный объект Впрочем, это все-равно удобно. В случе поддержания правил вставки комментариев в код X++ можно определить имя проекта и посмотреть все объекты, включенные в данный проект. Сразу видно, что еще было изменено в данном проекте. Хотя, данный способ использования можно считать "вне темы", поскольку к именованию объектов АОТ он не относится. Цель: Модификации с одинаковым префиксом располагаются в АОТ рядом. Удобнее искать Возражение: 1) Удобно, пока общее количество объектов относительно небольшое. При большом количестве объектов это уже существенного влияния не оказывает 2) Если объекты относятся к разным модулям, то поиск усложняется, поскольку объект оказывается далеко от стандартных объектов данного модуля. Необходим "двойной" поиск. Сначала по именам без префиксов, потом по именам с префиксами. Вне зависимости от того, нашли или нет что-то по поиску без префиксов. Если есть несколько префиксов, то надо будет выполнять поиск по каждому префиксу в отдельности. Цель: "Расширение" одноименных объектов (дополнительные поля таблиц) или их локализация Возражение: Для этой цели удобнее использовать суффиксы. Не нарушается стандартная идеология именования объектов и объекты оказываются рядом в АОТ Дополнительные проблемы 1) В случае многочисленных кастомизаций будет много разных префиксов. Как следствие, возникают сложности в поиске и идентификации нужных объектов 2) Наличие префиксов - это паралельный стандарт именования объектов. Паралельный тому, который не явно предлагают разработчики Axapta. Как следствие, возникает необходимость поддержания нескольких стандартов именования. Чем их больше, тем сложнее. 3) Усложняется процесс вхождения в курс дела нового сотрудника. Ему нужно изучить "двойные стандарты" именования 4) Потенциально способствует дублированию функционала. Ну, не нашел нужного объекта (забыл про префикс) и создал свой собственный |
|
|
За это сообщение автора поблагодарили: mazzy (5), fed (2), glibs (3), dn (2), CDR (1), Pustik (2), sukhanchik (2), lev (2), oip (5), gl00mie (2), ikopyl (4), S.Kuskov (3), kornix (2). |
![]() |
#106 |
Участник
|
Наиболее вероятная причина рекомендации по использованию префиксов в ранних версиях Axapta описана здесь
Syntax errors в sys-объектах Т.е. это попытка организационными средствами исправить "небрежность" программирования. Небрежность как на уровне ядра системы, так и на уровне написания кода. |
|
![]() |
#107 |
MCT
|
Вот что написано в inside Dynamics Ax 2012
"При написании дополнительной функциональности, в дополнение к следованию конвенции по именованию, следует добавить еще один префикс, который уникально идентифицирует ваше решение. Этот дополнительный префикс поможет предотвратить конфликт имен, если ваше решение будет работать с решениями из других источников. Рассматривайте префикс как идентификатор компании и решения. Например, если компания под названием MyCorp строит решение начисления заработной платы, то будет использовать префикс McPR у всех добавляемых элементах. "
__________________
Axapta book for developer |
|
![]() |
#108 |
Участник
|
По-моему, не стоит рассматривать эту книгу как истину в последней инстанции, тем более, что в этом вопросе она противоречит последним выпускам BP. Кроме того, пример в книге не очень удачный: если компания разработывает модуль начисления зарплаты и в соответствии с BP использует префикс модуля в именах своих объектов, то как-то слабо представляется, что в одном приложении будут "жить" несколько модулей с такой же функциональностью и, соотв., таким же префиксом модуля в названиях объектов приложения. А если такой модуль будет один, то и кодировать название его компании-разработчика в префиксе ни к чему.
|
|
![]() |
#109 |
Модератор
|
Цитата:
Сообщение от gl00mie
![]() Кроме того, пример в книге не очень удачный: если компания разработывает модуль начисления зарплаты и в соответствии с BP использует префикс модуля в именах своих объектов, то как-то слабо представляется, что в одном приложении будут "жить" несколько модулей с такой же функциональностью и, соотв., таким же префиксом модуля в названиях объектов приложения
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#110 |
Участник
|
Работаешь над inside Dynamics Ax 2012 ?
![]() Последний раз редактировалось handy-comp; 13.11.2012 в 23:29. |
|
![]() |
#111 |
Участник
|
|
|
![]() |
#112 |
Модератор
|
Пробовали оба варианта. Лично мне удобнее и приятнее работать с префиксами, add-on-описателям с которыми мы работаем вроде как тоже
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#113 |
MCT
|
Есть такое ... работы много, есть интересные утверждения вроде этого
![]()
__________________
Axapta book for developer |
|
![]() |
#114 |
MCT
|
Собственно, поддерживаю!
Как применяли их в трешке, так и сейчас не имеет смысла отказываться или придумывать замену.
__________________
Axapta book for developer |
|
![]() |
#115 |
Administrator
|
Цитата:
![]() Вообще, можно будет попробовать устроить голосовалку. Хотя она конечно и не будет сильно показательна (не все ж там проголосуют). Мне кажется, что, если уж говорить о том, что высказывать это мнение на страницах книги - то нужно его оформить в стиле сообщения Владимира Максимова - т.е. указать плюсы и минусы разного подхода. А выбор оставить на усмотрение читателя.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#116 |
MCT
|
Цитата:
![]() В азах по сео утверждается, что резюмированный взгляд на вещи всегда более ценен, чем все высказанные мысли вместе взятые, какими оригинальными они не были. ![]()
__________________
Axapta book for developer Последний раз редактировалось MikeR; 14.11.2012 в 08:19. |
|
![]() |
#117 |
NavAx
|
Прошу прощения, а что имеется в виду под "сео"? Очень слово "всегда" режет.
__________________
Isn't it nice when things just work? |
|
![]() |
#118 |
MCT
|
Я использовал, как термин поисковой оптимизации, в частности в некоторых руководствах описывается, как грамотно писать тексты, что бы они попадали в топ выдачи. Здесь же используется смысл грамотно оформленных комментариев, с получением максимально возможных одобрений,
![]()
__________________
Axapta book for developer |
|
![]() |
#119 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#120 |
Участник
|
Сейчас это уже то же самое, что назвать Internet интернетом. Не стоит запариваться по этому поводу.
__________________
// no comments |
|
Теги |
как правильно, полезное, holywar |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|