Salesforce 在名称空间下组织Apex类

Salesforce中有没有办法将apex类分组到包或命名空间下？我们能否将托管包用于内部组织目的

这是force.com堆栈中的一个限制，使得中大型项目即使不是不切实际的，也是痛苦的。使用托管包来获取包前缀并不能真正解决任何问题，因此不值得这么麻烦

我通常尝试将一个项目组织到一个平面的名称空间中。作为实际名称空间的替代，我将为每个名称空间指定一个3-5个字符的名称，用作前缀。任何属于“名称空间”的类都会得到前缀。例如，如果我需要

payroll

名称空间，我会使用

PYRL

前缀。一个名为

PaycheckCalculator

的类变成

PYRL\u PaycheckCalculator

这种约定的实际优势在于，它有助于防止名称冲突，并且当在排序列表（如IDE或Setup>Develop>Apex类）中查看时，类按其“名称空间”分组

不幸的是，一些基本的OO原则仍然被根本打破。可能最重要的一点是，每个类都对它所能看到的其他类（即所有类）形成隐式依赖

---

我很想听听其他人是如何克服这一限制的。

好吧，你可以使用托管软件包，但正如Jeremy提到的，它并没有给你带来多少好处。当然，托管软件包对于开发公开上市的应用程序并在AppExchange上销售至关重要。但在内部，这确实是一个组织范围内的问题，因为一旦您创建了一个带有前缀的托管包，所有涉及到它的任何其他部分的内容都会被标记为相同的名称空间前缀，包括所有自定义对象。更糟糕的是，您不能从托管包的外部访问托管包中的代码（这实际上是它们的全部要点）

---

虽然这不是最漂亮的解决方案，但我个人所做的是维护许多具有不同用途、应用程序和实用程序类的命名组织。当我在一个组织中需要一个实用程序类时，比如说我正在为AppExchange构建一个新的应用程序，我将从相关的实用程序组织中进行Eclipse导出/导入。这看起来确实很奇怪，但拥有一个组织库是我跟踪一切并管理“内部”组织的最好方式。但最终的结果实际上只是在任意代码存储之间进行美化的复制粘贴操作。

我在处理大型项目时遇到了类似的挑战，某个时候写了这篇博文来分享我现在采用的方法：

同样的解决方法。。。以惯例为前缀，我讨厌它。根据今年在Dreamforce举行的“与开发者见面”会议，我们很快就能看到一个具有满足这一需求的功能的版本。去年夏天，我直接与工程组织的一位高层人士讨论了这一点。没有计划添加任何类型的包/命名空间功能。原因是很少有客户要求它。回答很好，希望这是在salesforce.stackexchange.com上“您不能从托管包外部访问托管包中的代码”。在apex页面的版本设置选项卡上引用已安装的托管软件包不会解决这个问题吗？还是我误解了？@DanielBallinger我相信您必须在托管包中将代码设置为“全局”，以便在包外可见和引用我们希望获得相关信息，而不是可能被破坏的外部链接。关于Salesforce开发，我的主要建议是不要。请参阅