Организация Apex классов в пространстве имен

Question

Есть ли в Salesforce какой-либо способ сгруппировать классы Apex по пакету или пространству имен?Можем ли мы использовать управляемый пакет для внутренней организации?

Answer 1

Это ограничение в стеке force.com, которое делает проекты среднего размера болезненными, если не непрактичными.Использование управляемых пакетов для получения префикса пакета на самом деле не решает никаких проблем, поэтому оно не стоит того.

Я обычно стараюсь организовать проект в один плоский уровень имен.Вместо реальных пространств имен я буду давать каждому потенциальному пространству имен 3-5 символов, которые будут использоваться в качестве префикса.Любой класс, который принадлежит «пространству имен», получает префикс.Например, если мне нужно пространство имен payroll, я бы использовал префикс PYRL.Класс с именем PaycheckCalculator становится PYRL_PaycheckCalculator.

Практическое преимущество этого типа соглашений заключается в том, что он помогает предотвратить столкновения имен, а классы группируются по их «пространству имен» при просмотре в отсортированном списке, например вIDE или «Настройка»> «Разработка»> «Классы Apex»

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

Мне бы очень хотелось услышать, как другие обходили это ограничение.

Answer 2

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

Хотя это не самое красивое решение, я лично поддерживаю множество именованных организаций с различными целями, приложениями и служебными классами. Когда мне понадобится служебный класс в одной организации, скажем, я создаю новое приложение, предназначенное для AppExchange, я сделаю экспорт / импорт Eclipse из рассматриваемой служебной организации. Это определенно кажется странным, но наличие библиотеки организаций - лучший способ, которым мне удалось отследить все и управлять «внутренней» организацией. Но конечный результат - это просто прославленная операция копирования-вставки между произвольными хранилищами кода.

Answer 3

Я столкнулся с аналогичными проблемами при работе над большими проектами, написал эту статью в блоге некоторое время назад, чтобы поделиться подходом, которому я сейчас следую: http://www.tgerm.com/2011/11/apex-class-naming-convention-suggestion.html