关于Salesforce的组成

小时候看CCTV播放的纪录片,里面讲抗日战争日期中国空军的事情。
到现在都能很清晰的记起其中一段。
当时是采访一位老兵,说当时根本没有时间进行系统训练,
所有的飞行员都是简简单单练练起飞降落开机枪就上天作战了,
根本没机会像现代空军一样,要系统的学习机械原理,飞机构造之类的才能上天。
简单的比喻就像开车一样,能把车开走不一定需要知道车为什么能开走,引擎是什么烧的,动力是怎么传导的。

做开发也一样。
特别是Salesforce。
作为Salesforce从业者,也许精通admin,玩转401,熟练掌握501。
但不一定需要了解Salesforce平台是由什么构成的。

对于大部分从业人员来讲,了解了这些也不一定对日常工作有什么帮助。更何况还有可能占用宝贵的娱乐时间。
而且虽然作为Salesforce从业者,仍然有大量的英语困难症患者(日语也一样),更成为了止步不前的借口。

其实还是建议所有想在Salesforce平台好好做下去的从业者,认认真真的读一读官方提供的Salesforce基本原理
毕竟想跳的更高,就要蹲的更深。

干了这些年,根据经验总结。
我把Salesforce里面所有的东西分成三类。
第一类是云计算的核心,Metadata元数据
第二类是数据
第三类是设定

Metadata是其中最好理解的,也是最难深入理解的。
有经验的人知道我们对系统做出的大部分(注意,并不是所有)改动都会在Metadata上有所体现。
我们在Deploy的时候,Deloy的具体source也是MetaData文件。
MetaData可以视为是定义了Org中的一切。
老手甚至可以通过手动编辑MetaData让系统变成自己想要的样子。

如果MetaData使用来定义这个系统是什么样子。
那么数据就是这个系统的血肉,真正让系统的存在有了意义。
做Java系统时间长了的人,总觉得系统=代码。
而Salesforce将数据的重要性提到了一个新的高度。
几乎所有的改动都在围绕着数据。
收集数据,处理数据,显示数据。
数据还要分为业务数据,功能数据,系统数据。
业务数据就是系统用户日常业务开展需要数据,客户信息啊,商品列表啊,这些也是开发人员轻易不能动的内容之一。
功能数据,就是为了实现一些功能,需要储存参数的临时表, Custom Setting,或者记录功能执行记录的数据。
这部分数据用户是看不到也不需要看到的,但是又是系统正常运转的必须部分。
最后还有大量的系统数据,这些数据默默的维持着系统的基本运转,其中有一些表甚至不对开发者开放。

在这个世界上, 事情从来不会非黑即白。如果MetaData和数据泾渭分明,世界还是很美好的。
但现实是残酷的。并不是如理想一般,这个东西不是属于MetaData,就是属于数据。
在Salesforce里面,存在这大量双轨制的东西。
比如Profile,Role,Apex,VF等等,
这些既存在于MetaData,又存在于数据中。这样就等于赋予了这些东西两种截然不同的属性。
MetaData和数据的根本区别在于什么呢?
MetaData是定义,可以通过工具部署。是骨架。
数据不需要部署,可以直接导入,直接修改。是血肉。
这些东西就如粒子一般,拥有波粒二象性。
这里跑题太严重,就不展开了。

除了MetaData和数据以外,还有一些看得见摸得着的东西,不属于任何一种。
我称呼它们为设定,它们拥有这最顽固的性质,
除了手改,无法部署,不能导入。而且存在于各个角落。
最复杂的情况比如,在Profile本身已经是双规制。
结果Session Timeout设置和Password Policies这个两个俨然应该隶属于Profile的设定,
却不存在于MetaData和数据中任何一方。
甚至Profile的Copy功能也会将这两个设定无视掉。

具体分类的名单,等整理完之后再发吧。

// Upadate1

我还是想简单了,其实Metadata和数据的界限要更模糊一点。
有些我原来以为只能通过Metadata修改的东西,最后在sfdc后台其实还是一张表。

发表评论

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

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