26

We've always been conservative when it comes to exposing Globals for use by extension packages or subscriber extensions, and perhaps too conservative. We're considering being more proactive wth our global architecture, and we're discussing several changes to our current practice, in order to create a new set of best practices.

Topics we're discussing include "microglobals" that all share a common interface, minimizing the call tree, and when and how much we should use the internal API versioning that Salesforce provides.

Do you already have a set of best practices for designing and maintaining globals that works well for your packages and that you could share?

  • Though I can see this being somewhat opinion based I would think this can be turned into a useful Q&A with a little work, so voting to leave open. – Dave Humm Mar 5 '17 at 14:57
  • Thank you, @DaveHumm. While a great number of practitioners use extension packages to provide additional functionality and modularity, Salesforce only discusses extensions as a way to support multiple editions. As a result, there is no guidance in the Salesforce documentation that covers real-life practice. – Ted Husted Mar 6 '17 at 16:24
  • 1
    Note that Salesforce is planning to make significant changes to the packaging process over the next several releases, so that may change best practices over time. This DF16 presentation should give some more insight if you haven't seen it. I believe they are planning to allow you to develop extension packages in the same org as your main package, which should remove the necessity to make classes and methods global solely for extension packages (safe harbor, of course). – Robert Watson Mar 8 '17 at 1:00
  • Honestly, @RobertWatson, the pkg 2.0 changes will call for even more discipline in our practice, since we'd be able to share publics between artifacts. Brrrr. – Ted Husted Mar 9 '17 at 13:59
  • 1
    Here are some practice notes from another thread. * Prefer API-first, even if it means more globals. * Prefer use of interfaces and class extensions. * Prefer static stateless methods on services with the use of DTOs. * Establish an API Review process. * Enforce strict naming conventions, especially on API elements. * Prefer Invocable Methods as an API strategy. * Avoid the Salesforce behavior versioning. * Prefer versioning through introduction of a successor class (Global2, Global3). * Consider injecting @deprecated when deploying to packaging orgs. – Ted Husted Mar 9 '17 at 14:00

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.