OData Model Naming Conventions
I thought of sharing the naming conventions I follow to improve the readability of my OData service for UI developers and other consumers.
|General rules for all artefacts||No “ALL CAPS”|
|Use Camel case|
|Use English Names|
|No SAP technical names|
|Entity Names||Only Nouns|
|Not to contain operation names|
|🙂 examples||SalesOrderHeader, SalesOrderItem, Address, CostCenter|
|😥 examples:||SALES_ORDER, PO_CREATE, Orders, CostCenterF4, Bukrs, PurchaseOrderList|
|Complex Type||Whenever you have too many fields in your entity, improve the readability of your Entity by grouping fields into Complex Types|
Complex Type “Address” for complex properties “DeliveryAddress”, “PostalAddress”
Complex Type “CompensationDetail” for complex properties “OldCompDetail”, “NewCompDetail”
|Entity Sets||Plural of Entity name. Or add ‘Set’ at the end of Entity name|
|🙂 examples:||SalesOrderHeaders, SalesOrderItems, Addresses, CostCenters, Currencies, CurrencySet|
|Navigations||Same as Entity name if the target cardinality is 1|
|Same as EntitySet name if the target cardinality is M|
Consider two self explanatory, related entities, SalesOrderHeader and SalesOrderItem. Consider the navigation between them named as “SalesOrderItems”. Now, to navigate from header to item, we canuse a self explanatory URL as below.
If you had named the Navigation as say “Header_Item”, then you would have called URL
which is not at all consumer friendly.
|Function Imports||Name should clearly Indicate the operation getting performed|
|🙂 examples:||ReleasePO, ApproveLeave, BlockSalesOrder, GetReleaseStatus|
Let me know your views and if you follow any other best practices.