salesforce Custom Setting VS Custom metadata type（CMT）

Posted 2021-02-27 bzi-salesforce

对于Custom Setting和CMT到底该用哪个的问题最近一直在困扰，下面分别列举出custom setting与 CMT的优缺点

 

 

 

CMT：可直接带着value部署，这是custom setting所不能实现的

<?xml version="1.0" encoding="UTF-8"?>

<CustomMetadata xmlns="http://soap.sforce.com/2006/04/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <label>TestSaveBaiduUrl</label>

    <protected>false</protected>

    <values>

        <field>Country__c</field>

        <value xsi:type="xsd:string">CN</value>

    </values>

    <values>

        <field>EndPointURL__c</field>

        <value xsi:type="xsd:string">https://www.baidu.com</value>

    </values>

</CustomMetadata>

 

（XML of cmt）

<?xml version="1.0" encoding="UTF-8"?>

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">

    <customSettingsType>List</customSettingsType>

    <enableFeeds>false</enableFeeds>

    <label>TestSaveBaiduUrl</label>

    <visibility>Public</visibility>

</CustomObject>

（XML of Custom setting）

对于用Apex代码来对record进行DML操作来说CMT是不支持的，需要用来matadata API来进行update，另一篇随笔会share一个工具类来进行mdt的upsert。

 

Custom setting 与 CMT都是支持数据库查询语句的如下实例：

TestSaveBaiduUrl__mdt urlsave =[select id,Country__c,EndPointURL__c from ip_save__mdt where MasterLabel = ‘TestSaveBaiduUrl’];

Custom Setting与cmt的查询语句除了名称用__c与__mdt的差别以为并无太大差异

但是custom setting支持通过方法get value 好处是不占用apex的SQL101限制，不占用SQL次数

TestSaveBaiduUrl__c test= TestSaveBaiduUrl__c.getAll().get(‘baidu‘);//通过record Label获取value

 

同时customSetting也是可以直接进行DML操作的

database.update(test);

 

Cmt 没有完全取代custom setting的重要一点也是 custom setting的Hierarchies类型

可以针对profile和user做一些灵活配置，例如跳过一些验证规则与trigger等

 

以下为两者有点更详细的介绍分析希望可以对你带来更多的帮助 ：0

Advantages to Custom Metadata:

 

1. Most importantly, as stated before, they are Metadata and thus deployable! No more annoying configuration after deployment, which you have to do with Custom Settings. They‘re also refreshed to sandboxes, so you don‘t need to create Apex classes to generate your default Custom Setting records.

 

2. They have WAY more options that Custom Settings: picklist fields, long text areas (in Spring ‘17), page layouts, and validation rules (though as of Winter ‘17 these are not deployable either by change set or by migration tool - weird!)

 

3. The beauty that is Metadata Relationships! You can create lookups between Custom Metadata objects. Additionally, you can create an Object Definition lookup - so you‘re relating Custom Metadata to Standard or Custom Object definitions. Additionally, in Spring ‘17 you can create a dependent lookup to a Field Definition on that object. (Documentation here)

 

4. Custom Settings have the same permission to edit the records and to edit the configuration. Both can be done with the "Configure Application" permission. With Custom Metadata, you can edit the records with "Configure Application" but you require "Author Apex" to edit the configuration.

 

5. Custom Metadata types have a lot of additional features specific to developing managed packages. You can configure the visibility and editability of fields an objects both by the org that installs the package and by upgrades to the package.

 

Reason why you would use custom settings instead:

============

1. Hierarchies - Custom metadata types do not purport to replace hierarchy custom settings which allow you to vary values based on users and profiles across the org. These custom settings can also be referenced in formulas, so can be used in formula fields, validation rules, workflow rules, and visualforce. (Documentation here)

 

2. Web service credentials - If you’re using test credentials in a sandbox, you don’t have any reason to deploy them to production. More importantly, if you create a sandbox, you don’t want the config for the production versions of your Web Services being created automatically and used by default. However, it is usually best to use Named Credentials for this.

 

3. Custom setting records’ values can be edited in code, while custom metadata cannot. If you will need to modify your configuration programmatically for any reason (say you’re creating a config console for the user), custom metadata will not work.