在命名空间下组织Apex类 [英] Organizing Apex Classes under Namespace

问题描述

Salesforce中是否可以将包类或名称空间下的顶点类分组?我们可以将托管软件包用于内部组织吗?

解决方案

这是force.com堆栈中的一个限制，这使中等规模的项目很痛苦，甚至不切实际.使用托管程序包来获取程序包前缀并不能真正解决任何问题，因此，这样做确实不值得.

我通常会尝试将项目组织到一个平面的命名空间中.代替实际的名称空间，我将为每个可能的名称空间提供3-5个字符的名称，以用作前缀.属于命名空间"的任何类都将加上前缀.例如，如果我需要payroll命名空间，则可以使用PYRL前缀.名为PaycheckCalculator的类变为PYRL_PaycheckCalculator.

这种约定的实际优势是，它有助于防止名称冲突，并且在排序列表中(例如在IDE中，或在Setup> Develop> Apex Classes中查看)时，将类按其命名空间"分组.

不幸的是，一些基本的OO原则仍然从根本上被打破.可能最重要的一个是，每个类对它可见的 每个 其他类形成隐式依赖，即 all .

我很想听听其他人如何克服此限制.

Is there any way in Salesforce to group apex classes under a package or namespace? Can we use managed package for internal organization purpose?

解决方案

This is a limitation in the force.com stack that makes medium-large size projects painful, if not impractical. Using managed packages in order to get a package prefix doesn't really solve any problems, so it's not really worth the trouble.

I usually try to organize a project into one flat level of namespaces. In lieu of actual namespaces, I'll give each would-be-namespace a 3-5 character name, to be used as a prefix. Any class that belongs in the "namespace" gets prefixed. E.g., if I need a payroll namespace, I'd use a PYRL prefix. A class called PaycheckCalculator becomes PYRL_PaycheckCalculator.

The practical advantage of this type of convention is it helps prevent name clashes and classes are grouped by their "namespace" when viewed in a sorted list, such as in an IDE, or Setup > Develop > Apex Classes

Unfortunately, several basic OO principles are still fundamentally broken. Probably the most important one is every class forms an implicit dependency on every other class it has visibility to, which is all of them.

I'd love to hear how others have worked around this limitation.

这篇关于在命名空间下组织Apex类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！