CDS View Entities vs Classic CDS DDIC Views

Both are DDL sources compiled into database views at activation, and both carry CDS annotations, associations and exposure metadata. The structural fact that causes most confusion is that a classic CDS view (DDL source type 'view') always generates a corresponding object in the ABAP Dictionary, the same kind of object you get from SE11 view maintenance, with its own technical name visible in the dictionary object browser. A CDS view entity (DDL source type 'view entity') does not generate that dictionary object. It is compiled and executed directly by the CDS infrastructure as its own artifact type. This is not a cosmetic syntax change from 'define view' to 'define view entity'. It affects how the object is looked up, how associations redirect, how it is traced at the database layer, and whether it can serve as the persistence root of a RAP business object. Consultants who treat the rename as purely stylistic run into missing-object confusion the first time they go looking for it in the dictionary.

Use a CDS view entity for anything new: RAP business objects of any kind, any Fiori-facing data model built from this point forward, and any place where association redirection, draft handling, or managed save logic will eventually sit on top of the model. It is the required persistence layer for RAP root and child entities. Use a classic CDS DDIC view only when there is a concrete reason to keep the classic dictionary view object around, for example a reporting layer or a legacy consumer that does native SQL or old-style dictionary tooling against the generated view name, or an existing SEGW-generated OData v2 service that already depends on the classic view and is not being rebuilt. Reaching for a classic CDS view on a brand new development is a mistake almost every time; it buys nothing and forecloses a clean path into RAP later.

Below both sits the same layer: database tables, CDS table functions, or AMDP-backed views providing the raw data. Above a classic CDS view sits whatever consumed the generated dictionary view: native SQL, older ABAP reports, or a SEGW project mapped onto it. Above a CDS view entity sits the RAP stack directly: behavior definitions attach to it as the underlying persistence, service definitions expose it through OData, and associations on it drive navigation in Fiori elements list reports and object pages. CDS view entities effectively supersede classic CDS views as the entry point into new custom data models; they are not a replacement for CDS table functions or AMDP, which remain the layer below when set-based logic cannot express the requirement. Classic CDS views are not being removed, but they are being pushed downward into a legacy or reporting-only role rather than sitting at the head of new service development.

A team builds a custom approval object for internal purchase requests. The old approach, still present elsewhere in the same system, defined a classic CDS view named something like ZC_PURCHREQ_OLD with 'define view', exposed it through a SEGW project, and wired approval logic through a BOPF-based unmanaged implementation. For the new object the team defines ZI_PurchReqApproval with 'define view entity', selects from the base table, exposes header fields and an association to a line-item child view entity, and adds a composition annotation. A behavior definition is then written against ZI_PurchReqApproval as the managed root, with a create action for submission and a determination that sets the initial status. A service definition exposes both the root and the child through OData V4, and the Fiori elements list report renders directly off the root's annotations. No SEGW project is involved anywhere in this second path, and no classic dictionary view object is ever generated for ZI_PurchReqApproval, which is the detail that trips up anyone searching for it the old way.

CDS view entities are the current standard for custom development on S/4HANA and are mandatory for RAP business objects, which is itself the recommended pattern under a clean core approach for anything that used to be a custom BOPF or function-module-driven object. Classic CDS DDIC views are still fully supported and are not being withdrawn, but new custom development that reaches for one instead of a view entity is working against the direction the platform and the tooling are both pushing. Existing classic views feeding stable reporting or legacy OData V2 services are reasonable to leave alone; the discouraged pattern is starting a brand new custom object on a classic CDS view when a view entity was available and no dependency forced the older choice.

This is a developer decision made at design time, but it belongs on the architect's standards checklist for any new custom development, since retrofitting a classic view into a view entity later is real rework, not a flag flip. Functional consultants are only affected indirectly, through what fields and associations end up exposed for extension.

Read the RAP managed versus unmanaged material to see why view entities are non-negotiable for managed roots, and the CDS associations versus joins page to understand the redirection differences that show up most often during conversion. The compatibility views page is worth checking when a classic CDS view in an S/4HANA system turns out to be one of SAP's own delivered compatibility artifacts rather than custom code. Service definition and service binding material explains what sits directly above whichever variant is chosen.