在这篇文章中，我思考了什么是核心数据服务（CDS），它做了什么，以及为什么我们应该优先了解更多信息。

今天早上，在学习一个教程时，我在SAP Web IDE的控制台日志中看到了这样一条消息：

表面上看，我们在进程输出中看到的许多消息都是信息性的，以及一系列描述背景的台词的一部分。

让我印象深刻的是其中隐含的意义。这个信息告诉我的是，CD——一个迄今为止基本上被低估的层面——有一个身份，一个版本，大淘客网站，都有它自己的。甚至CDS编译器也有自己的版本。与其把CDS看作是一个隐含在数据库和UI5之间的无定形的语言块（尤其是Fiori元素，以及CDS提供的注释），CDS是SAP开发技术堆栈中非常值得我们关注的一部分诞生于早期的HANA时代，预示着应用程序编程的范式变化。HANA的力量不是像我们在经典的R/3+RDBMS方法中那样将数据转化为代码，而是建议这种方法应该是将代码转化为数据。

我们中的一些老黑客可能会认为这不是什么新鲜事，满怀渴望地谈论存储过程，以及所有旧的东西最终如何重新变成新的。但我们将把这一点留到下次讨论。

SAP几十年来一直做得很好的一件事就是理解抽象的重要性。随着HANA的出现和向以数据为中心的开发方法的转变，一个为数据定义、访问和查询提供语言的抽象层诞生了，是用来弥合低级SQL（作为一种"数据库汇编语言"）和解决业务问题所需的实际数据表达式之间的语义鸿沟，使概念和实现级别的声明更紧密地联系在一起，CDS随后被提供给ABAP世界，随着Fiori元素的出现，我们中的许多人意识到CDS不仅仅是一个数据库抽象层。

CDS注释的力量和将消费视图分层到接口视图的可能性，添加了在生成的用户界面（UI）场景中使用的元数据，这是一个令人兴奋的组合。再加上元数据扩展所允许的可能性，CDS确实成为了一个强大的层。

一个关键因素

我认为CDS是一个关键因素，渗透到我们作为SAP ecosphere开发人员现在和明天所做的许多事情中。是胶水，是把多个层次和移动部分结合在一起的主干。

过去，我们谈论的是"全栈开发人员"，意思是（在我们的世界里）可以用UI5支持的前端组件和ABAP堆栈上由OData支持的后端组件构建端到端的Fiori应用程序的人。或许，我们需要拓宽这一视野，思考一下现实情况，这可以更好地描述为"多栈"。我们已经确定ABAP作为后端平台，UI5作为前端平台运行良好，我们可以而且应该考虑两端的替代方案。

SAP云平台上的"自带语言"（BYOL）的想法实际上向各个方向延伸，以"自带[数据库|前端|后端]"，并淡化了"全栈开发者"的含义，因为几乎没有（如果有的话），阿里大数据分析，开发人员将熟练掌握所有可能的组合。

也就是说，CDS是在这个多堆栈世界中保持不变的领跑者，这是我们都应该知道的。我已经提到过，CDS将多个层和运动部件绑定在一起。或许更重要的是，它将人们联系在一起，成为一种被上下技术人员使用和理解的语言，对他们所有人都有意义和意义。

新的规范示例

在上周的《周一早晨的思考》中，关于学习连续体，我提到了新的应用程序编程模型SAP云平台，在我看来，它是一个很好的早期"入门"教程的形式，它暗示了一个诱人的丰富性和深度，个人免费云服务器，只有多次重复的旅程才能开始提取。

该教程是关于在SAP云平台上构建一个完整的堆栈应用程序（作为一个云铸造应用程序）使用各种技术组件：前端是Fiori元素和UI5，持久层是HANA，应用服务层是Java，

关键是这些只是技术组件的例子。例如，在本教程实例中，大数据挖掘，应用程序服务层是Java，主要是因为它现在是受支持的运行时。但是，对于应用程序编程模型的下一个化身，可能会支持一个替代应用程序服务层的NodeJS堆栈。现在还处于早期阶段，我个人很高兴，粗略的共识和运行的代码意味着我们可以通过一个运行时示例第一次看到整个模型，这比我们从第一天开始支持多个运行时的时间要早。

然而，最重要的是，有一个概念，变得很清楚，只要你通过教程运行哪怕只是一次。这种观念就是CDS的极端重要性。CDS用作业务级数据定义源，并在（HANA）持久层生成工件。它用于定义与数据相关的视觉方面，这些定义（注释）会到达前端，从而影响应用程序的外观和行为。最后但同样重要的是，它用于生成应用程序服务层。项目上下文菜单中甚至有一个顶级项用于基于CD的构建。

下一步