Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1429219
  • 博文数量: 931
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 10198
  • 用 户 组: 普通用户
  • 注册时间: 2011-07-08 12:28
个人简介

测试

文章分类

全部博文(931)

文章存档

2020年(134)

2019年(792)

2018年(5)

我的朋友

分类: 架构设计与优化

2019-05-11 10:23:39

Salesforce

Force.com integrates and optimizes several different data persistence technologies to deliver transparent polyglot persistence for all your applications and devices. With Force.com, you don’t have to deal with the complexity of trying to integrate, manage, test, and support several systems, and you only have to code to a single API, no matter which type of persistence is optimal for a given situation. The following figure is an overview of a sampling of Force.com’s persistence technology.

Salesforce存在一个Polyglot Persistence多态存储的概念。应用程序可以通过Polyglot persistence暴露出的统一接口去访问平台上的数据,而无需关心这些数据背后具体的存储技术到底是Transaction Engine, 还是由常驻内存提供,亦或是由支持全文本查找的搜索引擎提供。

SAP C4C(Cloud for Customer)

作为SAP提供的一款SaaS CRM解决方案,C4C也存在类似Salesforce Polyglot Persistence的设计,我们称之为元数据仓库存储。

我们在cloud application studio的package下面能看到许许多多的开发对象:

可以想象,这二三十种开发对象后台的存储逻辑和技术都各不相同。每次用户登录Cloud application studio,打开自己工作的package后,都会从后台将自己创建的类型各异的开发对象取出然后显示在studio里。

为了给Cloud application studio工具端和其他消费者(比如C4C前端UI)提供一个统一高效的API去C4C后台读取这些模型的数据,C4C设计了一个元数据存储仓库,该仓库提供了一个优化过后的API,相当于设计模式里的Facade(外观模式/门面模式)。该API会根据具体被访问的对象,将请求转发到该对象对应的存储服务提供者(Access service provider)上去。对于API的消费者来说,这些对象具体的存储技术是完全透明的,不需要知道。

要获取更多Jerry的原创文章,请关注公众号"汪子熙":


阅读(916) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~