惊!List型Custom Setting惨遭SFDC抛弃,上位者居然是……

一夜之间,List型Custom Setting惨遭抛弃,SFDC发布冷血声明。
上位者从默默无闻变成人尽皆知。
SFDC开发者不禁议论纷纷。
到底是人性的扭曲,还是道德的沦丧。
接下来请看————————————谁杀死了List型Custom Setting?

最近,SFDC开发者都在纷纷议论着一件事——————————List型的Custom Setting到底怎么了?
我们采访了一位资深SFDC开发者,希望以此了解到事情的经过。

记者:“你好,这里是夏晚实验室小组。我看到刚刚你们在讨论List型的Custom Setting,请问发生了什么?”
开发者A:“就是突然发现不让用了嘛。”
记者:“不让用了指的是?。。。”
开发者A:“就是不能新建List型的Custom Setting了”边说边用手指了指屏幕,记者注意到Setting Type已经定死了是Hierarchy。
记者:“那是从什么时候开始的呢?”
开发者A挠了挠头,说道:“这个就不清楚了,反正就是领导让我去建一个Custom Setting放参数用,结果一打开就发现这样了。”
开发者B这时候凑了过来,告诉记者:“看,上面SFDC还特意写了一个声明在上面。”

经深入了解后,我们发现这并不是孤例。遇到这个情况的开发者数不胜数。

随后,记者打开了一个新建的DE,看到了之前开发者B口中的官方声明。

Tip: Use Custom Metadata Types for App Configuration

If you’re thinking of using list custom settings, consider using custom metadata types instead. Unlike list custom settings, you can migrate the records of custom metadata types using packages or Metadata API tools. You can enable List Custom Settings on the Schema Settings page in Setup.

大意是说,如果想用List型Custom Setting的话,这位先生/女士,custom metadata types了解一下。不同于Custom Setting,数据可以直接deploy。
如果我安利失败了,你可以去Schema Setting里重新打开List型Custom Setting。

唔。。。看来List型Custom Setting还没凉,只是做了个开关,然后故意顺手帮你关上了。意图以此强行推Custom Metadata Type上位。
如果不注意看声明内容的话,就很有可能就这么中计了。
想继续用的话,还是可以在Setup->Administer->Data Management->Schema Settings自行开启。

那么,由SFDC大力扶持的上位者Custom Metadata Type,到底是什么呢?究竟Custom Metadata Type真的如声明中所说的那样美好吗?
让我们来一探究竟。

Custom Metadata Type这个名字虽然让人感到陌生,但实际上已经默默陪伴我们很久了。
Custom Metadata Type最早是在Summer’15被引入SFDC。
那时候还不允许在画面上直接创建数据,只能通过Metadata API才能进行增删改查。

那时刚出生的Custom Metadata Type委以厚望,用来为ISV解决一个很棘手的问题———————因为数据不能Deploy,所以configuration数据无法通过package直接安装进目标Org中,必须使用额外的手段。
但是,造化弄人,等待大放光彩的Custom Metadata Type却被湮没在了历史的长河之中。

为了推广这个功能,SFDC分别在Winter’16支持通过画面直接增删改查,
Spring’17支持RelationShip与QueryMore。连续不断的为其完善功能。
但开发者们仍然对其不感兴趣。

所以,Custom Metadata Type与Custom Setting相比,最大的优势就在于数据属于Metadata,可以与表定义一起deploy。
而Custom Setting中的数据只能通过Dataloader等数据迁移工具,在Deploy后再进行一次数据Import。

那么为什么Custom Metadata Type仍然不受待见呢?

首先,不同于Custom Setting,Custom Metadata Type并不支持在Apex中进行DML操作。只能通过UI或者Metadata API(因为是Metadata)。
其次,在测试类中无法创建测试数据。

所以,如果只是简简单单的用来放一些configuration数据用来参照的话,
两者的效果是差不多的。
但是,如果我们需要一个计数器,用来记录Batch的执行次数之类的话,Custom Metadata Type就无法胜任了。

因此,为了在测试不同的分支,
https://developer.salesforce.com/blogs/engineering/2015/05/testing-custom-metadata-types.html
只能如上文所述,不得不在Custom Metadata Type中提前埋一些测试数据进去,然后用额外的字段标注哪些是测试用数据。
不能如同Custom Setting那样,直接在测试类中方便的创建测试数据。

打铁还须自身硬,既然SFDC打算用Custom Metadata Type来代替List型Custom Setting。就让我们拭目以待后续的更新吧。

《惊!List型Custom Setting惨遭SFDC抛弃,上位者居然是……》有一个想法

  1. This is complete crap! What kind of change is this… can you at least deploy a new list custom setting via an older API version?

    I can’t believe they would force this change. There are certainly times where I would like to simply update my custom settings via DML in Apex. Now I can’t do that…

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据