Custom Setting vs Custom Metadata Types

Custom Setting有两种类型：

1.List Custom Settings：用于创建一组静态的数据;

2.Hierarchy Custom Settings：通过指定的Profile或者用户设置指定的数据。

 

Custom Settings :

“Manage List Custom Settings Type” is disabled, to allow the creation of List Custom Settings you have to enable “Manage List Custom Settings Type”.

To enable it : Go to Setup | Data or Search “Schema Settings” in Quick Find | Click Schema Settings | Enable “Manage List Custom Settings Type

• Custom settings enable you to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database.
• You can control the visibility of custom setting by specifying it as public or protected. If custom setting is marked as protected, the subscriber organization will not be able to access the custom setting. If it is marked as public, then subscriber org can also access it.
• There are 2 types of custom setting, List and Hierarchy. Once you create custom setting, then you cannot change the type (List to hierarchy or vice versa).
• List custom setting provides a reusable set of static data that can be accessed across your organization to all user.
• Hierarchy custom setting uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. In Hierarchy custom setting for logged in user, system first check user then profile and then org wide setting in order to return data from hierarchy custom setting.
• Custom settings do not support relationship fields.
• Custom Settings have the same permission to edit the records and to edit the configuration. Both can be done with the “Configure Application” permission.
• You can access custom setting data using instance methods and can avoid SOQL queries to database.
• While migrating custom setting to another org, It only deploys the metadata, you need to upload data into the custom setting post deployment.
• Custom setting can be used by formula fields, validation rules, flows, Apex, and the SOAP API.
• You cannot access List custom setting in Validation rule. Only Hierarchy custom setting can be used.
• You can perform CUD (Create, Update, Delete) operation on custom setting in apex.
• Custom settings are not visible in test class without “SeeAllData” annotation.

Custom Metadata Types :

• Custom metadata are like custom setting but records in custom metadata type considered as metadata rather than data. These are typically used to define application configurations that need to be migrated from one environment to another, or packaged and installed.
• Custom Metadata Types have WAY more options that Custom Settings, like picklist fields, long text areas (in Spring ’17), page layouts, and validation rules.
• You can control the visibility of Custom Metadata Types by specifying it as public or protected. If it is marked as public type, then anyone can see it. If it is marked as protected type, in the installed managed package subscriber organization, only Apex code in that managed package can use it.
• You can create lookups between Custom Metadata objects.
• Metadata Relationship provides the ability to add relationships from your custom metadata to other things in your app, such as other custom metadata, custom or standard objects and fields, and static resources.
• In Custom Metadata, you can edit the records with “Configure Application” permission, but you require “Author Apex” to edit the configuration.
• With custom metadata types, you can issue unlimited Salesforce Object Query Language (SOQL) queries for each Apex transaction.
• While migrating Custom Metadata Types to another org, the associated data you created against it is also deployed to the target organization.
• You cannot perform CUD (Create, Update, Delete) operation on custom metadata type in apex.
• You can control the visibility of custom metadata type while adding it in package.
• Custom metadata type are visible in test class without “SeeAllData” annotation