SAP CAP 中的域建模

簡介

SAP CAP 中的域模型是根據實體關係模型描述問題域的靜態、數據相關方面的模型。 在本文中,我們將詳細研究 SAP CAP 中的域建模。

領域建模

簡而言之,SAP CAP 中的 CDS 以這樣一種方式生成域模型,即它根據鍵、字段和註釋來定義業務問題。 生成域模型的代碼以 CDS 模式 (db/schema.cds) 編寫。 這些領域模型可以用在服務定義、持久性模型、數據庫中,甚至可以在另一個領域模型中重用。

示例示例:

命名空間empInfo; 使用來自“@sap/cds/common”的{貨幣,託管}; 實體員工:託管{鍵ID:整數; firstName:本地化字符串(111); lastName:本地化字符串(1111); 經理:經理協會; 加入日期:整數; 工資:十進制(9,2); 貨幣:貨幣; }

 

在此示例中,我們創建了一個文件 schema.cds,我們在其中創建了一個實體Employees,其中包括Employee 的基本詳細信息

整個模式都被賦予了一個命名空間,即 empInfo

此模式使用標準數據類型,即貨幣。 使用像這樣的標準數據類型有助於我們帶來與之相關的所有預定義值幫助。

我們使用 CDS 創建模型。 在那個 CDS 中,我們使用

  1. 表示一組唯一對象的實體,例如:
    1. 員工基本信息
    2. 員工溝通信息
    3. 員工工資信息
  2. 定義關係的關聯
    1. Manager 與另一個實體 Manager 的關聯,該實體將擁有所有 Managers 列表

命名約定和建議

  1. 實體名稱應以大寫字母開頭,並且應易於閱讀且不言自明——例如,員工
  2. 以小寫字母開頭的元素——例如,firstName
  3. 建議使用實體的複數形式——例如,Employees
  4. 建議使用單數形式的類型——例如,貨幣
  5. 不要重複上下文 - 例如,Employees.name 而不是 Employees.EmployeeName
  6. 喜歡單字名稱——例如,salary 而不是salaryAmount
  7. 將 ID 用於技術主鍵——例如,ID 用於員工 ID
  8. 您可以使用命名空間使您的實體獨一無二。 這就像 SAP 中的客戶端概念,您可以使用具有唯一命名空間的重複模式(cds 文件)來區分它們。 命名空間是可選的,如果您的模型可能在其他項目中重用,請使用命名空間。 歸根結底,它們只是前綴,會自動應用於文件中的所有相關名稱。 - 例如,

命名空間筆記本電腦;實體戴爾 {}

..... 相當於:

實體筆記本電腦.Dell {}

  1. 您可以將上下文用於嵌套的命名空間部分。 - 例如,

命名空間筆記本電腦;實體戴爾 {}           //>筆記本電腦.Dell上下文 Apple { 實體 MacBookPro {}       //>筆記本電腦.Apple.MacBookPro     實體 MacBookAir {} }

 

實體

實體就像帶有主鍵的表。 我們可以使用這些實體執行 CRUD 操作。 盡可能保持平坦。 不要過度規範化它。 不要使用不可重用的類型。 本節僅用於建模,僅應添加與各個字段相關的註釋,不應添加技術細節(邏輯)。

類型

類型類似於 SAP ABAP 中的域,用於定義數據元素的類型。

方面

方面是模型的擴展,主要用於擴展現有的定義和註釋。 定義模型後,我們可以使用不同的 cds 文件(Aspect)在它們之上添加註釋以用於特定任務。

例如-

  • CDS– 你的核心領域模型,保持乾淨、簡單和易於理解
  • 審計模型.cds- 在文件中添加審核所需的其他字段
  • 授權模型.cds- 添加授權註釋。

主鍵

像 SAP ABAP 中的表和 CDS 一樣,我們使用關鍵字維護實體的主鍵 鍵。

通過使用通用定義的方法,可以在模型中重用主鍵。

我們可以創建一個 common.cds 模型,其中可以存儲所有常見的定義。

// 常用定義

實體 StandardEntity { 鍵 ID:UUID; 現在這些通用定義可以如下重用: using { StandardEntity } from './common'; 實體員工:標準實體{名稱:字符串; ... } 實體管理器:標準實體 { 名稱:字符串; ... }

 

默認情況下,已使用名為的預定義實體創建公共文件 cuid.

將 UUID 映射到 OData

默認情況下,CDS 在所有 OData 模型中將 UUID 映射到 Edm.Guid。 但是,OData 標準對 Edm.Guid 值提出了限制性規則——例如,只允許使用連字符的字符串——這可能與現有數據發生衝突。 因此,我們允許按如下方式覆蓋默認映射:

實體書{

密鑰 ID:UUID @odata.Type:'Edm.String';

...

}

如有必要,您也可以添加註解@odata.MaxLength 來覆蓋相應的屬性。

協會

它用於定義兩個實體之間的關係。 像 ABAP CDS 一樣,我們在這裡也使用這個詞 協會。 在這裡,關鍵字 許多 表示一個 0..* 基數。 基數的限制可以添加為一個約束(where 條件)——例如,使用 不為空.

成分

與我們將實體的字段與整個實體的對象相關聯的關聯不同,組合僅引用另一個實體的特定字段。 它具有自我管理的深度操作(插入/更新)和級聯刪除(多依賴表刪除)的額外優勢。

// 定義包含 OrderItems 的訂單實體訂單{鍵ID:UUID; Items : Items.parent=$self;}entity Order_Items { // 只能通過訂單訪問  關鍵父級:與訂單的關聯; 關鍵書:與書籍的關聯; 數量:整數;}

最佳實踐

  1. 不要在模型中添加技術細節,我們使用 方面
  2. 使用 簡稱 及 簡單的平面模型
  3. 不要過度規範化模型中的實體
  4. 如果您確實要處理高負載和高容量,請使用本地整數序列。 否則,更喜歡 UUID

到現在為止我們學到了什麼:在它之上創建模型和方面。

SAP CAP 中的域建模

發表評論

本網站使用Akismet來減少垃圾郵件。 了解您的評論如何處理.