- Force.com Enterprise Architecture(Second Edition)
- Andrew Fawcett
- 519字
- 2021-07-09 18:31:00
Package types and benefits
A package is a container that holds your application components, such as Custom Objects, Apex code, Apex triggers, Visualforce pages, Lightning Components, and so on. This makes up your application. While there are other ways to move components between Salesforce orgs, a package provides a container that you can use for your entire application or deliver optional features by leveraging the so-called extension packages.
There are two types of packages—managed and unmanaged. Unmanaged packages result in the transfer of components from one org to another; however, the result is as if those components had been originally created in the destination org, meaning that they can be readily modified or even deleted by the administrator of that org. Furthermore, they are not upgradable, and are not particularly ideal from a support perspective. Moreover, the Apex code that you write is also visible for all to see, so your intellectual property is at risk.
Tip
Unmanaged packages can be used for sharing template components that are intended to be changed by the subscriber. If you are not using GitHub and the GitHub Salesforce Deployment Tool (https://github.com/afawcett/githubsfdeploy), they can also provide a means to share open source libraries to developers.
Features and benefits of managed packages
This book focuses solely on managed packages. Managed packages have the following features that are ideal for distributing your application. The org where your application package is installed is referred to as a subscriber org, since users of this org are subscribing to the services your application provides:
- Intellectual Property (IP) protection: Users in the subscriber org cannot see your Apex source code, although they can see your Visualforce pages code and static resources. While the Apex code is hidden, JavaScript code is not, so you may want to consider using a minify process to partially obscure such code.
- The naming scope: Your component names are unique to your package throughout the utilization of a namespace. This means that, even if you have object X in your application, and the subscriber has an object of the same name, they remain distinct. You will define a namespace later in this chapter.
- The governor scope: Code in your application executes within its own governor limit scope (such as DML and SOQL governors that are subject to passing Salesforce Security Review) and is not affected by other applications or code within the subscriber org. Note that some governors, such as the CPU time governor, are shared by the whole execution context (discussed in a later chapter), regardless of the namespace.
- Upgrades and versioning: Once the subscribers have started using your application, creating data, making configurations, and so on, you will want to provide upgrades and patches with new versions of your application.
There are other benefits to managed packages, but these are only accessible after becoming a Salesforce partner and completing the security review process; these benefits are described later in this chapter. Salesforce provides ISVforce Guide (otherwise known as the Packaging Guide) in which these topics are discussed in depth—bookmark it now! The ISVforce Guide can be found at http://login.salesforce.com/help/pdfs/en/salesforce_packaging_guide.pdf.
- Visualforce Development Cookbook(Second Edition)
- 腦動力:C語言函數速查效率手冊
- 大數據挑戰與NoSQL數據庫技術
- Windows環境下32位匯編語言程序設計
- 嵌入式操作系統
- 中國戰略性新興產業研究與發展·智能制造裝備
- Azure PowerShell Quick Start Guide
- Linux系統下C程序開發詳解
- 單片機技術項目化原理與實訓
- 大數據導論
- 工業機器人入門實用教程
- 簡明學中文版Flash動畫制作
- Raspberry Pi Projects for Kids
- MySQL Management and Administration with Navicat
- 網絡安全原理與應用