Моделиране на домейни в SAP CAP

Въведение

Моделът на домейн в SAP CAP е модел, който описва статичните, свързани с данни аспекти на проблемна област от гледна точка на моделите на обект-връзка. В тази статия ще проучим подробно моделирането на домейни в SAP CAP.

Моделиране на домейни

С прости думи, CDS в SAP CAP произвежда модел на домейн по такъв начин, че да дефинира бизнес проблема по отношение на ключове, полета и анотации. Кодът за генериране на модел на домейн е написан в CDS схема (db/schema.cds). Тези модели на домейни могат да се използват в дефиниции на услуги, модели на постоянство, бази данни или дори да се използват повторно в рамките на друг модел на домейн.

Примерен пример:

Пространство от имена empInfo; с помощта на {Currency, managed} от '@sap/cds/common'; обект Служители: управляван { ID на ключ: цяло число; първо име: локализиран низ (111); фамилно име: локализиран низ (1111); мениджър: Асоциация към мениджъри; дата на присъединяване: цяло число; заплата: Десетична (9,2); валута: Валута; }

 

В този пример създадохме файл schema.cds, където създадохме обект Служители, който включва основни подробности за служител

На цялата тази схема е дадено пространство от имена, т.е. empInfo

Тази схема използва стандартен тип данни, т.е. валута. Използването на стандартен тип данни като този ни помага да донесем всички предварително определени стойности, свързани с него.

Ние използваме CDS за създаване на модел. В този CDS използваме

  1. Обекти за представяне на набор от уникални обекти, напр.
    1. Основна информация за служителите
    2. Комуникационна информация за служителите
    3. Информация за заплатите на служителите
  2. Асоциации за дефиниране на връзки
    1. Свързване на мениджър с друг субект Мениджър, който ще има целия списък с мениджъри

Конвенция и препоръки за наименуване

  1. Името на обекта трябва да започва с главна буква и трябва да е четливо и разбираемо – например служители
  2. Започвайте елементи с малка буква – например име
  3. Препоръчително е да се използва форма за множествено число на субекти – например служители
  4. Препоръчително е да се използва форма на типове в единствено число – например Валута
  5. не повтаряйте контексти – например Employees.name вместо Employees.EmployeeName
  6. предпочитайте еднословни имена – например заплата вместо salaryAmount
  7. използвайте ID за технически първични ключове – например ID за ID на служител
  8. Можете да използвате Namespace, за да направите вашите обекти уникални. Това е като клиентска концепция в SAP, където можете да имате дублиращи се схеми (cds файлове) с уникално пространство от имена, за да ги разграничите. Пространствата от имена не са задължителни, използвайте пространства от имена, ако вашите модели могат да бъдат използвани повторно в други проекти. В края на деня те са просто префикси, които автоматично се прилагат към всички подходящи имена във файл. - например,

пространство с имена лаптоп;обект Dell {}

..… е еквивалентно на:

преносим компютър.Dell {}

  1. Можете да използвате контексти за вложени секции на пространството от имена. - например,

пространство с имена лаптоп;обект Dell {}           //> лаптоп.Dellконтекст Apple { entity MacBookPro {}       //> лаптоп.Apple.MacBookPro     обект MacBookAir {} }

 

образувания

Обектите са като таблици с първични ключове. Можем да извършим CRUD операция, използвайки тези обекти. Дръжте го възможно най-равно. Не го нормализирайте. Не използвайте типове за многократна употреба. Този раздел е само за моделиране, трябва да се добавят само анотации, свързани с отделни полета и не трябва да се добавят технически подробности (логики).

Видове

Типовете са като домейн в SAP ABAP, използван за дефиниране на типа на елементите от данни.

аспекти

Аспектите са разширения на моделите и се използват главно за разширяване на съществуващите дефиниции и анотации. След като моделът е дефиниран, можем да използваме различни cds файлове (Aspect), за да добавим пояснения върху тях за конкретна задача.

Например-

  • CDS– вашият основен модел на домейн, поддържан чист, прост и разбираем
  • audit-model.cds– добавя допълнителни полета, необходими за одит във файл
  • auth-model.cds– добавя бележки за оторизация.

Първични ключове

Подобно на таблици и CDS в SAP ABAP, ние поддържаме първични ключове за Entity с помощта на ключова дума ключ.

Първичният ключ може да се използва повторно в модела, като се използва методологията на общите дефиниции.

Можем да създадем общ.cds модел, където могат да се съхраняват всички общи дефиниции.

// общи дефиниции

entity StandardEntity { ID на ключ: UUID; } Сега тези общи дефиниции могат да се използват повторно, както е по-долу: използване на { StandardEntity } от './common'; entity Служител: StandardEntity { име: String; ... } Мениджър на обекти : StandardEntity { име : Низ; ... }

 

Общият файл вече е създаден по подразбиране с предварително дефиниран обект с име cuid.

Съпоставяне на UUID към OData

CDS картографира UUID към Edm.Guid по подразбиране във всички модели OData. Стандартът OData обаче поставя ограничителни правила за стойностите на Edm.Guid – например, разрешени са само низове с тире – което може да противоречи на съществуващите данни. Следователно позволяваме съпоставянето по подразбиране да бъде отменено, както следва:

entity Книги {

ID на ключа: UUID @odata.Type:'Edm.String';

...

}

Ако е необходимо, можете също да добавите анотацията @odata.MaxLength, за да замените и съответното свойство.

Асоциация

Използва се за дефиниране на връзката между две единици. Подобно на ABAP CDS, и тук използваме думата Асоциация. Ето, ключовата дума много показва a 0..* кардиналност. Ограниченията за мощността могат да бъдат добавени като ограничение (където условие) – например чрез използване не е нула.

Композиции

За разлика от Асоциацията, при която асоциираме поле на обект с обектите на цяла единица, композициите просто се отнасят до конкретно поле на друг обект. Той има допълнително предимство на самостоятелно управлявани дълбоки операции (вмъкване/актуализация) и каскадно изтриване (изтриване на много зависима таблица).

// Дефиниране на поръчки със съдържащи се OrderItemsentity Orders { ID на ключ: UUID; Елементи : Състав на много Order_Items на Items.parent=$self;}entity Order_Items { // ще бъде достъпен само чрез Поръчки  ключов родител: Асоциация към поръчки; ключова книга: Асоциация към книгите; количество: цяло число;}

Най-добри практики

  1. Не добавяйте технически подробности в моделите, ние използваме аспектиза това
  2. употреба кратки имена и прости плоски модели
  3. Не прекалявайте с нормализирането на обектите в моделите
  4. Използвайте локални целочислени последователности, ако наистина се справяте с големи натоварвания и обеми. В противен случай предпочитайте UUID

Досега това, което научихме: Създаване на модел и аспекти отгоре.

Моделиране на домейни в SAP CAP

Оставете коментар

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.